Deployment & Operations
Deploy Valcraven to Cloudflare Workers — provisioning, CI/CD, secrets, and database migrations.
Valcraven's production target is Cloudflare Workers. The Next.js app in apps/web is built and served through OpenNext, backed by D1 (serverless SQLite) for the database, R2 for object storage, and Cloudflare Queues for scalable email campaign sends. A second, standalone realtime Worker (apps/realtime) hosts the AI chat agent and other live features over WebSockets. Docker in this repo is local-dev only — it is never the production runtime.
The good news: a normal next build runs on Workers via OpenNext's adapter, so there is no rewrite required. The plumbing already ships — wrangler.toml, the build:cf / deploy:cf / deploy:cf:setup scripts, and the D1/R2 branches in lib/db.ts and lib/storage.ts. The pages below explain how to provision, deploy, and operate it.
- Deploying to Cloudflare Workers — the deploy scripts, what gets provisioned (D1, R2, Queues, the realtime Worker), and how to bind a custom domain.
- CI with Workers Builds — how the web Worker auto-deploys on push via Cloudflare Workers Builds, why the realtime Worker deploys manually, and how the repo's GitHub Actions fit in.
- Secrets & env — plain vars (
wrangler.toml [vars]) versus secrets (wrangler secret put), which are required, and how to set them on both Workers. - Running migrations in prod — applying D1 migrations to production, and the OpenNext cache tables seeded at deploy time.
For the architecture behind all this, see How Valcraven runs on Cloudflare Workers and The realtime Worker.
Hard-won gotchas
A curated collection of the traps that cost real debugging time on Valcraven — Next.js dev quirks, the monorepo dev stack, Worker deploys, Durable Objects, CI, and more.
Deploying to Cloudflare Workers
Provision and ship Valcraven to Cloudflare Workers — D1, R2, Queues, the realtime Worker, and a custom domain.