Seven things to fix before your Bolt.new app goes live

1. It only works inside the WebContainer

Don't trust the preview. Bolt runs your project in a StackBlitz WebContainer, a Node.js environment that lives inside your browser tab, and plenty of code that runs happily there fails a clean production build somewhere else. The preview has been patched up by prompt after prompt; nobody has ever installed it from scratch.

WebContainers can't run native binaries, so Bolt quietly reaches for pure JavaScript alternatives. Dependency versions drift as the AI adds packages. Type errors that the dev server shrugs off stop a strict build dead.

• How to spot it. Push the project to GitHub, clone it onto a laptop, delete node_modules, then run a fresh install and a production build. Anything that fails here would have failed on your host.

• The fix. Pin the Node version in the project, commit the lockfile, fix every build error rather than switching checks off, and make that clean build the thing your host runs on every deploy.

2. Your secrets are in the bundle, or in Git

Assume at least one key has leaked until you've checked. Most Bolt apps are React with Vite, and Vite copies any environment variable starting with VITE_ straight into the JavaScript every visitor downloads. When a prompt says to add a Stripe or OpenAI key, it often ends up there.

The second leak is the .env file itself. Bolt keeps it in the project so the preview works, and depending on how the repository was set up, it can be pushed to GitHub along with everything else.

• How to spot it. Search the built files for anything that looks like a secret key, and search the repository history, not just the latest commit, for a .env file.

• The fix. Rotate every key that was exposed, because deleting the file doesn't remove it from history. Move secret calls into Supabase edge functions or a small server, keep only the public Supabase URL and anon key in the frontend, and add .env to .gitignore.

3. Anyone can read the database

If row level security is off or loosely written, any visitor can query your tables directly. The browser talks to Supabase with the anon key, which is public by design, so the only thing standing between one user and another user's records is the policy on each table.

AI-written policies tend to fail in a specific way: they exist, but they say any signed-in user can read every row. The app looks right because the interface filters to your own data. The database doesn't.

• How to spot it. Open the security advisor in the Supabase dashboard, which flags tables with security switched off. Then sign in as a test user and query another user's rows from the browser console.

• The fix. Turn on row level security for every table, write policies that match each real role, and move anything that charges money or changes another user's data into an edge function that checks permissions on the server.

4. The backend isn't in your account yet

Check who owns the database before you change anything else. Newer Bolt projects use Bolt Database, which is built on Supabase, and until you claim it into a Supabase organisation you control, you don't hold the keys to your own users and data.

The trap here is connecting a fresh Supabase project to an app that already has a Bolt Database. Bolt warns that this replaces the connection and can lose data. Claiming moves the existing database across; reconnecting starts again.

• How to spot it. Look for the project in your own Supabase dashboard. If it isn't there, or it sits under a personal account rather than the company, it isn't fully yours.

• The fix. Claim the database, then compare tables, users, storage buckets and edge function secrets against what the live app uses. Confirm with Bolt what the claim covers for your project before cancelling anything.

5. Sign-up works for you and nobody else

Auth is usually tested once, by the founder, on the happy path. Real users click confirmation links on their phones, reset passwords and sign in with Google, and each of those depends on settings the preview never exercised.

• How to spot it. Sign up with a new email address on the deployed site, on a phone. Then reset the password, and sign in with every social provider you offer. Watch which address each email link points at.

• The fix. Set the Site URL and redirect URLs in Supabase to your real domain. Add a page that actually handles password resets. Connect your own email provider through custom SMTP, because Supabase's built-in email is rate limited and meant for testing. Register each OAuth provider's callback for the production domain.

6. The deploy depends on Netlify defaults you never chose

A one-click deploy from Bolt gets a site online, not a release process. Bolt's Netlify integration and its own hosting both make sensible guesses, and the gaps show up as soon as someone refreshes a page or you change a setting.

• Refreshing any page other than the home page returns a 404, because a single page app needs a rewrite rule sending every path to index.html.

• Changing an environment variable in the host does nothing until the next build, because Vite bakes values in at build time.

• The Netlify site sits in an account Bolt created for you, unclaimed, so nobody on your team can see the build logs.

• There are no preview builds, so every change goes straight to the address your customers use.

• How to spot it. Deep link to an inner page and refresh it. Then try to find the build log for the last deploy.

• The fix. Claim or recreate the site in your own Netlify or Vercel account, deploy from GitHub, add the single page app rewrite, keep variables per environment and turn on preview builds for every pull request. Put the app on a custom domain you control.

7. Nothing tells you when it breaks

A Bolt app usually ships with no error tracking, no tested backups and no staging copy, and schema changes have been made by prompt directly against the only database there is. You find out about problems from customers.

• How to spot it. Ask three questions. Where would I see an error a user hit an hour ago? When did I last restore a backup? Where can I try a schema change without touching live data?

• The fix. Add error tracking such as Sentry and an uptime check. Create a separate staging Supabase project, keep every schema change in a migration file in the repository, and check what backups your Supabase plan includes. Write automated tests for sign-up, payment and the one job the app exists to do.