Deploy a v0 App to Production in 5 Steps (2026)

v0 turns a prompt into a working preview, and Publish then involves a Vercel project, a visibility setting, a domain, and sometimes a GitHub merge, so each one needs a check before production.

Publish runs the deploy, and visibility and production variables, both managed in Vercel, decide whether it's safe. When a build fails, the deployment card has the logs and the Fix with v0 button.

I read v0's deployment, GitHub, Vercel integration, and FAQ docs, then checked the production settings against Vercel's own documentation. The v0 and Vercel steps below match those pages as of October 21, 2026.

What you need before you deploy a v0 app

Publish works when the chat has changes to publish and your account has the right permissions in both v0 and Vercel. GitHub and custom domains add two more requirements.

Prerequisites:

• A v0 chat with unpublished changes
• A v0 role that can edit the chat, plus permission to deploy the Vercel project (a Vercel Viewer with the v0 Builder role is the exception, explained next)
• A GitHub account or organization (only if you publish through pull requests)
• A domain and access to its registrar's DNS settings (only for a custom domain)

A Vercel Viewer with the v0 Builder role can publish from v0 but can't deploy through GitHub or the CLI, which means the same person can publish without trouble in v0 and then fail on a GitHub-triggered deployment.

Once those are in place, the first publish uses one Publish dialog, and visibility, commerce checks, and a custom domain's DNS records add steps.

How to deploy a v0 app step by step

Steps 1 to 4 make up the first publish, and step 5 repeats for every update.

Step 1: Open Publish and confirm the Vercel project

Click Publish in the chat header. v0 asks you to create or confirm the Vercel project name.

The project you confirm has one stable production URL, and later deployments update it.

