Your Bolt app works in preview. Production is a different machine.
Bolt’s preview runs a full Node server inside your browser tab — which is amazing for building and quietly misleading for launching, because production hosting can’t run half of what the preview can. The result is the most-searched Bolt complaint there is: “works in Bolt, broken after deploy.”
Add the standard vibe-coding risks — secrets inlined into the public bundle, database tables without Row Level Security, payments left in test mode — and a Bolt launch needs a real checklist. Here it is: the one we run before any Bolt app goes live.
The 8 risks real Bolt apps ship with
Compiled from documented incidents, CVEs, and platform docs — the same failure modes a Launch Check hunts for in your app, with what to do about each.
-
Paid API keys shipped to every visitor (the VITE_ trap)
Bolt’s default output is a Vite SPA, and Vite inlines every VITE_-prefixed variable into the public JS bundle at build time. When you ask Bolt to “integrate OpenAI/Stripe,” the fastest working demo is a direct browser call — scans of vibe-coded apps repeatedly find Stripe secret keys, service_role keys, and billable OpenAI keys in Bolt bundles. Scraped keys have produced overnight four-figure bills.
What to do: Grep your built bundle for “sk-”, “sk_live_”, and “service_role”. Move every paid-provider call behind a Netlify Function, Supabase Edge Function, or Bolt server function with the key stored as a function secret — no VITE_ prefix. Rotate anything that was ever in frontend code; it’s already public.
-
Tables without Row Level Security — any visitor can read (or delete) everything
Bolt’s standard pattern has the browser talk directly to Supabase with the public anon key — RLS policies are your entire authorization model, and Bolt-generated migrations frequently omit them. A scan of 1,072 deployed vibe-coded Supabase apps found 98% had at least one flaw, including 172 sites allowing unauthenticated data modification, with exposed tables like “payments” and “admin_users”.
What to do: Fix every table showing the “RLS disabled” warning in the Supabase dashboard: enable RLS deny-by-default, write policies keyed on auth.uid(), then verify with two test accounts and a raw curl using only the anon key.
-
Your “backend” never existed in production
The preview runs a real Node server in-browser (WebContainers), so a generated Express server or websocket works while you build. But Bolt hosting and the Netlify publish deploy a static frontend plus serverless functions — Bolt’s own docs note Netlify “can’t host your database or a traditional backend.” Server code that isn’t a function silently disappears at deploy; API routes 404 only in production.
What to do: Tell Bolt explicitly to implement server logic as Netlify Functions or Supabase Edge Functions, never an Express server. After every publish, smoke-test the deployed URL — signup, data write, payment — not the preview. A genuinely persistent backend belongs on Railway/Render/Fly.
-
Environment variables don’t transfer to Netlify
Secrets set in Bolt live in Bolt — they are not copied to Netlify when you publish. The build succeeds, then the app initializes Supabase or Stripe with undefined values and crashes with generic errors that never name the missing key. Duplicating a project makes it worse: the copy gets a fresh Netlify site with none of the original’s config.
What to do: Before publishing, set every variable in Netlify Site settings → Environment variables (and function secrets for server-side keys). Make the app fail loudly at boot when a required var is missing. After claiming the Netlify site, re-verify the env vars survived and redeploy.
-
Authorization enforced only in React
Bolt apps are SPAs with no server of your own, so “security” gets implemented as client-side route guards and hidden admin buttons. The Supabase REST endpoint stays reachable by anyone with the anon key from your bundle — attackers skip your UI and query the database directly with another user’s ID.
What to do: Treat the React app as untrusted. Every privileged operation must be enforced in RLS or in a function that validates the caller’s JWT and role. Test by replaying a DevTools request with a different user’s token — if it succeeds, the check only existed in the UI.
-
Stripe still in test mode — or webhooks anyone can spoof
The preview can’t exercise real webhook delivery, so Bolt apps commonly ship with test-mode keys, no live webhook registered, or no signature verification — meaning subscriptions never activate after checkout, or anyone who finds the fulfillment endpoint can POST a fake “payment succeeded” event.
What to do: Before launch: live keys into function secrets, register the deployed webhook URL in Stripe, verify signatures with constructEvent, and fire Stripe’s test events at the production endpoint. Watch webhook delivery health in the dashboard for the first week.
-
No tests, no CI, auto-commits straight to main
Bolt generates zero tests, and its GitHub integration auto-commits every change directly to the selected branch — no PRs, no review, and the agent’s habit of rewriting whole files means regressions land unreviewed on the branch you deploy from. Publish is one click to production with no staging step.
What to do: Connect GitHub early, protect main, and have Bolt work on a branch. Add a minimal CI workflow: typecheck, build, and 3–5 smoke tests of your money paths. Keep a separate staging deploy you actually test before promoting.
-
Flying blind: no error tracking, no security headers, exposed source maps
Bolt’s built-in analytics shows visitors — not errors, function logs, or alerts. Generated SPAs ship without Content-Security-Policy or HSTS, and production builds sometimes include source maps that hand attackers your original source. You learn the app is broken from a customer email.
What to do: Add error tracking (Sentry) to the app and your functions on day one, plus an uptime check that exercises a real flow. Set security headers via netlify.toml, disable production source maps in the Vite config, and sanity-check the deployed site with securityheaders.com.
Why trust this list? We build with AI ourselves and we've deployed production systems to millions of users. Reviewing and hardening AI-built apps is all we do — we know exactly what Bolt gets right, and exactly where it breaks.
A checklist can't read your app. We can.
The items above are the pattern — your app is the specific case. A Launch Check ($799, one-time) is a senior engineer reviewing your actual Bolt app across security, architecture, tests, delivery, and operations — back in 24–72 hours as a severity-ranked launch plan, plus a 15-minute findings call.
Start a Launch Check Not ready? Self-score free in 2 minutesGuarantee: If the report doesn’t change how you launch, tell us within 14 days — full refund.
Already live and something's breaking? Emergency rescue — same-day triage →
Common questions
Why does my Bolt app work in preview but break after deploying?
Because the preview runs a full Node.js environment inside your browser tab, while production hosting deploys a static frontend plus serverless functions. Anything that needed a persistent server — Express routes, websockets, background loops — silently doesn’t exist after deploy. The fix is moving that logic into functions, or hosting a real backend separately.
Is Bolt.new safe for production?
Bolt apps can run in production safely — after the configuration work Bolt doesn’t do for you: Row Level Security policies that actually restrict access, secrets out of the bundle and into function secrets, env vars set on the hosting side, live payment keys with verified webhooks, and some form of monitoring. That’s exactly the checklist above.
Do I need a developer to launch my Bolt app?
You need developer-grade verification, not necessarily a hire. Each item above is checkable in an afternoon if you know what to look for. If you don’t, that’s what our Launch Check is: a senior engineer reviews your actual app and hands you a severity-ranked fix list — most fixes are then promptable back into Bolt.