Deploy to Vercel

This guide deploys a working standalone, Nuxt, or Next.js application to Vercel. You need a Vercel account, committed migrations, and the data credentials required by your app.

1. Authenticate the CLI

Install Vercel in the project and sign in:

pnpm add -D vercel
pnpm exec vercel login
pnpm exec vercel whoami

Finish the device approval opened by vercel login. Continue when whoami returns your account; a dashboard login alone does not authenticate the CLI.

2. Select Vercel

Set the host in your existing config:

deploy: {
  target: 'vercel',
}

Vercel defaults to a Turso database. Create it first, then set TURSO_DATABASE_URL and TURSO_AUTH_TOKEN in the ignored .env file or process environment. CloudConfig applies migrations and synchronizes these server settings during deployment. It does not create the Turso service.

For an existing D1-backed app, set db.remote: { provider: 'd1' } to retain its database. See Database and File Storage for credentials and provider overrides.

CloudConfig reuses .vercel/project.json when the project is already linked. Keep .vercel out of version control.

To select a particular team or project, add those settings:

deploy: {
  target: 'vercel',
  name: 'blog-app',
  vercel: { scope: 'my-team', project: 'blog-app' },
}

An explicit deploy.name or deploy.vercel.project takes precedence over an existing project link.

3. Preview and Deploy

Run the deployment commands:

pnpm exec cloudconfig deploy --dry-run
pnpm exec cloudconfig deploy

The dry run checks local configuration, migration metadata, and required settings. It makes no provider calls or remote schema checks.

Deployment links the project, pulls its production settings, builds locally, applies migrations, synchronizes server settings, and publishes prebuilt production output. Secret values are supplied through stdin.

4. Check the Production URL

Open the printed production alias and /api/_docs. Test sign-in and a write followed by a read.

Generated deployment URLs can require Vercel login even when the production alias is public. If the production alias also asks for a login, review the project's deployment-protection settings before testing public API clients. Vercel account limits and Function timeouts still apply.

For native durable agent runs and schedules, declare deploy.agent, install workflow, and follow Deploy Agents. The automatic Workflow build integration currently supports Nuxt. Declare deploy.automations for portable scheduled and event-driven jobs using the same infrastructure. The CLI synchronizes schedules after publication; protected projects need VERCEL_AUTOMATION_BYPASS_SECRET for that request. See Deploy Automations and file transport limits.

Deploy from CI

Supply VERCEL_TOKEN through your CI secret store. VERCEL_ORG_ID and VERCEL_PROJECT_ID can identify an existing project. These credentials are used by deployment; they are not application runtime secrets.

How Your Framework Runs

Next.js uses vercel build; Nuxt uses the vercel Nitro preset. Standalone projects build a Function from the backend config.

For custom standalone routes, set deploy.entry to a module whose default export is an object with fetch(request, env). That handler also works on Azure. The adapter follows Vercel's prebuilt deployment flow.

When the app works, configure its domain and production origin.