We get a lot of Bolt.new projects through the door, and by now we can spot one before the founder even tells us what tool they used. There’s a particular flavour of bug that Bolt apps get, distinct from what we see in Replit or Cursor projects, and it comes down to one thing: Bolt builds and runs your app inside a browser sandbox, and the moment you deploy it somewhere real, a handful of assumptions quietly stop being true. This article covers the bolt.new bugs we run into most often, why they happen, and how to check your own project before they become a production incident.
What Bolt is genuinely good at
We should say this upfront because it’s true and it matters: Bolt is one of the faster tools for getting a working prototype in front of a user. The StackBlitz WebContainer tech behind it runs a full Node environment in the browser, which means you can go from a blank prompt to a clickable app in minutes, with hot reload and a live preview, no local setup at all. For validating an idea, demoing to a client, or testing a UI direction, that speed is real and we’re not going to pretend otherwise.
The trouble starts when “it works in the preview” gets treated as “it’s ready to launch.” Those are different claims, and Bolt’s own environment makes it easy to conflate them.
The problems that repeat
The first issue is the gap between the in-browser environment and real hosting. WebContainers simulate a Node runtime, but it isn’t the same as a Linux server, and it doesn’t have the same file system, process model, or networking behaviour. Apps that read and write local files, spawn child processes, or rely on specific Node APIs can behave differently once you export the project and deploy it to Vercel, Netlify, or your own server. We’ve seen builds that pass every check in the Bolt preview and then fail silently in production because a dependency expected a real file system that no longer exists.
Second, and this is the one that worries us most, is secrets baked straight into the front end. Because Bolt’s iteration loop is so fast, API keys end up hardcoded into client-side JavaScript far more often than in tools with a slower, more deliberate setup step. The founder pastes a Stripe secret key or an OpenAI key into a prompt to “make the API call work,” Bolt wires it in exactly as asked, and it ships to the browser bundle where anyone can view-source it. This isn’t a Bolt-specific flaw exactly, we cover the same pattern across tools in our guide to finding exposed API keys in your AI-built app, but Bolt’s speed seems to make it more common, not less.
Third: Supabase defaults. Bolt leans on Supabase as its go-to backend, and it’s a solid choice on paper, but Bolt-generated projects routinely ship with row level security either disabled or configured so loosely it’s not doing anything. We’ve opened Bolt projects where any authenticated user, sometimes any anonymous one, could read every row in the users table. If you’re on Supabase and haven’t had someone check your policies, read our piece on common Supabase mistakes in AI-generated code before you do anything else this week.
Fourth, and this one is subtler: token-limit rewrites that quietly break working code. When a Bolt session runs long, or the model hits its context window, it will sometimes regenerate a file from scratch rather than making a small edit, and that regeneration doesn’t always preserve logic that was already correct. We’ve seen validation rules vanish, error handling disappear, and edge-case fixes from three prompts ago get silently reverted because the model rewrote the file without full memory of why that code was there. It looks like nothing changed, because the app still runs. It’s only when someone hits the edge case again that the bug resurfaces.
How serious is each one
Not all of these deserve the same reaction, and we’d rather be straight about that than tell you everything is on fire.
The environment gap is usually annoying rather than dangerous. It causes broken deploys and confusing error messages, and it costs you a day of debugging, but it doesn’t put user data at risk on its own.
Baked-in secrets and loose Supabase policies are a different category entirely. These are the ones that get a founder’s Stripe account drained or their user table scraped, and they’re often invisible from the outside because the app looks and functions perfectly. If you’ve launched, or you’re about to, these two are the ones to check first, full stop.
The silent rewrite problem sits in the middle. It won’t leak data on its own, but it erodes trust in the codebase over time, because you stop being able to assume that a fix, once made, stays made. That’s exhausting for a non-technical founder trying to track what’s actually working.
A quick self-check for your Bolt project
Open your browser’s dev tools, go to the Network tab, and reload your app. Look at the requests going out. If you see an API key in a request URL or in a response body that came straight from your own front-end code, that’s a live problem, not a hypothetical one.
Next, if you’re on Supabase, log into the dashboard and check the RLS status on every table. “Enabled” isn’t enough by itself, the policies attached to each table need to actually restrict access to the right rows for the right users. If you’re not sure how to read that, this is exactly the kind of thing worth a second pair of eyes.
Then export your project and try a clean deploy somewhere other than Bolt’s own preview, ideally on the actual host you plan to use. If anything breaks, better to find out now than after a customer does.
Finally, if you’ve been iterating on the same Bolt project for weeks, pick two or three features you fixed a while back and test them again. If a bug you already solved has quietly come back, that’s the token-limit rewrite pattern at work, and it’s worth having someone review the diff history rather than just patching it again and hoping.
If you’re still deciding which tool to use for your next build, or trying to work out whether your current one is the reason for these headaches, our comparison of Bolt, Cursor, and Lovable and our writeup on the problems we see most in Replit Agent code cover how the tools differ in practice, not just in marketing copy.
Built it on Bolt and hit a wall? We’ll take a look for free.