Deploy on Cloudflare

The D1 kits use Cloudflare Workers for the website and Cloudflare D1 for application data. Create resources for your own app, then update the Worker configuration with their identifiers.

1. Configure production bindings

Update the production environments in the Wrangler files. Keep the binding names the application expects, and point them at your own D1, R2, queue and other resources.

The Next.js kit also has OpenNext cache bindings. Those are separate from the application's APP_DB database. The TanStack kit has its own web and jobs Worker configurations.

2. Apply the database migrations

For the Next.js kit:

pnpm --dir apps/web exec wrangler d1 migrations apply APP_DB --remote --env production

Apply its configured cache migrations too when you are creating the OpenNext cache database for the first time.

For the TanStack kit:

pnpm db:migrate:production

Both application databases need the MCP records migration before the web app starts serving OAuth connections.

3. Set the secrets and application origin

Configure Better Auth, your sender and Resend credentials on the Workers that use them. Keep secrets in Worker secrets rather than public vars.

Use your deployed origin in the auth and site settings. The User MCP and Admin MCP addresses will use that same origin.

4. Build for production

For Next.js:

pnpm --filter web exec opennextjs-cloudflare build --env production
pnpm --filter web exec opennextjs-cloudflare deploy --env production

Deploy the platform Worker as described in the repository when creating the app's background services.

For TanStack:

pnpm cf:deploy:production

That script builds with CLOUDFLARE_ENV=production and deploys the web and jobs Workers. Make sure the generated build contains your production bindings before upload. Building with the default environment can leave local placeholder database IDs in the generated configuration.

5. Check the live app

Test email verification, password login, a workspace and both connection gates. The Next.js demo uses Workers Paid because password/auth work exceeded the Free CPU limit during testing. Check your own runtime limits if you see intermittent CPU errors.

See troubleshooting if the Worker deploys successfully but login or the database fails.