Bolt got you a prototype. We get you to production.

Bolt runs your app inside a WebContainer — a real server runtime executing inside your browser tab. This isn't a mock or a simulation: dependency installs actually run, your server actually starts, your API routes actually execute. That's why the preview feels so convincing. But a WebContainer is a single sealed environment serving one browser tab, not a server handling many independent visitors at once, and that gap is where most of the breakage starts.

The filesystem is the first mismatch. WebContainers use an in-memory virtual filesystem that resets with the session. Code that writes to disk, reads local files at startup, or assumes a persistent working directory behaves differently once it lands on a real host, where storage can be ephemeral, read-only, or simply organized around assumptions the sandbox never had to satisfy.

Secrets follow the same pattern. Inside Bolt, environment variables usually sit as plain values in the project's own settings panel, not behind any real secrets manager. Because the whole app — client and server — compiles inside the same browser tab, it's easy for a key meant to stay server-side to end up reachable from the client bundle. Nothing in the sandbox forces that separation, so nobody notices until the app is live.

Database access has a matching blind spot. A WebContainer serves one user's session at a time, so a connection opened per request never collides with another one — there's no real concurrency to expose the problem. Put a second and third visitor on the same app at once, and the absence of connection pooling shows up as exhausted connections or requests that hang, a failure mode the sandbox has no way to produce. Networking behaves differently for the same reason: real hosting introduces concurrent requests, cold starts and timeouts that a single-tab sandbox simply doesn't model, so code that never had to share resources suddenly has to.