Is v0 by Vercel Production Ready? (And How to Check Yours)

Yes, v0 can build a real production application. No, publishing one does not make it production ready. Since the February 2026 rebuild v0 generates full-stack Next.js code and deploys it on Vercel; whether your app is safe to hand a stranger depends on auth, spend limits, tests, and rollback, none of which the preview checks.

v0 by Vercel can now generate, preview, and deploy a real full-stack application. It supports server-side code, API routes, databases, environment variables, Git branches, pull requests, and production deployments. These are credible production building blocks; the generated app still needs its own readiness evidence.

A specific v0 app is ready for production only after its authorization, data boundaries, payments, failure handling, dependency updates, monitoring, and release path have been verified. Both v0-origin apps in the AxonBuild audit corpus came back red, at 57 and 56 out of 100, and neither failure was visible in a screenshot. The preview can establish that the app runs in a production-like runtime. App-specific testing must still cover multiple users, hostile requests, partial failures, and the next code change.

The short verdict: four meanings of production ready

This distinction resolves much of the disagreement around the query. Someone calling v0 production-ready may mean it creates deployable code. Someone saying it is not may mean the resulting business system has not been tested. Both statements can describe the same app at different layers.

Is my v0 app production ready? A ten-minute self-check

Ten minutes, a browser, and two test accounts. Every step ends in a fact rather than an opinion, and you do not need to read the generated code to run any of them.

1. 01 Open a private window and paste a URL you can normally only see when signed in. If the page loads, that page is public.
2. 02 Sign in as a second test account and change a record ID in the URL to one the first account owns. Anything other than an error or an empty result is a data leak.
3. 03 View source on the deployed app, search the JavaScript for NEXT_PUBLIC_, and read what sits next to each match. Any value shaped like a key is already public.
4. 04 Call an AI, export, or email route with no session at all. If it answers, a stranger can run that route and you get the invoice.
5. 05 Check the Vercel plan. Hobby deployments pause after the included free-tier usage is exhausted. Pro and Enterprise deployments continue into on-demand usage by default. On Pro, set a spend amount and enable production-deployment pausing if you want that action.
6. 06 Open the GitHub repository settings and confirm the main branch is protected and a pull request is required before a merge.
7. 07 Name the last deployment you could roll back to, without looking it up. If you cannot name it, you do not have a rollback.

A step that fails here is not hypothetical. It is the specific thing that breaks first, and the rest of this page explains why each one matters and what to do about it.

v0, v0.app and Vercel: what is actually what

Three names, one product and one platform. v0 is Vercel’s AI app builder, v0.app is the address it lives at, and Vercel is the company behind it and the infrastructure your app deploys to. They are not competing choices, and v0.dev now redirects to v0.app.

The v0 documentation describes the product as “an AI agent that helps anyone create real code and full-stack apps and agents”, and describes publishing as one click to infrastructure powered by Vercel. So “v0 vs Vercel” is not a choice anyone has to make: v0 writes the app, Vercel runs it. v0.dev was the original address and returns a redirect to v0.app today, so a bookmark saved in 2024 and a link shared in 2026 land on the same product.

The accounts are shared and the bills are not. The v0 FAQ says a Vercel account is what gives you access to v0, so there is one login for both. Spending is metered in two separate places: your v0 plan burns credits when you generate, and your Vercel project bills for what the deployed app uses. That is why an app can be cheap to build and expensive to run.

Ownership sits with you. The same FAQ states that “Vercel doesn’t own the code generated based on your queries and prompts”, and that you can export the code and work locally, so hosting somewhere else stays available even though one-click publishing goes to Vercel. For readiness that matters in one specific way: the thing to keep safe is a repository you can move, not an account you rent.

The practical consequence is where the controls live. Once an app is published, its production behavior is a Vercel deployment’s behavior, so spend limits, deployment protection, logs, and rollback are set in the Vercel dashboard rather than in a v0 chat. And if your real question is whether the service itself is unavailable rather than whether your app is ready, that is a status question with its own answer path; the guide to what to do when an AI builder is down or not responding covers checking the vendor status page before you start debugging code that was working an hour ago.

What changed in v0 in 2026

Older descriptions of v0 as a frontend-only component generator are no longer accurate. Vercel’s current full-stack app documentation says v0 can create Next.js server actions and API routes, connect databases and other services, and add authentication and backend logic.

The February 2026 update changed the preview model too. According to the current v0 FAQ, previews run the full application in an isolated Vercel Sandbox, including server-side code, API routes, database connections, and environment variables. The sandbox documentation says this replaced the older browser preview that could not run those features.

