Bolt.new to production
Bolt.new runs your whole stack inside a browser tab, which is why it feels like magic and why so much of what it builds breaks the moment it's deployed. Here is what we find in Bolt projects, and how we fix it while you keep building in Bolt.
Taking a Bolt.new app to production means closing the gap between the WebContainer it was built in and the host it runs on: third-party API keys that were called straight from the browser and shipped in the bundle, Netlify or Supabase functions with no auth check and open CORS, environment variables that existed in the preview and not in production, and a codebase with no tests or deploy pipeline. Gen2Prod fixes these in your repo by pull request, so you can keep iterating in Bolt; the audit is free and each fix is a fixed price from $290.
The list we find on most Bolt.new projects, in the order it matters. Each one links to the service that fixes it.
The fastest way to make an OpenAI or Stripe call work in Bolt is to call it from the client, and that's what it does. The key ends up in the bundle, and someone's script finds it within days. We proxy every paid call through a function that checks the caller first.
Fixed by Security hardeningGenerated Netlify Functions rarely check who is calling and usually answer with `Access-Control-Allow-Origin: *`. We add auth on anything that reads user data and rate limits on anything that costs money.
Fixed by Security hardeningEnvironment variables that lived in the WebContainer aren't on Netlify; a `VITE_` prefix exposes some and a missing one breaks others; the build step Bolt skipped fails in CI. We map every variable, per environment, and make the build reproducible.
Fixed by Deploy & CI/CDBolt's Supabase integration creates tables fast and, like every generator, leaves Row Level Security off or permissive. We write policies per table and test each one.
Fixed by Security hardeningRouting, state, fetching and markup in one file that grew with every prompt. We split it so the next feature doesn't break the last one — and so Bolt edits it more reliably.
Fixed by Refactor & cleanupNo error tracking, no uptime check, no logs you can read. We add monitoring and alerts so you hear about a failure before your customers do.
Fixed by Monitoring & alertsA cleanup isn’t a rebuild. Bolt.new did real work, and most of it stays.
Because the environment it was built in isn't the one it runs in. The usual causes are an environment variable set in Bolt but not in the Netlify dashboard, a serverless function that ran in the preview but wasn't deployed, a CORS rule that was open in the preview and blocked in production, or a build step that Bolt never actually ran. The free audit lists which of these applies to your project.
Assume not until someone has checked. Bolt frequently puts third-party keys into client-side code or `VITE_` variables, both of which are visible to anyone who opens your site's JavaScript. We scan the built bundle for secrets, rotate anything exposed, and move the calls behind a server function.
Yes. We work in the GitHub repo Bolt exports to, by pull request, and we leave a README describing the structure. Bolt handles a well-organised repo better than the one it generates, so you'll find it breaks fewer things per prompt afterwards.
Only when there's a reason — Netlify is a fine host for most Bolt projects. If your app needs a long-running server, a database in a specific region, or a framework Netlify handles poorly, we'll say so and move it; otherwise we add CI, preview deploys and monitoring around the host you already have.
Go deeper: Your AI app is leaking API keys. Here is how to find them
Start with the free audit. In 48 hours you'll know what's broken, what each fix costs, and whether it's even worth doing — before you've spent a dollar.
Free audit, no card · Fixed price before we start · Your code stays yours