Deploy a v0 app to production: the publish flow and what to check first

Symptom

v0's own docs name a few states you may see: a branch menu that says No active preview, a publish that is blocked by GitHub, or the action button changing to Fix Build, Fix CI or Fix Conflicts. Those labels tell you which of the causes below you are dealing with.

Why it happens

The preview and production are different environments

v0's preview runs in a Vercel Sandbox and, per v0's docs, can only access variables from the Development environment of the connected Vercel project. Your published app reads Production. The sandbox docs are explicit that deployments run on separate Vercel infrastructure with their own environment variables. So a working preview tells you nothing about whether Production has its keys.

Vercel adds two details that catch people out: variable changes only apply to new deployments, and NEXT_PUBLIC_ variables are inlined into the browser bundle at build time. A key added after the build is not in the live app until you publish again.

GitHub is now in the path

If you connected GitHub, v0 never pushes straight to your base branch. It works on a working branch, and Publish creates or reuses a pull request, merges it, then waits for production. v0's docs say required checks, required reviews, draft pull requests and other branch protection can block that merge. When they do, the pull request stays open and the publish waits.

Your team may not allow it

Vercel teams can set Deployment Policies that restrict which sources create deployments. If a policy blocks v0, a team Owner has to allow the source or override it for the project. Publishing also needs a v0 role that can edit the chat and permission to deploy to the Vercel project.

The fix

1. List the variables production needs. Open Project menu then Settings then Environment Variables in v0, or the Vercel project itself, and check each variable's environments. Integration variables (Supabase, Neon, Stripe and others from the Marketplace) are added for you, but anything you typed in yourself may only be set for Development. From a terminal linked to the project (the --environment option needs Vercel CLI 64.7.0 or later):

vercel env list --environment production
vercel env list --environment development
 
# build locally with the production values, without writing them to disk
vercel env run -e production -- next build

2. Fail the build when a variable is missing. A build that stops with a clear message is better than a live site that half works. A small schema checked from next.config.ts does that:

// env.ts (plain module, no "server-only" import, so next.config can load it)
import { z } from "zod"; // zod 4 syntax; on zod 3 use z.string().url()
 
const schema = z.object({
  DATABASE_URL: z.url(),
  STRIPE_SECRET_KEY: z.string().startsWith("sk_"),
  NEXT_PUBLIC_SITE_URL: z.url(),
});
 
export const env = schema.parse({
  DATABASE_URL: process.env.DATABASE_URL,
  STRIPE_SECRET_KEY: process.env.STRIPE_SECRET_KEY,
  NEXT_PUBLIC_SITE_URL: process.env.NEXT_PUBLIC_SITE_URL, // reference by full name so Next.js can inline it
});

// next.config.ts
import type { NextConfig } from "next";
import "./env"; // throws during the build if a required variable is missing
 
const nextConfig: NextConfig = {};
export default nextConfig;

Swap in your own variable names. Keep the schema to what the app truly needs, or every preview build fails too.

3. Run the first publish deliberately. v0's first-publish flow has five steps: confirm the Vercel project name, choose Visibility, pick a Domain (the vercel.app one, a connected custom domain, or add one in Vercel), review Commerce mode if there are unclaimed Stripe sandboxes or Shopify development stores, then Publish. Choose visibility knowingly. A protected production URL means your users meet a Vercel login.

4. Clear GitHub blockers. If the publish stalls, open the branch menu next to Publish. It shows the preview deployment, diff, pull request and CI checks. v0 can handle failing CI and merge conflicts through Fix CI or Fix Conflicts; required human reviews have to be completed in GitHub, then you select Publish again.

5. Fix build failures from the logs. When a deployment has errors, v0 shows Fix with v0 or Fix Build, which reads the logs and applies a fix. v0's docs say paid plans get some free uses a day on unedited code, then fixes cost credits like a normal prompt. Read the build log yourself first through the deployment inspector link; a missing variable is faster to fix by hand.

6. Ship updates through Publish Changes. After more work, open Publish, check the deployment and domain, and select Publish Changes. The production URL stays the same. If a release goes wrong, use Vercel's rollbacks from the inspector, or restore an earlier v0 version and publish it.

How to prevent it

• Set every new variable for Development, Preview and Production at the moment you add it, with separate keys for test and live where the provider has them.
• Turn on GitHub before launch so every change gets a preview deployment and a pull request you can review.
• Add a required CI check that runs tsc --noEmit and your tests, so v0 cannot merge a broken build through Publish.
• After each publish, click through sign-up, the main paid action and one error state on the production domain.

The checklist in launching an AI-built app covers what to test after go-live. If you want the code out of v0 before you host it, read exporting v0 code first. Both sit under the wider prototype to product guide.

When to get help

Publishing is easy; knowing the app holds up under real users is the hard part. The free vibe code health check flags the usual gaps before launch. If you would rather hand the launch over, my Rescue Sprint gets the app ready for real users, whether it's about to launch or already struggling in production.