Prepare a Next.js Site for Cloudflare Workers

Start from the project you actually have

An existing site may already use a working adapter and deployment process. Preserve that structure until a concrete requirement justifies a change. Review the current official Cloudflare and adapter guidance for the installed versions; framework recommendations and support matrices can change. This guide focuses on the decisions and checks that remain useful across those changes, rather than prescribing one permanent setup command.

Inventory the routes, API handlers, data sources, uploads, background jobs and image behaviour. Record which pages are static and which depend on request-time identity or data. The deployment target must support those capabilities, not merely compile the homepage.

Identify runtime assumptions

Inspect dependencies that use local files, native modules, long-running processes or database sockets. Confirm that the selected runtime and adapter support the required behaviour. Persistent uploads should use an appropriate storage service; do not assume files written during a request will become durable application storage.

Make a short compatibility table for the project. For each assumption, record the production capability and the test that verifies it. This gives you a focused migration checklist and prevents trial-and-error configuration changes from obscuring the actual requirement.

Separate public configuration and credentials

Record which values are needed at build time and which are needed at runtime. A public site origin may belong in metadata generation, while a backend service token must remain private. Check framework conventions that expose selected environment variables to client bundles. Keep real credentials out of source files, examples and deployment logs.

Validate required configuration at the appropriate boundary. If a legacy service is still used during migration, give it an explicit origin and define how requests are routed. Avoid a setup where moving the public domain causes a service bridge to call itself recursively.

Package routes and assets together

Build the framework output using the project’s supported adapter. Confirm that the Worker entrypoint and static assets are included in the deployment artifact. If the adapter uses generated cache assets for static or pre-rendered routes, follow its documented population and packaging process. A correct source tree does not guarantee a complete artifact.

Verify representative production behaviour

Exercise the packaged application in a target-compatible runtime. Cover the homepage, a nested content route, a dynamic endpoint, redirects, a missing page, sitemap and image assets. If there are forms or external actions, use safe validation or test adapters instead of sending real enquiries merely to confirm a deployment.

Check canonical origins and metadata against the intended domain. Verify that private data is not placed in shared caches and that public content can be reused appropriately. Keep generated artifacts tied to the exact source version used to build them so a later deployment can be reproduced.

Plan domain migration as a separate operation

Publishing a review environment and moving an existing production domain are different steps. Before a domain cutover, verify DNS ownership, service routing, redirects, form destinations and any authentication callbacks. Keep the previous working configuration and define how to restore it if the main user journeys fail.

Do not mark the migration complete solely because the homepage opens. The meaningful checks are the paths people use: finding a course, opening a resource, submitting an authorized request and reaching the correct backend. Monitor those paths after the cutover according to the project’s operating process.

Release checklist and official references

• The installed adapter and runtime assumptions are documented.
• Public values and secrets have separate exposure rules.
• Worker, static and generated cache assets are packaged.
• Representative routes and error paths pass on the artifact.
• Canonical URLs and redirects match the intended origin.
• Domain cutover has its own verification and recovery plan.