How to take a Bolt app to production

Why Bolt apps break on the way to production

Bolt is made by StackBlitz, the team behind WebContainers, and that technology is the reason it feels so quick. Your app's development environment, Node.js included, runs inside your browser tab. There is nothing to install. It builds full-stack web apps in JavaScript frameworks, and mobile apps through its Expo integration.

Behind the editor sits Bolt Cloud: hosting on a bolt.host address, custom domains, a database Bolt creates when your project needs one, login, file storage, server functions and Stripe payments. In other words, everything you need to launch is in one place. That is the appeal, and also why the gaps are easy to miss.

The usual reasons a Bolt app is not ready for real users:

• The preview is not production. In the editor, the app runs in a container in your own browser, used by one person who knows how it works. Production means real servers, real secrets, real network delays and strangers doing things in the wrong order.
• Login is not always there. Bolt's own docs say it doesn't always add sign-up and log-in automatically. You have to ask for it. If you asked late, the data model was built before anyone thought about who owns what.
• The security check is narrow. Bolt's Security Audit looks for open permissions and missing row level security rules in the database. It covers the database only, not the rest of your project.
• Each prompt fixes what is in front of it. Bolt edits what you describe. Nothing checks that the change didn't break checkout two screens away.

How the common failures show up in Bolt

The general list of the ten things that break most often in AI-built apps applies to Bolt too. Here is how those failures tend to look in a Bolt project, as a checklist you can run yourself.

Auth and data access

When Bolt adds login, you configure email confirmation, password reset and Google sign-in in the database's Authentication settings. That covers who someone is. It does not cover what they are allowed to see. The rules that stop one customer reading another customer's records sit in the database, and the gaps I look for are tables with no rules, rules that only check whether someone is logged in, and admin screens that are hidden in the interface but not blocked underneath.

Secrets and server functions

Bolt handles keys sensibly when you let it. Secrets only work with server functions, which run on Bolt's servers rather than in the browser, and Bolt prompts you when a secret is needed. Its docs also say never to paste secret values into your project's code, to rotate keys on a schedule and to delete the ones you no longer use. The risk is keys that went into the code early on, before anyone set up Secrets, and server functions that hold a key safely but will do expensive work for anyone who calls them.

Payments

Bolt Cloud connects to Stripe for one-off payments and subscriptions, and Stripe handles the card details. What still needs care is how your app learns a payment went through, and what happens on a failed renewal, a cancellation or a refund. If the upgrade happens when a success page loads, it will be wrong some of the time.

Hosting: Bolt hosting or Netlify

New Bolt projects publish to Bolt hosting by default. You can switch to Netlify, but Netlify can only host the part of your app that runs in the browser. Anything with a database or backend should stay on Bolt hosting. Switching between the two means unpublishing first, and custom domains don't move across automatically.

Two production details worth knowing:

• Hosting usage is capped by plan. If you hit the limit, your site stops displaying publicly until usage resets at the next billing cycle. Check your plan before a launch you expect to go well.
• Idle databases can pause. In unpublished projects, Bolt may pause a database after six or more days of low use. Published projects are not paused, but a staging copy you forgot about might be.

How export to GitHub works

Bolt's GitHub integration syncs both ways. Every change that doesn't break the project becomes a commit, and Bolt checks GitHub every 30 seconds for changes made elsewhere and pulls them in. You can also import an existing repository, as long as it isn't empty and you have push permission.

The details that matter once someone else is working on the code:

• Branches you create in Bolt are created in GitHub too, but Bolt can't merge them. Merging happens in GitHub.
• If Bolt tries to push while GitHub has a newer version, it pulls GitHub's version and asks whether to reapply your last message or discard it.
• Only the project owner can connect and manage the integration. A collaborator's changes sync the next time the owner opens the project.
• Disconnecting is permanent from your side. To reconnect the same repository you have to contact Bolt support, so don't disconnect it to tidy things up.

Moving your data later

You can export row data from the Tables page. If you think you might want your database in your own Supabase account one day, decide early: Pro and Teams users can pick Supabase when starting a new project, but Bolt's database docs say there is currently no supported way to migrate an existing Bolt database to Supabase. Check the latest docs before you plan a move, because this is the kind of detail that changes.

What a fix looks like

The goal is a Bolt app you can put in front of paying users, and that you can keep editing in Bolt afterwards. Security and data first, money second, experience third.

1. 1

   Free health check

   Run the vibe-code health check for a first read on where the app stands.

2. 2

   Call and repository access

   A short call about who the app is for and what it must do. You give me access to the GitHub repository Bolt syncs to, and I review the code, database rules, secrets and server functions.

3. 3

   Fixed price, in writing

   A list of what I will fix, in order, with one price. If something is better rebuilt than rescued, you hear it now.

4. 4

   Access rules, keys and payments

   Row level security on every table, server functions that check the caller, keys moved to Secrets and rotated, and payment handling that does not rely on a page load.

5. 5

   Errors, mobile, accessibility and polish

   Proper empty, loading and error states, a phone-first pass, keyboard and screen reader basics, and consistent components.

6. 6

   Tests, merge and handover

   Tests on the journeys that matter. Fixes are merged in GitHub, sync back into Bolt, and you get notes on which parts to leave alone when prompting.

A Rescue Sprint usually takes about a week. The price is fixed and agreed in writing after the free health check and a call. I don't give a number before that, because two Bolt apps that look the same in the preview can be very different underneath. To see where yours stands, run the free health check.

When a rebuild makes more sense

A rescue is not always the right call, and I would rather say so up front. With a Bolt app, a rebuild usually makes more sense when:

• You need to leave Bolt Cloud and your data lives in a Bolt database. With no supported route to move an existing database to Supabase, the migration can be as much work as building it properly.
• The data model is wrong at the root. If login was added late and records have no clear owner, fixing it touches every table and every screen.
• The product has changed. Paying to fix screens for an idea you have dropped is money better spent on the version you actually need.
• A team will take it over. Developers you hire, or investors checking the code, will want something conventional they can read without a tour.

Your Bolt app is still worth having in that case. It is the clearest brief you could write. An MVP Build starts from £12,000 and takes 4 to 6 weeks, designed and built by me in Next.js, TypeScript, Postgres and Stripe, with every account in your name. If you are still choosing tools, read the Lovable vs Bolt vs designer comparison, or see a marketplace I built and run myself in the FindPopups case study.