Is my Bolt, v0 or Replit app production-ready?

What does Bolt check?

Bolt offers a project security audit on paid plans that reviews code and database, fixes what it can and flags the rest, plus a database security check on all plans. Both are started by you from the Publish menu, up to 30 audits a day; neither runs on its own and neither blocks publishing.

Bolt's support documentation describes two tools. The project security audit reviews your whole project, including your code and database, fixes what it can, and flags anything you need to handle, uses no tokens, and is available on paid plans. The database security check flags issues with your database settings so you can ask Bolt to fix them and is on all plans. Bolt recommends running a security check at least once before you publish, from the Publish button, and caps audits at 30 a day.

What that leaves: everything outside the project. Bolt hosts on a bolt.host subdomain and the grade recognises it as a platform subdomain, so you can grade before attaching a domain. The checks Bolt's own tools do not reach are the same as for every builder, listed below.

What does v0 check?

v0 warns when code uses a NEXT_PUBLIC_ variable in a way that could expose a secret, and can move that code to a route handler or server action. It has no security scan or pre-publish audit in its documentation; it deploys to Vercel, where previews get unique URLs and production has a stable one.

v0's security page says it analyzes NEXT_PUBLIC_ usage and warns users about potential security risks, that the AI can move code to Route Handlers, Server Actions or other server-side contexts, and that server-side code becomes Functions in isolated sandboxes on deploy. That is a real guard against the single most common secret leak, the public prefix on a private value, and it is the only check the documentation describes.

So a v0 app arrives at Vercel with no verdict on its database policies, its headers, its routes or anything at the domain. The preview URL guide covers grading the vercel.app address, including behind deployment protection, and vercel-env-hygiene reads the project's environment on your own machine for trailing newlines, unscoped values and secrets under public names.

What does Replit check?

Replit runs free automatic dependency scans against public vulnerability records, offers Agent security scans for insecure code patterns, privacy issues and architectural flaws on paid plans, and since July 2025 gives each published app a production database the Agent cannot modify. Its docs say a scan is not a complete security review.

The security documentation lists automatic dependency scans that check project packages against public vulnerability records, free and automatic, and Agent security scans for paid builders that identify insecure code patterns such as SQL injection, cross-site scripting, and cross-site request forgery; privacy issues such as sensitive data flowing to logs or third-party APIs; and architectural vulnerabilities in routes, APIs, and data flows. The same page adds: A scan is not a complete security review. Scans are started by you, not run on publish.

The change that followed the July 2025 incident, in which an agent deleted a production database during a code freeze, is structural rather than a scan. Replit's announcement says apps had used a single database for both development and live customer data, and introduced separate development and production databases. The documentation now states that Agent is not able to modify the production database, and that point-in-time restore holds 7 days of history on Core and 28 on Pro and Enterprise. That closes the agent-destruction class on Replit; it says nothing about the other four in the ledger.

What does none of them check?

The outside view. No builder reads your live domain the way an attacker or a customer does: the sending domain of your sign-in emails, the Stripe key mode in the page, whether a missing page answers 404, the headers, the registration expiry, a request to your API with no credential, and whether any of it regressed since the last deploy.

Every builder scans its own output and stops at its wall, and every one says so. The seams are where launches fail, and the grade reads all of them in one pass:

Email

auth-sender-authenticated, spf, dkim, dmarc: the domain your magic links come from, and whether it is authenticated.

Payments

stripe-test-key-in-prod on the page; stripe-webhook-wiring with your own key on your machine.

Domain

domain-expiry, https-redirect, tls-expiry, nameservers.

Headers

csp, hsts, x-frame-options, cookie-flags, cors-wildcard-credentials.

Routes

open-admin-routes, rate-limit, supabase-anon-row-read: what answers an anonymous request.

Pages

not-found-page, legal-pages, analytics-present, ai-leftovers.

Time

Re-grading on every deploy with history, so a header or a policy that regresses is noticed the day it happens.

Production-ready is a verdict on the live URL, and it is one the builder cannot give. Run the builder's scan, fix what it finds, then grade the URL from outside and fix what that finds. The launch checklist is the order to do it in.