Next.js
To create a new Next.js app, pre-configured to run on Cloudflare using @opennextjs/cloudflare
↗, run:
For setup, select the following options:
- For What would you like to start with?, choose
Framework Starter
. - For Which development framework do you want to use?, choose
Next.js
. - Complete the framework's own CLI wizard.
- For Do you want to use git for version control?, choose
Yes
. - For Do you want to deploy your application?, choose
No
(we will be making some changes before deploying).
First, install @opennextjs/cloudflare ↗:
Then, add a wrangler.toml
file to the root directory of your Next.js app:
As shown above, you must enable the nodejs_compat
compatibility flag and set your compatibility date to 2024-09-23
or later for your Next.js app to work with @opennextjs/cloudflare.
wrangler.toml
is where you configure your Worker and define what resources it can access via bindings.
Add the following to the scripts field of your package.json
file:
npm run build:worker
: Runs the @opennextjs/cloudflare ↗ adapter. This first builds your app by runningnext build
behind the scenes, and then transforms the build output to a format that you can run locally using Wrangler and deploy to Cloudflare.npm run dev:worker
: Takes the output generated bybuild:worker
and runs it locally in workerd ↗, the open-source Workers Runtime, allowing you to run the app locally in the same environment that it will run in production. If you instead runnext dev
, your app will run in Node.js, which is a different JavaScript runtime from the Workers runtime, with differences in behavior and APIs.npm run preview:worker
: Runsbuild:worker
and thendev:worker
, allowing you to quickly preview your app running locally in the Workers runtime, via a single command.npm run deploy
: Builds your app, and then deploys it to Cloudflare
opennextjs/cloudflare
uses Workers KV as the cache for your Next.js app. Workers KV is fast ↗ and uses Cloudflare's Tiered Cache to increase cache hit rates. When you write cached data to Workers KV, you write to storage that can be read by any Cloudflare location. This means your app can fetch data, cache it in KV, and then be read by subsequent requests from this cache anywhere in the world.
To enable caching, you must:
As shown above, the name of the binding that you configure for the KV namespace must be set to NEXT_CACHE_WORKERS_KV
.
You can continue to run next dev
when developing locally.
In step 3, we also added the npm run preview:worker
, which allows you to quickly preview your app running locally in the Workers runtime, rather than in Node.js. This allows you to test changes in the same runtime that your app runs in, when deployed to Cloudflare.
Either deploy via the command line:
Or connect a GitHub or GitLab repository, and Cloudflare will automatically build and deploy each pull request you merge to your production branch.
You can serve static assets your Next.js application by placing them in the ./public/
directory. This can be useful for resource files such as images, stylesheets, fonts, and manifests.
When using Workers Assets, Cloudflare will first attempt to serve any static assets which match the incoming request.
For example, if you have requests for /logo.png
and /blog/hello-world.html
in your assets directory, and make requests for /logo.png
and /blog/hello-world
, those files will be served respectively. The html_handling
option allows you to customize the serving of HTML files if you have specific needs around redirects and trailing slashes.
If a request does not match a static asset, Cloudflare will then invoke your Worker script module, if one is present. This can be configured with the main
property in wrangler.toml
.
Finally, if a request does not match any static assets, and either a Worker script module is not present, or from within that Worker script module, the asset binding's fetch
method is called (e.g. env.ASSETS.fetch(request)
), Cloudflare will fall back to evaluating the not_found_handling
behavior. By default, it will serve a null-body 404-status response, but this can be configured to instead serve custom HTML 404 pages, or to serve a single-page application (SPA).
At present, there is no way to customize this routing behavior beyond the html_handling
and not_found_handling
options. We plan to offer additional configuration controls, such as allowing you to always run the Worker script modules for certain paths, in the future.