Look at the connected project at the top of each chat before you publish, so you update the URL you expect (v0's docs don't describe how to unlink or relink it; v0's FAQ only says where it shows).

Step 2: Choose visibility

Visibility sets who can open the deployed app, and the options you see depend on your plan and on the Deployment Protection settings in Vercel (v0's deployment guide doesn't list them).

Decide before you share the URL, since the setting applies to the production link. You can change it later under Project menu > Settings > Vercel Project.

For an internal tool, choose a protected option now (Vercel recommends Vercel Authentication, which allows only users with deployment access to view the site) and review the Deployment Protection settings in the production settings section below.

Step 3: Choose a vercel.app or custom domain

You can use the provided vercel.app domain, a custom domain you connected, or one you added in Vercel.

A .vercel.app domain is free and ready as soon as you publish, with HTTPS already configured. A domain you own, such as myapp.com, needs DNS records at your registrar, set up from the Vercel dashboard.

Manage domains under Project menu > Settings > Domains, or through Publish > Customize Domain.

Start with the vercel.app domain and attach the custom one once the build passes (that way a DNS mistake can't be confused with a build error).

Step 4: Start the production deployment

Commerce projects get one extra check before the deployment starts, where you review any unclaimed Stripe test sandbox or Shopify development store and choose whether to claim it (v0's guide doesn't say what claiming changes).

Review the settings and start the deployment. A deployment card shows build progress and links to the deployed site and the commit. Two more links open the Vercel inspector and the logs.

Tip: Keep the logs link open while the build runs. If the deployment has errors or warnings, select Fix with v0 or Fix Build.

Step 5: Update the app with Publish Changes

After the first publish, open the Publish menu, review the deployment and domain, then choose Publish Changes.

Without GitHub, v0 deploys the current code directly to the connected project. With GitHub, it creates or reuses a pull request and merges it into the base branch, then waits for production.

The production URL stays the same between updates.

If the Publish button is disabled, the chat usually has nothing new to publish or your account lacks the roles above. A team deployment policy can also block it (see the policies section below). To rule out the first cause, ask v0 for a small code change.

How do preview and production deployments differ in v0?

Previews come from working branches and get unique URLs, while the production version serves your project's domains. Publishing from v0 updates production, and on GitHub-backed projects a merge into the production branch does the same.

Variables behave differently in preview and production. The v0 preview can only read Development environment variables, and v0's docs say sensitive variables are unavailable to previews.

Vercel now allows Secrets in Development, which the preview reads, so give each environment its own value and keep production credentials out of that scope. Teams can enforce separate values with Vercel's optional Separate Production Secret Values policy, which an Owner turns on.

How do you take v0 to production with GitHub?

Connecting GitHub makes the repository the authoritative copy of your code and turns Publish into a pull request merge. Vercel's launch post for the new v0, dated February 3, 2026, describes this flow, with a branch per chat and pull requests against main that deploy on merge.

How to connect and publish:

1. Open Project menu > Settings > GitHub and select Connect. Choose the Git Scope (account or organization) and name the repository, then select Create Repository. v0 creates a private repo and pushes the current code.
2. To start from an existing repo, use Import from GitHub. The Vercel GitHub App must be installed for the account or organization that owns the repo, or the repository won't appear in Import from GitHub.
3. Make a code change. v0 creates a working branch on the first change and pushes there, leaving the base branch untouched. Each working branch gets its own Vercel preview.
4. Read the preview and CI status in the branch menu, select Publish, confirm the domain and visibility, then select Publish again. v0 merges the pull request into the base branch and waits for production.

The merge triggers a production deployment when the base branch is your project's production branch, which Vercel sets to main by default. After a publish, the next code change in that chat starts a new working branch.

Branch protection still applies. Required checks, required reviews, and draft pull requests can block the merge. When they do, v0 leaves the pull request open and links to it with an explanation of the issue. Human approvals have to happen in GitHub, because v0 can't supply them.

Because the repo holds the authoritative copy of the code once it's connected, v0's docs warn that code may be unrecoverable if the repo is deleted, so be sure before you remove it.

Which production settings are managed in Vercel?

Environment variables, Deployment Protection, and team deployment policies are managed in the Vercel project. v0's docs also send DNS, redirects, and other advanced domain settings to the Vercel dashboard.

Environment variables

Vercel scopes each variable to Production, Preview, Development, or a custom environment. In v0, manage them under Project menu > Settings > Environment Variables.

Hardcoded secrets in generated code are the second of the seven risks in our vibe coding security guide, so use the Secret type for API keys. Secret values are write-only after you save them, while Config values stay readable to members with project access.

Changes apply only to new deployments; publish again after editing a production variable.

Deployment Protection

Standard Protection covers every URL except your production domains, and All Deployments protects those too. Both are available on all plans.

You can add a protection method on top of either scope. Vercel Authentication, the method Vercel recommends, is available on all plans and allows only users with deployment access.

The other three methods depend on your plan. Password Protection costs $20 per month per protected project on Pro and isn't available on Hobby. Passport (sign-in through your identity provider) and Trusted IPs (access limited to approved IP addresses) need Enterprise.

Team deployment policies

A team policy can block v0 from publishing. Deployment Policies control, per environment, which Git sources and mechanisms can deploy. They're available on Pro and Enterprise, and only the Owner role can configure them.

The Deployment Sources list includes a v0 source, covering releases from v0 projects without a Git connection. For a GitHub-backed project, review the Git Sources rules and make sure Git is allowed in that list.

If a policy blocks v0, a team Owner must allow the source or override the policy for the project.

What to do when a v0 deployment fails

Start at the deployment card from step 4, which has the logs and the Vercel inspector.

Work through these in order:

1. Fix with v0 or Fix Build. When a deployment has errors or warnings, Fix with v0 sends the error logs to v0, which reads them and applies a fix. On GitHub-backed projects, the branch menu also shows Fix CI, Fix Conflicts, and Fix CI + Conflicts.
2. Read the logs. Open the Vercel inspector from the deployment card for build and runtime logs.
3. Check the connection. If a pull request or branch fails to create, confirm your GitHub connection is active and the repository is reachable. For persistent errors, v0's FAQ points to Vercel support at vercel.com/help.
4. Match the domain. If a domain doesn't show up, it has to belong to the connected Vercel project. Unverified domains need verification in Vercel first.
5. Rule out policies and reviews. A team policy that blocks v0 needs an Owner to change it, and a required review needs a person to approve it in GitHub.

Fix with v0, the first step above, has a cost limit. Paid plans get a daily allowance of free fixes on unedited code (v0's guide doesn't give the number), and once that runs out, fixes use credits like a normal prompt.

Common mistakes to avoid

Three mistakes are easy to make here. A variable scoped only to Development works in the v0 preview and fails in production, so scope the key to Production as well.

The second one sits in visibility. Standard Protection leaves production domains public, which means an internal tool needs All Deployments before you share it.

The third comes after an edit. A changed variable does nothing until you publish again, because the running deployment holds the old value until a new one goes out.

Deploying a v0 app on internal data with Superblocks

If IT requires an app that reads internal data to run inside your own network, you need a deployment route outside v0's Publish flow, which targets Vercel.

If v0 isn’t the right fit for a production internal app, compare other builders in our guide to v0 alternatives.

One such route is Superblocks, which imports v0 apps and runs policy checks on them at import. Our post on app imports covers the flow, and the guide to AI app builders versus platforms compares the two. 

To deploy a v0 app on internal data, Superblocks adds:

• v0 import: Click Import and upload the app, and Superblocks says the UI carries over with its business logic (announced May 27, 2026).
• Pre-production scans: Policy agents check imported apps for exposed API keys, vulnerable packages, and supply chain risks. Token exchange or service accounts can replace personal API keys.
• In-network deployment: Hybrid runs the data plane in your AWS, GCP, or Azure account, while the control plane stays in Superblocks Cloud. Cloud-Prem runs the full platform, including inference, in your own cloud (AWS, GCP, or Azure), as the deployment overview describes.
• Access and audit: RBAC is included in Teams, while SSO/SAML/OIDC and audit logs are Enterprise features, as are the Admin MCP and VPC deployment.

Teams costs $125 per month, billed monthly, or $100 per month billed annually. It includes 100 Governed Agent Units a month and up to 15 builders, with 1 hosted app per Team and RBAC. Extra hosted apps cost $10 per app per month.

In-network hosting through VPC deployment starts at Enterprise. Enterprise uses custom pricing.

On compliance, Superblocks states that it is SOC 2 Type II certified and HIPAA compliant.

Start a 14-day free trial on Teams, or book a demo to plan the VPC setup that in-network hosting needs. Our checklist for deploying vibe-coded apps covers apps from other builders.

Frequently asked questions

How do you deploy a v0 app?

You deploy a v0 app by clicking Publish in the chat header. v0 then asks for the Vercel project, visibility, and domain before it starts the production deployment.

Can you deploy a v0 app for free?

Yes, with limits. Plus costs $30 per user per month and Business costs $100 per user per month. The page doesn't state the billing cycle. The Free plan costs $0/month and lists "Deploy apps to Vercel," with a 7-message-per-day limit.

Can you download a v0 app's code and host it elsewhere?

Yes. v0's FAQ says you can export the code and deploy elsewhere. The changelog lists Download ZIP in the project menu, and connecting GitHub pushes each code change to a working branch in your repository.

Why isn't your v0 deployment updating?

A v0 deployment doesn't update when the chat has no new changes, when a GitHub check or required review blocks the merge, or when a team deployment policy blocks v0. The branch menu shows deployment status and CI checks, and the deployment card shows the build state.

Can Superblocks deploy a v0 app inside your own cloud?

Yes. Superblocks imports v0 apps, and VPC deployment is available on the Enterprise plan. Hybrid puts the data plane in your cloud account, while Cloud-Prem runs the full platform, including inference, in your own cloud (AWS, GCP, or Azure).