Deployment

Put your app online with Cloudflare, Vercel, or Azure.

You can deploy the same CloudConfig application to different hosts. Choose the host in cloud.config.ts, then run the same command:

cloud.config.ts
deploy: {
  target: 'vercel', // 'cloudflare' | 'vercel' | 'azure'
}
pnpm exec cloudconfig deploy

Cloudflare is the default. The initializer's --target nuxt, next, or standalone chooses the framework; deploy.target chooses where it runs. The database defaults to Turso on Vercel and D1 on Cloudflare and Azure. Set db.remote.provider explicitly to keep that choice across app hosts.

Choose Your Host

Follow one guide for your first deployment:

Cloudflare

Run a Worker with native D1 and R2 bindings.

Vercel

Publish production Functions for your framework.

Azure

Run Node.js on a Linux App Service.

All three support standalone, Nuxt, and Next.js applications. Nuxt agent hosts use native durable execution on each cloud: Cloudflare Agents, Vercel Workflow, or Azure Durable Functions. See Deploy Agents for the runtime dependencies, execution storage, and authenticated gateway contract. Portable scheduled and event-driven jobs use the same native infrastructure; see Deploy Automations. Review Platform Support for framework coverage, storage limits, and what the repository checks establish. Cloudflare Workflow classes declared in deploy.workflows require Cloudflare.

Before Your First Deployment

Start with a working local app from the Quickstart. Before following the guide for your host:

  1. Generate, review, and commit SQL migrations and migrations/meta snapshots.
  2. Run cloudconfig auth status and provide the required values in the ignored .env file. Dashboard starters with two-factor verification also need email delivery.
  3. Prepare data-service credentials. Vercel's Turso default needs an existing database URL and auth token. D1 or R2 used from Vercel or Azure need Cloudflare credentials.

Deployment builds the application, prepares its configured data services, applies migrations, and publishes the result. It checks local configuration before changing the remote database.

Moving an Existing App?

Pin db.remote.provider before changing hosts to keep the same database. Deployment leaves existing data, the previous deployment, and DNS in place.

Follow Switch Hosts to validate the new app before moving traffic. Moving the database or files is a separate migration.

Copyright © 2026