Deploying a Next.js website to Cloudflare Workers involves more than uploading a successful local build. The application must run within the target runtime, use an appropriate framework integration and access its data through supported mechanisms. A company profile can benefit from this hosting approach, but deployment choices should follow the application's actual requirements.
Framework support changes over time. Check the official Next.js and Cloudflare documentation for the installed versions and chosen path when planning a release. This checklist describes decisions to verify rather than promising that every Next.js feature works identically in every integration.
Separate static pages from runtime features
List which routes can be generated ahead of time and which need request-time execution. Service pages and project write-ups may be static. Contact submissions, authentication, lead administration and personalised content need different handling.
A static export and a server-capable deployment are different products. If the website requires a submission API, confirm where that API runs and how it stores data. A static page that links to a non-existent server endpoint is not a completed contact workflow.
Select the integration deliberately
Cloudflare documents current Next.js-oriented deployment paths, including approaches for existing applications. Read their feature and compatibility guidance before choosing one. Do not assume a tutorial for an older release still describes the recommended defaults.
Record the framework version, integration version, runtime settings and deployment command in the repository. If a temporary compatibility workaround is necessary, make it reproducible, narrow and attributable to the upstream issue. An undocumented change inside installed dependencies will disappear during the next clean install.
Remove assumptions about a persistent local machine
A development server may read local content files or write enquiry records beside the source code. A Worker deployment should use an explicitly supported strategy. For static content, a build-generated manifest can preserve a simple editorial workflow without requiring runtime filesystem reads.
Use suitable platform storage or external services for runtime data. Confirm how bindings reach the application's server code and how schema changes are applied. Local emulation is useful, but it does not prove that the production binding, permissions and dataset are correct.
Test real requests in the target runtime
Organise a deployment rehearsal around outcomes:
| Check | Evidence to capture |
|---|---|
| Public homepage | Correct content and successful response |
| Dynamic detail route | Known slug renders; unknown slug returns a real missing page |
| Contact submission | Valid enquiry persists and invalid input is rejected |
| Administrator route | Unauthorised request cannot access protected data |
| Error and cache paths | Cold requests and repeated requests behave predictably |
A build success proves packaging, not runtime correctness. Test after a fresh start and when caches are absent, as well as after the application has warmed up. Some compatibility problems only appear when a previously unused route or manifest is loaded.
Configure environments independently
Keep production secrets out of source control and browser-exposed configuration. Use separate preview credentials and storage where possible. Check that a preview form cannot create live enquiries or send notifications to real customers accidentally.
Review allowed hostnames, canonical site URLs, privacy notices and administrative access for the production domain. Confirm that monitoring distinguishes application failures from upstream service failures. Avoid placing personal enquiry contents in general-purpose logs.
Plan the release and recovery
Keep a known working deployment and document how to restore it. Data migrations may need their own recovery plan because reverting application code does not automatically revert data.
Assign ownership for updates to Next.js, the integration and platform configuration. Recheck important routes after upgrades rather than relying on the previous release's compatibility result. Launch when packaging, runtime requests and data persistence have all been demonstrated in the intended environment, with a clear path to recover if the next change fails.
Primary references
Related reading
- Website Security Checklist for Business Owners
- Software Maintenance SLAs: Define Response and Recovery
Explore our web apps to plan a practical implementation around your team's needs.