Abandoned Lovable apps: what to do with the old ones still online

Updated Nov 1, 20268 min read

Abandoned Lovable apps keep running after you stop opening them. A published Lovable site has no expiry date, and the database behind it answers anyone who has its public key. Here is how to list your old apps, check what each one exposes, and then fix, freeze or shut each one down without losing data your users may still want back.

Why abandoned Lovable apps stay online

Lovable's docs say published sites have no fixed expiry date. Lovable only unpublishes a project on its own in a Free workspace, and only when the app has had no visits for 12 months, the workspace owner hasn't logged in for 12 months, and no custom domain is connected. Even then it pauses the backend and keeps the project, the code and the data.

The database can stay awake too. Lovable pauses an idle built-in backend after about 7 days without activity, except when scheduled jobs or other background work keep it active. A Supabase project you connected yourself follows Supabase's rules: Free projects pause after a week with too few database requests, and Supabase says a few requests a day are usually enough to prevent that. Paid projects never pause. So an old app that still gets a few visits a day can stay awake.

Old apps also miss newer checks. Lovable's Quick scan runs when you publish, so an app nobody has republished hasn't been checked against the current scan. NVD lists CVE-2025-48757 as insufficient RLS in sites generated by Lovable through April 15, 2025. Lovable disputes it and says each app owner is responsible for their own data. If your app is older than that and you never touched its policies, look at it first.

Find every app you forgot about

Make one list before you change anything. Check these places:

• The Lovable dashboard, in every workspace you belong to. Note which projects are published and which use the built-in backend or your own Supabase.
• The Supabase dashboard, in every organization. Paused projects are listed too, and Supabase lets you restore them for up to a year.
• GitHub. A repo Lovable synced stays in your account even after you delete the project.
• Your domain registrar, Vercel or Netlify, for anything you exported and hosted elsewhere. Old preview links can also stay up, see exposed preview deployments.

Then find out which apps have real people in them. In a Supabase project you own, run this in the SQL Editor:

-- How many accounts, and when did anyone last sign in?
select count(*) as accounts, max(last_sign_in_at) as last_sign_in
from auth.users;

-- Which tables hold rows (approximate counts)
select relname as table_name, n_live_tup as approx_rows
from pg_stat_user_tables
where schemaname = 'public'
order by n_live_tup desc;

On Lovable's built-in backend, the Users and Database views show the same thing. For each app, write down the URL, the backend, the account count, the last sign-in, the tables with personal data and the third-party keys it uses.

Check what an abandoned Lovable app exposes

Start with the tools you already have. In the project's Security view, run the Quick scan and then the Deep scan, which only runs when you start it. For your own Supabase project, open the Security Advisor too. Both read your real settings, so they catch policies added by clicking in the dashboard.

Then test it the way a stranger would. Take the publishable key from the live site and ask for each table while signed out, as shown in how to test Supabase RLS. If the app has sign-ups, create a second account and run the second-account test. A policy that lets any signed-in user read every row passes the signed-out test, so you need both.

Also check:

• Public storage buckets with uploads in them. See open storage buckets.
• A service role key in the frontend code. See service role key in the browser.
• Keys in old commits of the synced repo. See find secrets in git history.

Keep, freeze or shut down: pick one per app

Two questions decide most cases: does anyone still use it, and does it hold real people's data?

Lovable has several ways to take an app down, and they do very different things to your data. Unpublishing and deleting the project both leave the data in place.

From Lovable's and Supabase's docs, checked Nov 1, 2026. Only the two delete rows remove data.

If you keep an app, fix what the checks found, republish so the Quick scan runs, and put it on your list for a check every few months. The Lovable security guide covers the usual fixes.

Freeze an abandoned app while you decide

These steps close the app quickly and can all be undone:

