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 production address is requested the way a browser would ask for it, then the certificate and the security headers. An incident opens after two failed checks in a row, never on one blip, and a certificate is flagged from fourteen days before it expires.
- Every publish. Bolt does not announce a publish, so each five-minute check fingerprints the live page. A new fingerprint is a publish, checked and walked by your journeys. A project still published to Netlify can connect Netlify instead, and each deploy is checked the moment it goes live. Netlify.
- Sign-in and checkout, in a real browser. A journey is the steps a customer takes, written in plain words and walked in a real browser after every publish and on your plan’s schedule. It can type a one-off inbox address and wait for the email, so a sign-up confirmation or a magic link is walked to the end. A payment journey stops before the pay step; nothing is charged.
- Supabase. With a read-only access token for your Supabase project, every check reads the auth redirect URLs, which mailer sends the sign-in email, the security advisor’s findings — row level security included — and failed sign-ins per hour. Supabase.
- Payments. With a read-only Stripe key, payments are compared with what that hour of the week usually brings, and webhook endpoints and failed deliveries are read, so money that stops arriving is noticed in hours rather than at the month’s close. Stripe.
- Errors. One script tag reports uncaught errors and failed requests from real visitors — never form values or request bodies — so an incident says what broke, not only that something did. Sentry works too, if the app already has it. Error capture, Sentry.
When you publish
Within five minutes of a publish, Keelnest sees the new version on the live site and verifies it: the address, the certificate, the headers, then your journeys. On Netlify, connect it with a read-only token and add the deploy notification, and verification starts the moment the deploy succeeds.
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 a read-only access token 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
Does Keelnest work with Bolt Cloud and with Netlify?
Yes. On Bolt Cloud the live site is fingerprinted every five minutes and a change is a publish. On Netlify you can also connect Netlify, and each deploy is reported the moment it succeeds.
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.
Can Keelnest fix the problem for me?
It writes the fix as a prompt for Bolt’s chat on every plan. On paid plans with the GitHub integration on, it can prepare a pull request instead, and nothing merges until a named person approves it.
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.