App rescue · Bolt.new
Your Bolt.new app works in the preview and breaks everywhere else
Bolt.new gets you to something that runs. Running is not the same as deployed: the preview hands you environment variables you never set, an origin your auth redirect will never see again, and a database nobody has locked down. Every Bolt rescue we take starts at the first real deploy.
What actually breaks
The four failures we see most in Bolt.new builds
These are specific to Bolt.new. A rescue starts by working out which of them you have.
Supabase row level security left off
Bolt wires Supabase into the frontend with the anon key, which is public by design. Row level security is the only thing standing between that key and every row in your database. Industry reporting puts roughly 70% of Lovable and Bolt apps on Supabase shipping with RLS disabled. Open your table editor and look at the RLS column.
Environment variables that only exist in the preview
Keys hardcoded during generation, or set in the Bolt environment and never carried into the deploy target. The build succeeds and the app fails on first real request.
Auth redirect loops after deploying to a custom domain
Callback URLs still pointing at the preview host, so sign-in bounces forever. Fixable in minutes once you know where to look, and maddening if you do not.
The preview is not a server
Bolt builds and runs your project in the browser. Anything that needs a real filesystem, a native package or a process that stays alive works there because nothing in the preview is being asked to survive. The first deploy is where you find out which of those you depend on.
What we do
What a rescue includes
Scoped after the audit, so you see the plan and the price before anything is touched.
- Every table tested against the anon key, with RLS policies written where they are missing
- Secrets moved out of the codebase and into the deploy environment
- Auth callback and redirect URLs corrected for your real domain
- A working deploy pipeline you can run yourself
- Failures reported from the deploy target rather than swallowed, so you see the 500 before a customer does
The first audit is free · written findings within 48 hours · the report is yours either way
Questions, answered
Can you fix my Bolt app or do you have to rebuild it?
Usually fix. The app runs — that is why you shipped it. What is missing sits around the code: policies on the database, secrets in the deploy target, callbacks pointing at your own domain. We recommend a rebuild only when the data model cannot support what the product needs next, and the audit tells you which of the two you are before you spend anything.
Is my Supabase data actually exposed right now?
Check whether row level security is enabled on your tables. If it is off, then yes: any authenticated user can query any row, and so can anyone holding the anon key sitting in your frontend bundle. This is the first thing we look at. Switching RLS on without breaking your own queries is the part people get wrong.
What does the free audit actually include?
We look at the real thing — the live app or the repository, not a description of it — and send back a written assessment within 48 hours: what is salvageable, what is not, what it would cost to get to production, and what we would do first. It is yours to keep whether or not you hire us.
Do I own the code after you fix it?
Yes. You own the repository, the infrastructure and every account it runs on, with documentation and a handover. That is true of a rescue exactly as it is of a build.