That is a material improvement. A preview can now catch build errors, runtime failures, broken server routes, and integration mistakes that an interface-only sandbox could never expose. The preview may also interact with real external services if those services and credentials are connected, which increases the importance of test data and environment boundaries.

What does a successful v0 preview actually prove?

A successful preview is evidence that one version of the application starts and completes the paths you exercised in its sandbox. It can prove that the server route ran, the configured database answered, and the interface handled the returned result.

It does not automatically prove any of the following:

Those are properties of the generated app and its operating process. A platform can make them easier to implement, but only app-specific evidence can confirm them.

Two of those bullets name exact strings worth searching for. The Supabase service_role key carries Postgres’s BYPASSRLS attribute, so it skips every policy you wrote, and Supabase’s API key documentation says never to use it in a browser, even on localhost. Any variable prefixed NEXT_PUBLIC_ is inlined into the JavaScript bundle at build time and shipped to every visitor, so a secret behind that prefix is already public and has to be rotated rather than hidden. If the app is on Supabase, the toggle being on is not the evidence; testing the policies with a second account is.

A v0 preview can prove that the full stack runs. It cannot prove every user is allowed to make every request the stack accepts.

GitHub is the safest boundary between prompting and production

v0’s current GitHub workflow creates a branch for each chat, commits generated changes automatically, and does not push directly to main. A pull request can then be reviewed and merged. Once connected, the GitHub repository becomes the source of truth, and v0 does not retain a separate recoverable copy if that repository is deleted.

That workflow gives teams a useful production gate, but the gate only works when a merge requires evidence. Configure branch protection so a pull request cannot merge until the build, type checks, critical tests, and required review pass. Keep backups and repository ownership independent of a single person’s account.

Without GitHub, v0 can publish directly to production. That route is convenient for low-risk experiments. For an app with users or important data, require a reviewable commit and a reproducible deployment before a change reaches the production URL.

Does Vercel hosting make a v0 app secure?

Vercel provides infrastructure controls such as deployment protection, a web application firewall, observability, log drains, caching, and spend management. Its own production launch checklist also recommends application work including security headers, pinned lockfiles, rate limiting, tracing, load testing, rollback planning, and cost alerts.

That checklist is useful because it separates hosting from readiness. The platform itself is sound; Vercel is a safe place to host, and that is a different question from whether your app is safe on it. Automatic HTTPS and a global CDN can be working perfectly while an API route still returns the wrong customer’s data. A firewall can absorb some abuse while an unmetered model endpoint still accepts expensive authenticated requests. Platform controls and app controls cover different failure paths.

The same applies to dependencies. v0 defaults to Next.js, and the version recorded in the lockfile becomes part of the app you own. The clearest historical example of what that ownership means is CVE-2025-29927, a critical authorization bypass in Next.js middleware. Middleware is often the only wall in front of every protected route in a generated auth flow, and a request carrying the right header walked straight past it, no credentials required. The advisory lists every 15.0.x through 15.2.2 release as vulnerable, along with older lines back to 11.1.4; the fix lands at 15.2.3, with 12.3.5, 13.5.9, and 14.2.25 patching the earlier branches. Vercel-hosted Next.js deployments were automatically protected from this vulnerability. Self-hosted deployments and deployments on other platforms still needed a patch or the documented workaround. Host-level protection does not update the lockfile or follow the app to another host. Eight of the 21 third-party apps in the AxonBuild corpus ran a framework version carrying a reachable RCE or auth-bypass, most of them inside that same middleware window. Where it applies, the entire fix is one version string:

{
  "dependencies": {
-   "next": "15.2.2"
+   "next": "15.2.3"
  }
}

The corpus carries a matching caution against overreacting to a scanner: in three of the 21 apps, an automated scan flagged 33 to 44 vulnerabilities and not one traced to something reachable in the code. Counting CVEs and knowing which ones matter are different skills. Review direct and transitive dependencies, check whether reported vulnerabilities are reachable in your code, and schedule updates after launch; dependency maintenance is a continuing production task, not a one-time patch.

Why a v0 launch can produce a bill you did not plan for

Vercel handles the limit differently by plan. Hobby deployments pause after they exceed the included free-tier usage. Pro and Enterprise deployments do not stop automatically at 100% usage, so they can continue into on-demand usage. On Pro, Spend Management can notify you or take action at a chosen amount. Setting the amount alone does not stop usage. Pausing production deployments is a separate action that an Owner or Billing role must enable.

Even switched on, it is a brake rather than a wall. Vercel checks metered usage every few minutes rather than continuously, so notifications, webhooks, and project pausing can fire several minutes after you cross the amount, and the docs advise setting the amount below the maximum you are actually willing to spend. Notifications go out at 50, 75, and 100 percent of that amount.

