Take a Lovable App to Production

To take a Lovable app to production, lock down the Supabase backend first: row-level security on every table, no service role key anywhere in the front end, and Stripe events handled by a verified webhook rather than a success page. Then add migrations, a staging copy of the database and tests on sign-up and payment. If you want someone to look first, Easify's €99 Prototype Check returns the top security and data risks in writing within 48 hours.

This guide explains how a Lovable app is put together, where the documented weak points are, a self-check you can run this afternoon, and how to decide whether to stay on Lovable or move off it.

At a glance

How a Lovable app is built, and why it matters

Which Lovable you have depends on when the project was started. Lovable's FAQ says apps created from 13 May 2026 (22 June 2026 for Enterprise workspaces) use TanStack Start, which renders pages on the server, while older apps use React and Vite and render in the browser. You cannot pick another framework such as Next.js. Check package.json before anything else.

The backend is the same in both: a PostgreSQL database, either on Lovable Cloud, which Lovable describes as built on Supabase's open-source foundation (database, auth, storage, Edge Functions and secrets), or in a Supabase project you connect yourself.

In an older, browser-rendered app there is no server of your own between the user and the data. The browser calls the Supabase API directly with a public key, and anything that needs a secret runs in an Edge Function. The database's own rules are then your entire security model: a forgotten policy is every row of a table, available to anyone who opens the browser console. A newer app can also run code on the server, which helps, but any code that uses the Supabase client with the public key is still bounded only by those rules, and every server function is an endpoint that has to check who is calling.

The risks specific to Lovable apps

Row-level security: the one that matters most

Supabase's row-level security (RLS) decides which rows each user may read and write. Without it, the public key is enough to read the whole table.

This is not hypothetical. CVE-2025-48757 records Lovable-built apps whose tables could be read, and in some cases written, by anyone holding the public key, because RLS was missing or insufficient. Lovable disputes the CVE on the grounds that each customer is responsible for their own app's data, which is precisely the point: the responsibility is yours.

Lovable now runs a security scan on publish that checks database access rules, and its own documentation says that "misconfigured RLS rules are a common cause of data leaks" and that the scans do not replace a thorough security review. The patterns to look for:

• RLS enabled with a policy of true. The scan sees RLS switched on; the policy still lets everyone through.
• Ownership checked on read but not on update. A user cannot see other people's rows but can change their own role or plan column to admin or pro.
• Insert policies with no with check clause, so a user can create rows that claim to belong to someone else.
• Storage buckets left public for files such as invoices, IDs or contracts.
• Policies that filter on columns with no index. Supabase's RLS guidance recommends indexing the columns policies use; without it, every query slows as tables grow.

Auth and roles checked in the interface

The demo hides the admin page from ordinary users. That is a display choice, not a permission. Every role check needs to exist where the user cannot edit it: in an RLS policy, or in an Edge Function or server function that verifies the user's token before doing anything privileged. Watch especially for a profiles table that holds the role and that users are allowed to update.

Keys in the wrong place

The Supabase anon (publishable) key is meant to be public. The service role key bypasses RLS entirely, and Supabase's API key guide says it must never reach the browser. Both stacks build with Vite, and in Vite any variable prefixed VITE_ is compiled into the front-end bundle, so a secret stored that way is published to every visitor. Lovable's documentation says the same in its own words: secrets cannot be stored safely in client-side code, and belong in Secrets, used from Edge Functions. If a key was ever pasted into the chat or committed to GitHub, rotate it.

Payments and Stripe webhooks

The common prototype shortcut is to mark a user as paid when Stripe redirects them to a success page. Anyone can visit that URL. Access should be granted only from a Stripe webhook handled in an Edge Function, with the signature verified and duplicate events ignored, because Stripe can deliver the same event more than once. Also check what happens on a failed renewal, a refund and a cancelled subscription. A demo exercises none of them.

Scaling

