Is your Bolt.new app production-ready?

By Aakshar Garg, Co-founder, Fixier · Last reviewed July 27, 2026

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.

Is my Bolt.new app secure?

It turns on two answers. First, whether any secret carries the VITE_ prefix — Vite bundles those into the browser at build time regardless of how sensitive the value is. Second, whether the service holding your data enforces its own access rules, because Bolt's deployment target can't host a traditional backend and therefore can't enforce them for you.

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 launching a Bolt.new app?

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 thirteen layers below are the full pass.

The 13-layer production check

Every audit we run walks the same thirteen layers, in this order. Each one is a question you can answer about your own app today — no tooling required.

1
Frontend foundationsDoes it break in front of the customer?
error boundaries on every route, image and bundle optimisation, a console that's clean on a live load
2
APIs & backend logicDoes your server trust whatever it's sent?
input validation on every endpoint, verified webhook signatures, idempotent writes, errors that don't leak stack traces
3
Database & storageCan a query be made to return someone else's rows?
parameterised queries, tenant isolation in the database, CVEs in the ORM and driver, a backup policy that exists
4
Auth & permissionsCan a stranger reach something they shouldn't?
the session checked on the server before data is returned, reset and verification flows, lockout, re-auth before destructive actions
5
Hosting & deploymentIf today's deploy is wrong, can you undo it?
a staging or preview environment, a written rollback path, env vars separated per environment, HTTPS and HSTS enforced
6
Cloud & computeWhat's the bill at a hundred times this traffic?
budget alerts, documented platform limits, a ceiling on AI and inference spend
7
CI/CD & version controlWhat stops a bad change reaching customers?
lint, type-check, test and build on every push, branch protection on main, an automated CVE gate, no pre-release packages in production
8
Security & RLSCan one customer see another customer's data?
row-level security, a scan for committed secrets, live penetration probing for injection and XSS, CSP and framing headers
9
Rate limitingCan one person hammer sign-in — or checkout — all night?
limits on sign-in and sign-up, on payment routes, and on every endpoint that writes
10
Caching & CDNCould one customer be served a page cached for another?
no-store on authenticated responses, cache keys that can't cross users, a revalidation strategy someone actually chose
11
Load balancing & scalingWhat happens when everyone arrives at once?
database connection pooling, a horizontal scaling path, a load test we run at the traffic you expect
12
Error tracking & logsWould you know it broke before a customer told you?
error tracking in the browser and on the server, structured logs with levels, alerts on the paths that matter
13
Availability & recoveryIf the data went wrong today, could you get it back?
a health endpoint, external uptime monitoring, an incident playbook, a restore you have actually run

Each layer in full — what it means, how to test it yourself, and the fix: the 13-layer production check.

Sources

Every claim above about a third-party tool was checked against that tool's own documentation on July 27, 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 thirteen 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.