The fastest way to reach that number is a route that costs money and does not check who is calling. The lower-scoring of the two v0 apps we audited had three of them, all AI routes open to anyone who knew the URL. Nothing about that is visible in the interface, and the preview ran them without complaint because the preview was signed in as the owner. A stranger runs the model; the owner gets the invoice. Function invocations and image optimization on a public page do the same thing more slowly.

Three controls, in this order, before launch:

1. Authentication and a per-user rate limit on every route that calls a model, sends an email, writes a file, or exports data. This is the only one that fixes the cause.
2. A plan-specific spending boundary. Hobby pauses after included usage. On Pro, set a spend amount below your real ceiling and enable production-deployment pausing. On Enterprise, record the billing control that applies to your account.
3. A usage alert that reaches a person, not a dashboard nobody opens.

There is a second budget in play. v0’s own plans are credit-metered, with $5 of included monthly credits on the free plan and $30 of included credits per user on Plus, and running low is what pushes people to ship the first version that compiles. That is a budget decision, not an engineering one, and the parts left unfinished are almost always the failure, permission, and recovery cases.

The plan page is worth reading once before you start, because the free tier is built for evaluation rather than delivery. As of August 2026 v0’s pricing lists Free at $0 a month with $5 of included monthly credits and a seven message per day limit, Plus at $30 per user per month with $30 of included monthly credits plus $2 of free daily credits on login, Business at $100 per user per month on the same credit allowance, and Enterprise at custom pricing. Students with an email address at one of the listed schools can verify it for a year of free premium. All of that pays for generating the app. None of it pays for running the app, and running it is what produces the invoice nobody planned for.

What did two audited v0 apps score?

The AxonBuild audit corpus is not a controlled sample of v0 projects and cannot provide a v0 failure rate, but it does include two v0-origin builds, so the gap is not extrapolated from apps built somewhere else. Both came back red, scoring 57 and 56 out of 100. The 57 was a GDPR and HIPAA-styled compliance tool: its three AI routes accepted an anonymous POST with no login and no rate limit, so a stranger could run up the owner’s model bill at will, and its pinned Next.js release carried a separate, reachable remote-code-execution advisory, one patch behind the fix, sitting there because nothing automated ever bumps a dependency on its own. Neither number came from anything a screenshot would show.

The wider corpus provides context for the checks builders commonly skip: at least 23 of 26 audited AI-built apps had no working automated tests, and reliability and correctness was the lowest-scoring area across the 21 third-party apps.

That evidence supports checking whether tests actually run. Two red scores do not support claiming that v0 causes the gap. The broader mechanism is that a generated happy path can look complete before anyone has written the failure, permission, or recovery cases around it. The launch-readiness guide for AI-built apps covers that platform-independent question.

Bolt.new, another frontend-first generator, reaches a similar handoff from generated build to owned application through a different workflow. What makes code production ready in the fullest sense is a longer argument than any of these tools’ marketing pages. For v0 specifically, the fastest useful path is to prove the boundaries the full-stack preview cannot certify on its own.

Fix or rebuild: what the two audited v0 apps actually needed

Fix, in most cases. The decision rule is three lines long.

Rebuild when the data model or tenancy is wrong at the root, because every fix layered on top of it re-opens the same hole. Fix when auth, rate limits, dependencies, and monitoring are the gap, because those are additions to a working system rather than arguments with it. Both audited v0 builds, at 57 and 56 out of 100, were the second kind: the schema was coherent and the failures sat around it.

A fix pass runs in this order, and the order matters because each step makes the next one testable:

1. Get the code into a repository you control, protect the main branch, and require a passing check before merge. Without this there is nowhere to land a fix safely.
2. Close the money holes: authentication and rate limits on paid routes, then the spend amount and alert.
3. Close the data holes: policies on every table, secrets out of the client bundle, permission checks moved into server actions.
4. Bump the framework and any dependency carrying a reachable advisory, then set an update cadence.
5. Add error reporting that reaches a human, and one repeatable test per business-critical flow.
6. Rehearse a rollback and a restore before you need either.

Rebuilding to escape bad policies swaps a known problem for an unknown one, and the second version usually inherits the same authorization mistakes because the same prompts write it.

Where the production gap sits: v0, Lovable, Bolt.new

A production-readiness checklist for v0 apps

