Lovable · Supabase · free check
Is my Lovable app safe for production?
It can be. A Lovable app is a React front end on Supabase, and whether it is safe for real users is decided by four things the editor does not show you on the screen you build in. Start with what your live address already hands every visitor:
✓ Passive check · reads only what your app already sends every visitor · nothing is stored
1 · what goes wrong
Who can read whose rows
Every Lovable app talks to Supabase straight from the browser, with a public key that ships in every copy of the app. That is by design. The only thing that keeps one customer's rows away from another's is row-level security, switched on and written table by table. A table added later through a prompt or an SQL migration can arrive with it off, or with a policy that admits every row, and nothing in the app looks any different.
Any visitor holding the public key can read that table: other customers' names, emails, orders, messages. In the EU that is a personal-data breach you may have to report within 72 hours.
2 · what goes wrong
Keys that should never reach the browser
Whatever the app's JavaScript contains is public, whatever the variable is called. A Supabase secret or service-role key, a Stripe secret key or an OpenAI key that ends up in the front-end bundle can be copied by anyone who opens the page.
A Supabase secret key ignores row-level security entirely: every row of every table, readable and writable, with no account and no trace. A payment or AI key runs up your bill or reaches your customers' payments.
3 · what goes wrong
A backup nobody has restored
Most apps have never restored a backup. Until someone has, nobody knows whether one exists, how old it is, or how long the restore takes.
The day a migration or a prompt deletes the wrong rows, the answer to "can we get it back?" is a guess.
4 · what goes wrong
Changes nobody re-checks
An app built by prompting changes faster than anyone reads the changes. Without tests that exercise the paths customers use, a fix in one place quietly breaks another.
Customers find the regression before you do, usually in sign-up or checkout.
Questions people ask
Is the Supabase anon key in my Lovable app a problem?
No. The anon (publishable) key is meant to be in the browser. What protects your data is row-level security on every table that holds it. The key that must never be in the browser is the secret or service-role key.
Doesn't Lovable check security before I publish?
Lovable runs a security scan and surfaces Supabase's own warnings, which catch a table with row-level security switched off. Neither can know which rows each of your customers should see, so a policy that is on but admits too much passes them.
What can a check of my address see, and what not?
From the address: what every visitor is handed — the page, its scripts, keys inside them, security headers. Not visible from outside: your row-level security policies, backups and tests. Those are read from your code by the full check.
An address shows only what a visitor sees. Row-level security policies, backups, tests and secrets with fallback defaults are in your code: the full check reads 118 of them inside Claude Code, Cursor or Codex, free. The full check, in your coding tool →
When you want the gaps closed the way serious software teams close them, the same 
prodready connection runs the SDLC on your project.