Skip to content
richbay.ai
PlaygroundsCasesLearnToolsFor Teams
richbay.ai

Learn by Solving. Solve practical problems, test what works, and turn evidence into reusable methods, workflows, and stacks.

Explore

  • Playgrounds
  • Cases

Resources

  • Learn
  • Tools

RichBay

  • For Teams
  • About
  • Privacy

© 2026 RichBay

RichBay.ai is independent and is not affiliated with or endorsed by the model providers or companies referenced on this site.

Tutorial · Build and deployment

Deploy an AI product on Cloudflare Workers

Choose the current Next.js deployment path, bind only the services the product needs, and release with a reversible production check.

2–4 hoursIntermediateUsed at RichBayReviewed 2026-09-05
← All TutorialsStart with the steps

What you will produce

A versioned production deployment with validated bindings, a public release marker, smoke checks, and a rollback path.

On this pageBefore you beginStepsDeliverablesDecision boundariesSources
Used at RichBay

RichBay currently deploys its existing Next.js 16 application to Cloudflare Workers through OpenNext. Cloudflare now recommends vinext for new Next.js projects; migration should wait until compatibility is verified.

Before you begin

Set the operating boundary first.

  • A working application with repeatable local tests and a locked package manager.
  • A Cloudflare account, Wrangler authentication, and a named production owner.
  • A list of required bindings, secrets, data regions, and expected request paths.
  • A low-risk smoke-test route and a rollback decision rule.

Step by step

Move from scope to a checked artifact.

01

Choose the deployment path deliberately

For a new Next.js application, start by checking vinext compatibility because Cloudflare lists vinext as its recommended path. For an existing OpenNext deployment, keep the adapter when migration has an unresolved compatibility gap. Use Pages only for a true static export.

Checkpoint
The repository records why vinext, OpenNext, or static Pages fits this application today.
Artifact
Deployment-path decision record
02

Define runtime and data boundaries

List which routes need server rendering or APIs and which can remain static. Add D1, R2, KV, Workers AI, Queues, or other bindings only when a validated feature requires them. Document what data crosses each boundary and which system owns deletion and recovery.

Checkpoint
Every binding has a named feature, data owner, and failure behavior.
Artifact
Runtime and binding map
03

Make the build reproducible

Pin the adapter and deployment tooling, generate binding types, and run type checks, tests, content validation, and the exact production build command. Keep secrets out of source control and distinguish preview configuration from production configuration.

Checkpoint
A clean checkout can produce the same deployment artifact without undocumented local state.
Artifact
Verified build and configuration inventory
04

Preview the production artifact

Run the built Worker locally or in a preview environment, then check status codes, redirects, metadata, static assets, authenticated boundaries, and any database migrations. Treat remote AI bindings as potentially billable even during local development.

Checkpoint
The exact production artifact passes a written route and binding matrix.
Artifact
Preview smoke-test record
05

Release a traceable version

Generate a public version marker from the commit, run a deployment dry-run, and deploy the immutable build. Record the commit, Worker version, deployment time, and operator. Avoid changing data schemas and application behavior in one unreviewed step.

Checkpoint
The public version marker resolves to the intended commit and the deployment provider reports a successful version.
Artifact
Production release record
06

Verify and keep rollback available

Repeat the route matrix against the public domain, including critical 200, redirect, 404, metadata, and API checks. Watch errors and user-visible regressions. Roll back when the release breaks a critical path or violates the prewritten acceptance boundary.

Checkpoint
Production matches the release record, or the previous known-good version is restored.
Artifact
Public verification and rollback decision

Deliverables

Keep the work reusable and inspectable.

  1. Deployment-path decision record
  2. Runtime, data, and binding map
  3. Repeatable production build command
  4. Preview route and binding matrix
  5. Commit-to-Worker release record
  6. Public smoke-test and rollback record

Decision boundaries

What this tutorial does not prove.

  • Cloudflare labels vinext beta; verify its compatibility report before migrating an existing production application.
  • OpenNext remains a documented maintenance path, but it should not be presented as Cloudflare’s default for a new application.
  • D1, R2, Workers AI, and other services have separate limits, pricing, and data behavior that must be checked for the chosen plan.
  • A successful deployment does not prove application correctness, security, data recovery, or model-output quality.

Source ledger

Check the current primary guidance.

  1. Cloudflare Workers: Next.js guide

    Primary source for the current recommended vinext path, compatibility check, and Workers bindings.

  2. Cloudflare Workers: OpenNext adapter

    Primary source for maintaining an existing OpenNext application and its supported Next.js features.

  3. Cloudflare D1 documentation

    Primary source for D1 binding, data, and operational details.

  4. Cloudflare R2 documentation

    Primary source for object-storage behavior, limits, and pricing links.

Continue the loop

Connect the tutorial to evidence and tools.

Browse coding and building toolsInspect RichBay StacksRead the AI product launch tutorial