Lovable app to production: ten checks before real users arrive
A Lovable app is ready for production when it still works with the editor closed. Real users are arriving, and nobody has tested what happens when ten times as many do.
Lovable to production
- Built with
- Lovable Cloud or Supabase
- Checks
- Ten, each with a pass test
- Docs read
- 19 October 2026
- Review
- Paid, after a free call
- Ends with
- A costed fix list
The short answer
A Lovable app is production ready when its data, sign-in and deploys hold up without you in the editor. Check that every table enforces row-level security, private keys stay on the server, sign-up and AI calls have limits, backups restore, errors reach a person, and you can rebuild from your own Git repository. Ten checks follow, each with a pass test.
What Lovable handles and what stays with you
Lovable hosts the published app, serves it over HTTPS and scales page delivery with traffic. Behind it sits a backend with a Postgres database, sign-in, storage and functions. New projects get Lovable's built-in backend, called Cloud, and you can connect your own Supabase project instead. Moving between the two is not automatic, so choose early.
The same documentation says who owns the outcome. You are responsible for making sure the app meets the security needs of its use case, and the built-in scans do not replace a thorough review. Frontend code runs in the browser, where visitors can read and change it. Anything that must be enforced belongs in the database or in server code.
That split is why a Lovable app can look finished and still struggle in its first busy week. The screens work, and the rules behind them were written by a model that was asked for a feature.
The ten checks
These are the ten layers Digiton scores on every production review, written out for a Lovable project. Run them in this order, because the early rows decide how bad a late failure can get.
| Layer | How to check it | A pass looks like |
|---|---|---|
| Frontend bundle | Open the live site, read the network requests and search the loaded scripts for key prefixes and the word secret. Look for served source maps too. | Only publishable keys reach the browser. Private keys sit in Lovable's Secrets and are read by server code. |
| Database access | List every table with its policies. Request each one signed out, then as a second user. Check which roles hold insert, update or delete grants. | Row-level security is on everywhere, no policy lets everyone through, and user B cannot read user A. |
| Version control | Turn on Git sync, clone the repository and run the app on your own machine. | The repository holds the code, human changes arrive as reviewed branches, and Lovable edits one branch only. |
| API and server code | Call each edge function or server route directly, outside the interface, signed out and as the wrong user. | Every route checks who is calling and what they may do, and rejects malformed input. |
| Hosting, deploys and backups | Publish, revert to an earlier version in History, and restore a database backup into a test copy. | You have rolled back once on purpose. On Cloud, backups are daily, kept for about 14 days and leave out files in storage. |
| Security headers | Read the response headers your custom domain sends, not just the lovable.app address. | HTTPS everywhere and a content security policy you chose and tested. |
| Rate limiting | Find every route that sends email or calls a paid model, then call it a few hundred times from one address. | One visitor cannot run up your bill or use up the hourly sign-up email limit. |
| Caching | Load the busiest page twice and watch the database queries it makes. | Reads that are the same for everyone are cached. Nothing that belongs to one user is. |
| Load and capacity | Run a load test against a staging copy while watching the CPU, memory and disk cards in Advanced settings. | You know how many concurrent users slow it down and which instance size you would move to. |
| Error tracking | Break something on purpose in production, then find the trace in More, Cloud, Logs. | An error reaches a person who can act on it, not only a log nobody opens. |
Row-level security and grants decide the rest
If you only have an hour, spend it on the second row of the table. Lovable's Supabase guide says missing row-level security policies are the most common way app data gets exposed, and its Quick scan flags tables that have no per-record access control.
Two layers work together, and Supabase's documentation is direct about it. Grants decide whether a role can touch a table at all. Policies decide which rows it can touch. A table in an exposed schema without row-level security can be read and written by any role holding a grant on it, and adding a policy does not take the grant back. Views bypass row-level security by default. Server code that uses the service role bypasses it too, so that code has to check permissions itself.
The Supabase Security Advisor lints for the common cases, such as tables in the public schema with security switched off. A lint is a prompt to look. It does not say whether the public key can actually reach the data. Only the grants say that.
What this looked like on our own product
We ran this check on Parci in July 2026.
Flagged. The Supabase advisor flagged 12 public tables in Parci with row-level security switched off.
Checked. The grants showed that the anon and authenticated roles could read none of them, so the warning was a lint and not a leak.
Fixed. Row-level security went on for the 11 tables Parci owns. The twelfth is a PostGIS system table that the advisor will always flag.
The lesson for a Lovable app is the order of operations. Read the grants before you panic, and read them again before you relax, because adding a policy never removes one.
The Supabase change on 30 October 2026
Supabase announced on 28 April 2026 that new tables in the public schema stop being exposed to its Data API by default. It began rolling out as the default for new projects on 30 May 2026, and Supabase applies it to all existing projects on 30 October 2026. After that date a new table needs an explicit grant before the app can reach it through the API. Existing tables keep the grants they have, and row-level security behaves as before.
For a Lovable app on your own Supabase project, a feature that adds a table may start failing on that date until someone adds a grant. The risk is the quick fix, which can grant more than the app needs. Give each role only what it needs and put the grants in the same migration as the row-level security statements. We searched Lovable's documentation on 19 October 2026 and found no mention of the change, and nothing on how it reaches the built-in backend, so read your own project's migrations instead of assuming the builder handles it.
The order to fix things in
- Prove you can rebuild. Turn on Git sync, clone the repository and run the app locally, so every later fix lands somewhere you control.
- Close the database. Switch on row-level security for every table, trim the grants, then retest with two accounts.
- Move private keys and paid calls to the server and put limits on them. A model call without a limit is an open tap.
- Rehearse the bad day. Revert a version, restore a backup into a copy, break something on purpose and find the trace.
- Load test a staging copy, then choose the instance size with numbers instead of a feeling.
Export to GitHub and deploy without the editor
- Git sync runs both ways. Edits in Lovable are committed to a GitHub, GitLab or Bitbucket repository you own, and commits you push to the synced branch appear in the project.
- Lovable edits one branch at a time. Keep it on main and put human changes on a feature branch that you merge when ready. If the two sides diverge, Lovable pushes its changes to a separate branch and the next sync from GitHub replaces its version.
- The frontend can move. Apps created from 13 May 2026 use TanStack Start, which runs server code and needs a host that does too. Older apps are React and Vite and build to static files that any static host serves, such as Vercel, Netlify or Cloudflare Pages.
- The backend moves less freely. Lovable supports managed or self-hosted Supabase as destinations and does not support plain Postgres, and moving the database alone leaves sign-in, storage and functions behind.
When an engineer should look at it
Some apps are fine after the first four rows. An internal tool used by a few trusted colleagues, holding no personal data, can go live on that. An app that holds customer records, takes payments or calls a paid model needs the whole table and a second pair of eyes.
Digiton starts with a free 25-minute scoping call about the system. If it fits, the first paid step is a production review of the real repository and infrastructure. You get a scorecard across the ten layers with evidence for each, the result of one load test and a fix list with a cost on every line. The production engineering page shows the full standard. Platforms that need more than hardening sit under custom AI development, and agents acting inside your systems under AI agent development.
If you are still deciding who to bring in, read how to hire a Lovable developer. If security is the worry, the Lovable security audit page covers what the built-in scans check and what they leave to you. Part of the app may also come from a coding agent, and our comparison of Claude Code, Cursor and Codex shows how we weigh them.
Sources, checked 2026-10-19
17 sources
- Lovable says you are responsible for the app's security requirements and that its Quick and Deep scans do not replace a thorough security review.Source: docs.lovable.dev, checked 2026-10-19.
- The Quick scan runs on every publish and checks database access rules, npm dependencies and MCP server exposure. The Deep scan reviews all application code and starts on demand.Source: docs.lovable.dev, checked 2026-10-19.
- Lovable's built-in backend (Cloud) is on by default, you can connect your own Supabase project, and there is no automatic switch between them. Lovable says missing row-level security policies are the most common way app data gets exposed.Source: docs.lovable.dev, checked 2026-10-19.
- Frontend code runs in the browser and can be inspected. Server code that uses the service role bypasses row-level security and must check permissions itself.Source: docs.lovable.dev, checked 2026-10-19.
- Git sync is two-way, Lovable edits one branch at a time, and a diverged branch is pushed to a separate lovable-sync branch.Source: docs.lovable.dev, checked 2026-10-19.
- Apps created from 13 May 2026 use TanStack Start. The frontend can move to hosts such as Vercel, Netlify and Cloudflare Pages, and the backend moves only to managed or self-hosted Supabase.Source: docs.lovable.dev, checked 2026-10-19.
- Cloud takes a daily database backup kept for roughly 14 days, and backups do not include files in storage.Source: docs.lovable.dev, checked 2026-10-19.
- Hosting scales with traffic, newer apps on the Free plan have a limit of 1,000 server requests per project per 10 seconds, and the backend's capacity is set by the database instance size.Source: docs.lovable.dev, checked 2026-10-19.
- Advanced settings shows CPU, memory and disk pressure cards for the last 24 hours and lets you resize the instance.Source: docs.lovable.dev, checked 2026-10-19.
- Email confirmation should stay on for a live app, and an hourly rate limit caps authentication emails.Source: docs.lovable.dev, checked 2026-10-19.
- Every change creates a version that you can preview and revert to.Source: docs.lovable.dev, checked 2026-10-19.
- Backend logs, including edge function and database logs, are under More, Cloud, Logs.Source: docs.lovable.dev, checked 2026-10-19.
- A table in an exposed schema without row-level security is readable and writable by any role with a grant on it, adding policies does not remove grants, and views bypass row-level security by default.Source: supabase.com, checked 2026-10-19.
- Supabase lists row-level security on all tables, email confirmations, a custom SMTP server and load testing on a staging environment in its production checklist.Source: supabase.com, checked 2026-10-19.
- The Security Advisor includes lints for row-level security disabled in public and for policies that exist while security is disabled.Source: supabase.com, checked 2026-10-19.
- Supabase stops exposing new public tables to the Data API by default: new projects from 30 May 2026 and all existing projects on 30 October 2026, with existing tables unaffected.Source: github.com, checked 2026-10-19.
- Unbounded consumption of a model API is a named risk, including denial of wallet through high-volume use.Source: genai.owasp.org, checked 2026-10-19.
Digiton Dynamics OÜ is registered in Tallinn, Estonia, and delivers from Lisbon.
Frequently asked questions
Is Lovable production ready?
It can host a production app. Lovable runs the hosting, scales page delivery with traffic and includes a built-in backend, and its Quick scan runs on every publish. It also says you are responsible for the app's security requirements and that the scans do not replace a thorough review. Production ready is a property of your app, so run the ten checks.
Can I host a Lovable app somewhere other than Lovable?
Yes. Sync the project to your own Git repository, then deploy the frontend to a host such as Vercel, Netlify or Cloudflare Pages. The built-in backend can stay where it is, or you can move it to managed or self-hosted Supabase. Moving the database alone does not move sign-in, storage, realtime or functions.
Do I need my own Supabase project?
No. Lovable's built-in backend is on by default and uses the same open-source foundation. Connect your own Supabase project when you want to own the account, the billing and the dashboard. There is no one-click migration between the two, so decide before you have real data.
How do I check whether my tables are exposed?
Read the database findings in Lovable's Security view or the Supabase Security Advisor, then test like a stranger. Sign out and request each table, then sign in as a second user and request the first user's rows. The lint tells you where to look. A real request and the grants tell you whether data leaks.
Will the Supabase change on 30 October 2026 break my app?
Tables that already exist keep their grants, so they keep working. A new table on your own Supabase project will need an explicit grant before the API can see it. Put the grants and the row-level security statements in one migration, and test the change on a branch before the date.
What does the production review cost?
We do not publish a price. The scoping call is free and takes 25 minutes. The review is paid and quoted after that call, and its output stands on its own: a scorecard, a load test result and a priced fix list your team can use with or without us.
Talk to an engineer about your system
Book a free 25-minute scoping call. We tell you what we would build, what it takes to keep it running, and whether we are the right fit.