Is your Bolt.new app production-ready?
By Aakshar Garg, Founder, Scalable Systems · Last reviewed
the short answer
Often close, with two things to check first. Anything your front end reads from a VITE_-prefixed variable is compiled into the JavaScript you ship — Vite's own docs say those must not contain sensitive information like API keys. And Netlify, Bolt's quickest deploy path, can't host a database or a traditional backend, so your data lives somewhere that needs its own access rules.
Bolt is fast at getting a working app in front of you, and the app you see in the preview is genuinely running. The gap tends to open at the boundary between that preview and a real deployment: where secrets live, what the browser can be trusted with, and which parts of your stack the host isn't running at all.
What we find in Bolt apps
| What breaks | What you'd notice |
|---|---|
A secret in a VITE_ variablecritical | The key is compiled into your JavaScript at build time. Anyone can open DevTools and read it — no hacking involved. |
| Database reachable from the browser with no row rulescritical | The front end talks to the database directly and the database allows it, so one customer can read another's records. |
| Validation only in the browserhigh | Your form requires a positive quantity; a request sent without your form doesn't. Prices, quantities and roles can be edited on the way out. |
| Works in the preview, breaks once deployedhigh | Environment variables, redirects, or routes that were set in the builder aren't configured on the host, so the live site fails where the preview didn't. |
| No rate limitinghigh | Nothing between a script and your signup, login or search endpoint. |
| No error trackingmedium | Errors happen in your users' browsers and never reach you. |
Is Bolt.new production-ready?
Bolt produces real, deployable applications — the question is what you added around them. In practice the readiness of a Bolt app comes down to three things: whether any secret ended up in the client bundle, whether the database enforces who can read what, and whether the server (not the browser) validates anything that matters.
Are my environment variables exposed in a Bolt app?
The ones prefixed VITE_ are, by design. Vite's documentation is unambiguous: variables prefixed with VITE_ are exposed in client-side source code after bundling, and they should not contain sensitive information such as API keys, because the values are baked into your source at build time. Variables without the prefix stay server-side.
Check yours in about a minute. Deploy, open the site, open DevTools → Sources, and search the bundle for a distinctive fragment of the key. If it's there, it's public, and rotating it is the first move — not just deleting it from the code, since the old value is already out.
Where should secrets actually live?
On something the browser can't read: a server, an edge or serverless function, or your platform's secret store. Bolt has a secrets area under Settings → Secrets for values you don't want in source. Vite's docs make the same recommendation — use a backend or serverless functions to secure secrets properly.
The rule of thumb that survives every stack: if a value would let someone spend your money or read your data, it needs to sit behind code you control, with the browser calling that code instead of the third party directly.
Why does my app work in Bolt but break after deploying?
Because the preview and the deployment are two different environments with two different configurations. Variables, redirects and any server-side routes must exist on the host too, and values compiled in at build time freeze whatever was set when the build ran.
Can Netlify host my backend?
Not a traditional one. Bolt's own deployment documentation states plainly that Netlify can't host your database or a traditional backend. That's not a limitation you have to fight — it just means your data and privileged logic live in a separate service, and that service is where your access rules have to be enforced.
If that service is Supabase, the rules are row-level security policies, and the Supabase RLS checklist is the next thing to read.
What should I check before launch?
Search your deployed bundle for keys, then confirm your database rejects a request for someone else's row, then make sure anything money-related is validated on the server. Those three cover the failures that actually cost money. The seven layers below are the full pass.
The seven-layer production check
Every audit we run walks the same seven layers, in this order. Each one is a question you can answer about your own app today — no tooling required.
- 1
AccessCan a stranger reach something they shouldn't?
authentication, session handling, ownership checks on every route
- 2
TenancyCan one customer see another customer's data?
row-level security, tenant scoping, IDOR on every id in a URL
- 3
SecretsWhat's shipped in the browser that shouldn't be?
keys in the client bundle, service-role credentials, token scope
- 4
Money pathsCan a customer be charged twice — or not at all?
idempotency, webhook retries, payment state reconciliation
- 5
Load and costWhat happens at a hundred times this traffic, and what's the bill?
N+1 queries, missing indexes, unbounded jobs, runaway spend
- 6
ObservabilityWould you know it broke before a customer told you?
error tracking, structured logs, alerting on the paths that matter
- 7
RecoveryIf the data went wrong today, could you get it back?
backups you've actually restored, reversible migrations, rollback
Sources
Every claim above about a third-party tool was checked against that tool's own documentation on July 26, 2026. These products change fast — if you spot something out of date, tell us.
Related guides
Want someone to actually check?
We audit AI-built apps against all seven layers and hand back a report in plain English — with the technical detail underneath for whoever fixes it. Startup-friendly pricing, scoped to your project.
Book an Audit