How a Lovable app runs in production
A Lovable app goes live when you press Publish: Lovable deploys a snapshot to a lovable.app address — or your own domain, on a paid plan — and nothing you change afterwards reaches visitors until you publish again.
Behind it is usually Supabase, through Lovable Cloud or a project of your own, for sign-in, the database and edge functions; and Stripe for payments, called from an edge function that holds your secret key. Lovable can keep the code in a GitHub repository, synced both ways.
What breaks after launch
- Anyone can read your Supabase tablesLovable creates tables as you describe features. One left without row level security can be read with the public key every visitor downloads — a 2025 scan of Lovable apps found 170 of 1,645 exposing data that way (CVE-2025-48757).How to tell, and the fix
- Sign-in breaks on your new domainMoving from the lovable.app address to your own domain leaves Supabase’s redirect URLs naming the old one, so sign-in fails on the new address and nowhere else.How to tell, and the fix
- Sign-up emails do not arriveA Supabase project still on its built-in mailer sends only a few auth emails an hour. On launch day the rest of the sign-ups never get theirs.How to tell, and the fix
- Checkout succeeds; the order never happensLovable’s Stripe guide leaves the webhook for you to set up in Stripe. Until it exists and answers, a customer can pay and the app never hears about it.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. Lovable does not announce a publish, so each five-minute check fingerprints the live page’s own scripts and styles. A new fingerprint is a publish: the new version is checked and your journeys are walked against it.
- 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 pressing Publish, Keelnest sees the new version — Lovable tells nobody, so the live site is fingerprinted on every check — and verifies it: the address, the certificate, the headers, then your journeys. If sign-in broke, you hear it from Keelnest, with the reason, before a customer tells you.
Fixes: a prompt, or a pull request
Every incident comes with a prompt written for Lovable’s chat: what broke, what to change, and never a secret to paste. On a paid plan with GitHub sync on, Keelnest can prepare the fix as a pull request on the synced repository instead; nothing merges until a named person approves it, and Lovable’s sync brings the change back into the project. Settings outside the code — Supabase’s redirect URLs, Stripe’s webhooks — come as steps, with a link to the exact page.
Setting it up
- Add the app’s live address — the lovable.app one or your own domain. The first check runs straight away.
- If the app uses a Supabase project in your own account, connect it with a read-only access token; if it takes payments, connect Stripe with a restricted key.
- Write one journey — sign in, or reach the checkout — in plain words. It is walked after every publish.
- For fixes as pull requests, turn on GitHub sync in Lovable and install the Keelnest GitHub App on that repository.
Or start without an account: the free health check reads any live address in a few seconds.
Questions
Do I need to change my Lovable app?
No. Everything starts from the live address. Connections add depth — Supabase, Stripe, GitHub — and each one is a read-only credential you create and can revoke. The error-capture script tag is the one optional line of code.
How quickly does Keelnest notice a publish?
Within five minutes. Lovable does not announce publishes, so the live site is fingerprinted on every check and a change is treated as a publish, then verified.
Can Keelnest fix the problem for me?
It writes the fix as a prompt for Lovable’s chat on every plan. On paid plans with GitHub sync on, it can prepare the fix as 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 Lovable does, as its own documentation described it on 23 September 2026. Builders change quickly; if something here is out of date, tell us.
- Lovable · Publishing
- Lovable · GitHub integration
- Lovable · Stripe
- Supabase · Custom SMTP
- CVE-2025-48757 write-up