How to Deploy a v0 App (and What to Check Before Real Users Arrive)

v0 is Vercel's AI app builder. You describe an interface or an app, v0 writes it, and a preview runs next to the chat. When you're happy, there's a Publish button, and your app is live.

For a lot of people that's the whole story. But "live" and "ready for real users" aren't the same thing, and at some point you may want the app somewhere other than where it started. This guide covers both.

v0 changes quickly — it shipped Git integration, a code editor, and database connections in early 2026. Details here reflect the product as of September 2026; check v0's documentation for current specifics.

What a v0 app actually is

Under the chat, v0 generates a standard Next.js application using React, TypeScript, Tailwind CSS, and the shadcn/ui component library. That's worth knowing for two reasons:

It's ordinary code. Any developer who knows Next.js can work on it, and it can run anywhere Next.js runs.
Next.js is made by Vercel, so the path of least resistance — and the one v0 is built around — is hosting on Vercel.

If your app stores data, it's typically connected to an external database provider through Vercel's integrations, with connection details supplied as environment variables in the Vercel project.

Path 1: Publish to Vercel

Click Publish. v0 deploys the app to Vercel and gives you a URL. You can add a custom domain from the Vercel project afterwards.

Good for: prototypes, landing pages, internal tools, and a large share of real production apps. Vercel is a mature host, and a Next.js app on Vercel is about as well-supported a combination as exists.

Watch for: usage-based pricing. Vercel's plans include allowances for bandwidth, function execution, and similar resources, and a busy app — or a traffic spike — can move you onto usage charges. Check the current plan limits against what you expect before launch, and set spend alerts.

Path 2: Connect GitHub and work like a team

v0 can sync with a GitHub repository. With the Git integration, each chat can work on its own branch, and changes go to main through pull requests rather than being pushed straight to production. Connected to a Vercel project, every pull request gets its own preview deployment, and merging deploys to production.

This is the setup to move to once real users depend on the app:

Your code has a home outside v0. GitHub is your history, your undo button, and your exit.
Changes are reviewable. Someone (or something) can look at a pull request before it reaches users.
Developers and v0 can work on the same codebase. A developer can fix something by hand in a normal editor, and you keep iterating in v0.

If this pull-request-per-change workflow is new to you, Preview Environments for Every Branch explains why it's worth having.

Path 3: Host it somewhere other than Vercel

v0 lets you export the code, and a Next.js app runs anywhere Node.js does. Reasons people move:

They want predictable flat pricing rather than usage-based billing.
The app needs long-running work — background jobs, queues, websockets, scheduled tasks — that fits awkwardly into serverless functions.
They want the database and the app on the same infrastructure.
They want to keep building with an AI agent that can run the whole app, not just edit its files.

The mechanics are simple:

npm install
npm run build
npm start          # serves the production build on $PORT

For container-based hosts, Next.js has a standalone output mode (output: 'standalone' in next.config) that produces a minimal server you can put in a Docker image.

What to check before you move

Most of a v0 app moves without changes. The parts that don't are the ones tied to Vercel's platform:

Vercel-specific packages. Search for imports starting with @vercel/ — storage, analytics, edge config, and similar. Each needs a replacement or a self-hosted equivalent.
Scheduled jobs. Cron jobs defined in vercel.json are run by Vercel. Elsewhere, you need your host's scheduler.
Environment variables. They live in the Vercel project, not in the code. Copy every one to the new host (vercel env pull downloads them to a local file). Missing variables are the number-one cause of apps that work on one host and not another — see Why Does My App Work Locally but Not in Production?.
Image optimisation and caching. These work when self-hosting Next.js, but they run on your server and use its CPU, memory, and disk rather than Vercel's.
The database. If it was attached through a Vercel integration, it's a normal database account with the provider. You can keep using it from the new host, or migrate the data to a database alongside the app.

Test the production build on the new host before changing your domain's DNS. Then switch DNS and watch the logs for a day.

The production checklist, wherever it lives

The hosting path matters less than these:

Secrets stay on the server. In Next.js, any variable prefixed NEXT_PUBLIC_ is bundled into the JavaScript every visitor downloads. API secrets, database URLs, and payment secret keys must never have that prefix. See How to Keep API Keys Out of an AI-Built App.
Server actions and API routes check who's asking. An API route is a public URL. If it reads or changes data, it has to verify that the logged-in user is allowed to, on the server — hiding a button in the interface protects nothing.
Database access is restricted. If your database provider exposes data directly to the browser (as Supabase does), row-level security must be on for every table.
Your domain is connected, with HTTPS working. New to DNS? How to Connect a Custom Domain to Your App.
Backups exist and you've restored one. Know what your database plan actually keeps, and for how long.
Payments, if any, are in live mode and tested with a real card. And they follow the four rules for Stripe.
You'll hear about errors. Something that notifies you when the app throws, rather than a user emailing you a week later.
Code is in GitHub. Whichever path you chose.

Run through the broader Security Checklist for Vibe-Coded Apps too. v0 writes competent code, but an AI builder optimises for "it works in the preview," and several of those checks are things a preview can't catch.

Which path should you choose?

Validating an idea? Publish to Vercel and move on. Don't optimise hosting for an app nobody has used yet.
Real users, and Vercel's model suits you? Stay on Vercel and connect GitHub so changes go through pull requests.
Need long-running processes, flat pricing, or the app and database together? Export and move to a host that runs the whole application.

All three are legitimate. The mistake isn't picking the "wrong" host. It's shipping without the checklist.

EasySpawn runs the whole application — Next.js server, managed Postgres with daily backups, automatic SSL on your own domain — on flat monthly pricing, with Claude Code working against the running app rather than a preview. See how it works for AI-built apps or join the waitlist.