The usual limits are queries rather than servers. Lists that fetch a whole table and filter in JavaScript, one request per row on a dashboard, and no pagination all work at demo size and degrade as data grows. Edge Functions and server functions that call slow third-party APIs inside a user's request are the other common bottleneck; move that work to a background job.

Tests, CI and migrations

Lovable's GitHub sync works both ways on one branch, by default main. That is convenient and also means every prompt can change production code with no review and no tests. Check whether the database schema exists in the repository as migration files, or only as whatever state the last prompt left it in. Production needs a staging Supabase project, migrations under version control, backups you have actually restored, and a CI run on every change.

Lock-in and hosting

The code is portable: Git sync works on every plan, paid plans can download the whole codebase, and Lovable documents running the app on hosting you choose. The backend depends on where it lives. If you connected your own Supabase project, you already own it, and Supabase is open source. If it is on Lovable Cloud, Lovable's documentation says there is no one-click path to your own Supabase project: you export the data, connect a new project and rebuild the schema, and the export leaves out stored files, Edge Function code and secrets. That is manageable for a prototype and worth deciding early, before the data grows.

A self-check you can run today

1. Open the Supabase table editor. Is RLS enabled on every table that holds user data?
2. Read each policy. Does any say true, or check auth.uid() on select but not on update?
3. Create two test accounts. Logged in as one, try to load the other's records by changing an ID in the URL.
4. Search the repository for service_role, sk_live, sk_test and any VITE_ variable holding a secret.
5. Check storage buckets: which are public, and what files are in them?
6. Find where a user becomes paid. Is it a webhook with a signature check, or a redirect?
7. Look for a supabase/migrations folder, or any record of schema changes.
8. Ask what would happen if someone deleted a table now. Is there a backup, and has anyone restored it?
9. Check whether main on GitHub is protected and whether anything runs tests on it.

If any answer is "I don't know", that is the place to start.

When to stay on Lovable, and when to move off

Stay on Lovable while you are still finding out whether anyone wants the product, when the app holds little personal data and no payments, or when it is an internal tool used by a few people you trust. Fix the RLS and key issues anyway; they are cheap now.

Use a hybrid once you have paying users: keep Lovable for interface work, move the backend to your own Supabase project, and route changes through pull requests with tests and a review of anything touching the database, auth or money.

Move off it when several developers need to work in parallel, when you need server-side logic that Edge Functions make awkward, or when the RLS model has become too complex to reason about. Usually the interface survives and the data and auth layer is rebuilt.

When not to hire us: if the app is a demo for investors, a landing page or a tool only you use, you do not need a production review. Spend the money on users.

What the €99 Prototype Check covers

The Prototype Check is a short, human review for apps built with Lovable, Bolt, v0, Replit, Cursor or similar. For a Lovable app, the person reviewing it looks at both the repository and the live app, with particular attention to:

• RLS on every table and the policies behind it, tested against the live app;
• where roles and permissions are enforced;
• keys in the bundle, the repository and environment variables;
• storage bucket access;
• how payment status is set and whether webhooks are verified;
• whether there are migrations, backups and a separate staging database.

Within 48 hours you get the top security and data risks in writing, ranked, followed by a 15-minute call to go through them. It is a triage, not the full audit. Request it with the Prototype Check form; we reply within one business day with a payment link.

What happens after it

You can take the written findings and fix them yourself, or give them to any developer. That is a perfectly good outcome.

If you want Easify to do the work, the next step is the five-day audit described on the same prototype to production page, quoted after the Prototype Check, followed by the fixes it identifies. If the honest answer is a rebuild, the audit says so, and a rebuild is scoped like any MVP: typically €5,000 to €25,000 over 4 to 12 weeks, at €25 to €45 an hour with a €1,000 minimum project. The MVP cost calculator gives a rough range before you talk to anyone. The €99 is credited against the build if you hire us.

We are based in Budapest and work remotely across Europe on CET, in English or Hungarian. Our engineering team is in India; the people you talk to are in Budapest. If your prototype came from a different tool, the sibling guides cover Bolt, v0 and Replit.