Next.js Framework Guide

Next.js is the most popular open source React-based framework. It allows developers to use all the features you need for production in a front-end framework: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed. Check out their documentation for guides to all these key features.

To get started, you can run the following command to create a new Next.js project and the follow the steps in their automatic setup guide:

npx create-next-app@latest

Or, if you want to start with a template designed specifically for headless WordPress, you can clone one of these starter templates:

git clone https://github.com/colbyfayock/next-wordpress-starter

git clone https://github.com/colbyfayock/next-wpgraphql-basic-starter

git clone https://github.com/JEverhart383/crash-course-headless-wp-next-wpgraphql

To deploy your project to Atlas, it will need to be available on a remote GitHub or Bitbucket repository. The Next.js installation process lets us initialize a local repository for the project.

Create a new remote repository, and then run the following commands to initialize and configure your local and remote repositories:

# Add remote repository
$ git remote add origin https://<your-git-provider>/<username>/<repo>


# Stage all changed files
$ git add -A


# Commit the files to the current branch
$ git commit -m "initial commit"


# Push changes to remote repository
$ git push -u origin main

Atlas detects that it is a Next.js app and runs the build scripts and configs necessary for the build details.

One thing to note is the next/cache folder within your Next.js project. Atlas caches common framework assests between builds to optimise build times. The build step will not override the folder.

Once your project is in your repository, you can follow the directions in our getting started guide to deploy your project to Atlas.

The Next.js Image component, next/image, is an extension of the HTML <img> element, evolved for the modern web. It includes a variety of built-in performance optimizations to help you achieve good Core Web Vitals.

One thing to keep in mind is when switching over your domains on Atlas, you must declare them in the next.js.config file, otherwise the images will not render. Please reference Next Image Docs for guidance.

While our Node infrastructure will support path-based revalidation on-demand, this revalidation will currently not extend to edge cached versions of that path, nor will they apply to all instances of your front-end application (if scaled beyond a single instance). This is under active investigation by our engineering team.

By default, Next Image serves up WebP versions of images to browsers that support it, and the AVIF format can also be delivered through configuration. While Atlas supports the delivery of both of these formats, Cloudflare does not support the Vary header for paths without a file extension. Because of this, it is possible that if the WebP/AVIF version of a header is cached, that version may be served to browsers that cannot support such formats and could result in broken images for such users. The linked GitHub issue has a potential workaround, and we currently have a request in to Cloudflare to support such functionality.

Because Atlas does not rely on serverless functions/edge functions, such functionality currently runs on the origin Node server. It is important to note that this means that such functions will run only on requests that terminate at the origin; any requests served from the edge will continue to serve whatever response is cached at the edge for that path.

The Next.js documentation has more in depth details on framework features.