How a Bolt app runs in production
Pressing Publish in Bolt puts the app on Bolt Cloud at a bolt.host address, or on your own domain with a Pro plan. Projects from before Bolt Cloud were published to Netlify, and many still are.
Data and sign-in come from Bolt’s built-in database or from a Supabase project you connect, and Bolt’s Stripe integration runs on Supabase and registers its own webhooks. Bolt can keep the code in a GitHub repository, synced both ways.
What breaks after launch
- Sign-in breaks on your new domainBolt’s own docs warn that the auth Site URL starts as localhost:3000, which does not work for a live app. Until it and the redirect list name your real address, sign-in fails in production.How to tell, and the fix
- Anyone can read your Supabase tablesOn a Supabase project, a table without row level security answers anybody holding the public key the site ships with.How to tell, and the fix
- Stripe disabled your webhook endpointBolt registers Stripe’s webhooks for you. If deliveries start failing, Stripe retries for three days and then disables the endpoint — quietly.How to tell, and the fix
- A publish broke a journeyA publish can change a page a customer depends on — the sign-up form, the pricing page — without anything erroring.How to tell, and the fix
What Keelnest watches
The site, every five minutes
The address, its certificate and its security headers, requested the way a browser asks; an incident opens after two failures in a row, never on one blip.
Every publish
Every check fingerprints the live page, so a publish is checked within five minutes; a project still on Netlify can connect Netlify and have each deploy checked the moment it goes live.
Sign-in and checkout, in a real browser
Walked after every publish and on your plan’s schedule, sign-up emails and magic links included; a payment journey stops before the pay step.
Supabase
Every check reads the auth redirect URLs, the sign-in mailer, the security advisor’s findings and failed sign-ins, with a token Keelnest only reads with.
Payments
A read-only Stripe key compares payments with what that hour of the week usually brings, and reads webhook endpoints and failed deliveries.
Errors
One script tag reports uncaught errors and failed requests — never form values or request bodies — so an incident says what broke. Sentry works too.
Fixes: a prompt, or a pull request
Every incident carries a prompt written for Bolt’s chat, never asking for a secret. On a paid plan with Bolt’s GitHub integration on, Keelnest can prepare the fix as a pull request instead; nothing merges until a named person approves it, and Bolt’s sync brings the change back into the project.
Setting it up
- Add the app’s live address — bolt.host, a Netlify address or your own domain. The first check runs straight away.
- Connect Supabase with an access token (Keelnest only reads with it) if the app uses a Supabase project of yours, and Stripe with a restricted key if it takes payments.
- Write one journey — sign in, or reach the checkout — in plain words. It is walked after every publish.
- If the project still publishes to Netlify, connect Netlify so each deploy is checked the moment it goes live.
Or start without an account: the free health check reads any live address in a few seconds.
Questions
Do I need to change my Bolt app?
No. Everything starts from the live address; each connection is a read-only credential you create and can revoke, and the error-capture script tag is the one optional line of code.
Is it free?
Your first app is: the five-minute checks, the check after every publish, and one journey, walked weekly and after every publish. Paid plans add journeys, run them hourly or faster, and prepare fixes as pull requests.
Sources
What Bolt does, as its own documentation described it on 23 September 2026. Builders change quickly; if something here is out of date, tell us.