1. Unpublish it: Project settings, then Publishing, then Unpublish project. The live URL stops working and the project stays in the editor.
2. In your own Supabase project, turn off "Allow new users to sign up" in the Auth settings. Supabase says only existing users can then sign in.
3. Take the API grants away from the public roles, so the publishable key reads nothing:

revoke all on all tables in schema public from anon, authenticated;
revoke execute on all functions in schema public from anon, authenticated;

On the built-in backend, ask Lovable to apply these lines as a migration. Requests through the publishable key now fail with a 42501 permission error. The dashboard and your own admin access keep working, and you can grant the privileges back later. If a secret key or service role key ever shipped in the code, rotate it now with the zero-downtime key rotation guide.

Shut down an abandoned Lovable app safely, step by step

Go in this order. The first steps can be undone, the last ones can't.

1. Export the data

   On the built-in backend, open More, then Database, Manage, Settings, and use Export project data. The export includes users' password hashes, so store it encrypted. Download files from More, then Storage. For your own Supabase project, run supabase db dump.

2. Tell the people in it

   If real users signed up, email them before you delete: what happens to their data, the date, and how they can get a copy.

3. Freeze it

   Unpublish, turn off sign-ups and revoke the anon and authenticated grants, as in the section above.

4. Revoke third-party keys

   Delete the Stripe, OpenAI or email keys the app used at each provider. Deleting the app doesn't revoke them.

5. Delete the data

   On the built-in backend, Remove database deletes the database, its backups, user accounts and storage files, and can't be undone. For your own Supabase project, delete the project in its settings. Supabase can't recover it.

6. Delete the project and the repo

   Delete the Lovable project. You can restore it for 60 days, then it's gone. Lovable never deletes the synced GitHub repo, so archive or delete it there.

7. Delete the export when you're done

   Keep the export only as long as you have a reason to, then delete it as well.

If EU residents signed up, GDPR's storage limitation rule says personal data should be kept no longer than necessary. An app nobody uses rarely needs its data. Ask a lawyer about your specific case.

Audit prompt you can paste

Paste this into the old project's Lovable chat or into Cursor with the synced repo. It only asks for a report, so nothing changes until you approve.

This is an old app I may shut down. Do not change any code, data or settings yet. Only report.
1. List every database table. For each: what personal data it holds (emails, names, phone numbers, addresses, payments, health, uploads), whether RLS is enabled, and every policy with its USING and WITH CHECK clauses. Flag USING (true), policies that only check login, and tables with RLS off.
2. List every storage bucket, whether it is public, and what kind of files it holds.
3. List every edge function or API route and whether it checks the signed-in user.
4. List every secret or API key the app uses (Supabase, Stripe, OpenAI, email) and where it is read. Flag any secret key or service_role key in frontend code.
5. List scheduled jobs, webhooks and cron calls that keep the backend active.
Give file and line for each item. Then propose, without applying, the smallest change that blocks public reads and writes while I decide what to do.

Check the report against the dashboard. If the agent says a table is safe, confirm it with the signed-out curl test.

What Leakcade checks

Leakcade's paid scan reads a public GitHub repo, so it fits the repo Lovable synced if that repo is public. It looks for keys in the files and in the last 50 commits, tables created without RLS in the SQL migrations, policies that only check login, and agent files that tell your coding tool to leak secrets. Each finding comes with a fix prompt.

It doesn't connect to your live app or database. Policies you changed in the dashboard and settings on Lovable's built-in backend don't show up in a repo, so the Security view and the curl tests above still matter.

Further reading

1. Lovable docs: Publish and unpublish
2. Lovable docs: Delete a project
3. Lovable docs: Pause, resume or remove your database
4. Lovable docs: Back up, restore and export your database
5. Lovable docs: Security
6. Lovable docs: Supabase integration
7. Supabase docs: Project pausing
8. Supabase docs: Deleting your project
9. Supabase docs: Auth general configuration
10. NVD: CVE-2025-48757
11. GDPR Article 5: storage limitation

FAQ