1. 01 Connect the project to a repository you control, protect the main branch, and require checks before merge
2. 02 Pin dependencies with a committed lockfile, check current advisories, and assign an update cadence
3. 03 Test every protected route with two accounts and direct requests, including reads, writes, files, admin actions, and exports
4. 04 Verify payment amounts, entitlements, and webhook signatures on the server, then test duplicate and out-of-order events
5. 05 Put authentication, rate limits, input limits, timeouts, and cost caps around AI and other paid API routes
6. 06 Use isolated preview or staging data and keys so a test cannot charge a customer or modify production records
7. 07 Add repeatable tests for sign-up, login, checkout, account deletion, and the highest-value business action
8. 08 Create a production error deliberately, confirm it is visible in logs and alerts, and document who responds
9. 09 Rehearse deployment rollback and data recovery before the first incident requires either one

The items are intentionally verifiable. Replace “v0 added auth” with a two-account authorization result. Replace “Vercel has monitoring” with a deliberate error that produced an alert. Replace “the preview worked” with a test that runs on every proposed production change.

Common questions about v0 production readiness

Is v0 any good?

Yes for what it is: a fast way to turn a prompt into a working full-stack web app, with a real preview, a Git branch per chat, and deployment attached. It is weakest at the parts no generator checks, which are authorization, spend limits, tests, and recovery. Both v0-origin apps in the AxonBuild audit corpus scored red on exactly those, at 57 and 56 out of 100, while both looked finished on screen.

What are the alternatives to v0?

The closest ones are Lovable, Bolt.new, Base44, Replit, and Figma Make, plus the code-first assistants Cursor, Claude Code, and Windsurf. The useful split is by what you end up holding: v0 and Bolt.new generate framework code you can export, Lovable and Base44 hand you an app on a managed backend, and Cursor, Claude Code, and Windsurf edit a repository you already own. None of them changes the list on this page. Every one of them produces an app whose authorization, spend limits, tests, and rollback are still yours to prove, so switching tools moves the work rather than removing it.

Is v0 good for production apps?

Yes, as a way to create and iterate on a real application. Its full-stack runtime, Git workflow, and Vercel integration are credible production building blocks. The generated app still needs app-level security, tests, monitoring, recovery, and ownership before real users should depend on it.

Can v0 build a full-stack app?

Yes. Current v0 supports Next.js server code, API routes, databases, authentication, external APIs, environment variables, and full-stack previews. Describing it as only a UI generator is outdated.

What it builds is a web app. If the goal is something a customer installs from the App Store or Google Play, that is a separate question about wrappers and native builds, and the mobile-app guide for AI builders answers it.

Are v0 previews the same as production?

They run the full app in an isolated Vercel Sandbox and are designed to behave like a Vercel deployment. They are still previews: traffic, data volume, concurrency, abuse, third-party failures, production permissions, and operational response can differ.

Does publishing from v0 make an app production-ready?

Publishing creates a production deployment and URL. Production readiness additionally requires verified authorization, safe data changes, tested business flows, observability, rollback, and a controlled path for later changes.

Why is my Vercel bill so high for a v0 app?

On Pro or Enterprise, a high bill often starts with a route that costs money and answers requests from people who are not signed in. AI calls, exports, image optimization, and function invocations are billed on usage, and those plans do not stop deployments automatically at 100% usage. Put authentication and a rate limit on every paid route first. On Pro, set a spend amount and enable production-deployment pausing if that is the action you want. Hobby deployments instead pause after the included free-tier usage is exhausted.

Should I fix my v0 app or rebuild it?

Fix it, unless the data model or the tenancy design is wrong at the root. If auth, rate limits, dependency versions, and monitoring are the gap, those are additions to a working system and a fix pass is faster and safer. Rebuild only when every fix would sit on top of a schema nobody can describe, because the same prompts tend to reproduce the same authorization mistakes in version two.

How long does it take to make a v0 app production ready?

Run the readiness checks before estimating. A single-user app with no payments may need less work when its controls are already present and testable; a multi-tenant app with roles, payments, and uploads requires each relevant boundary to be exercised across roles and tenants. Live customer data can add migration, rollback, and recovery work. Set the schedule only after the failed checks, affected paths, data state, and external dependencies are known.

Is v0-generated code secure?

The generated code is usually competent on the path it was asked to build and silent about the paths it was not. The recurring failures are the same ones across AI-built apps: a table without Row Level Security, a service key that reached client code, a permission check that only hides a button, and a paid route with no session requirement. Those are properties of your app, not verdicts about v0, and each one is testable in minutes.

Do I need a developer after building with v0?

Not for every change, but someone must own the resulting code and system. That owner needs to evaluate generated changes, dependencies, data migrations, security boundaries, incidents, and recovery. The responsibility exists whether the owner writes the first version manually or through v0.