Account & Billing

The Lovable Exit Checklist: Get Everything Out Before You Cancel

Do not cancel first. Export everything while your subscription is still active: your code to a GitHub repo you own, your Supabase database, your auth users, and your storage buckets. Cancelling or downgrading can lock the editor and the project export controls behind a paywall, leaving your data stranded inside an account you no longer pay for. This checklist gets it all out in the right order.

Book a free audit call See the fix-it service

By Founder Name · Last verified: 2026-06-25

Why can't I just cancel Lovable and export my project afterward?

Because cancelling or downgrading restricts the exact controls you need to export. The GitHub sync toggle, the editor, and project settings often sit behind your paid plan. Once you drop to free or a cancelled state, you can be locked out of the buttons that pull your code and connect your own backend. Your data is not deleted, but you may lose self-service access to extract it.

There is a common, costly assumption here: that the project sitting in your dashboard will always be one click away from export. In practice, the export surface area is a paid feature. The day your billing lapses, the GitHub connection screen, the publish controls, and sometimes the editor itself stop responding the way they did when you were a paying customer.

The safe sequence is the opposite of what most people do. Export every asset first, verify each export actually loaded somewhere you control, and only then touch your billing. Treat cancellation as the final step, not the first one. Everything below assumes your subscription is still active right now.

What NOT to do: do not click cancel or downgrade to free to 'save money this month' and plan to export next week. The plan change can take effect immediately and remove the export controls before you have pulled anything out. Export first. Cancel last.

What exactly do I need to get out before I leave Lovable?

Four assets, and the code is the least important of them. Your frontend and backend code, your Supabase database (schema plus rows), your authenticated user accounts, and your storage bucket files. Code regenerates and exports cleanly. Auth users, live data, and uploaded files do not regenerate — if you leave them behind they are genuinely hard to recover. Inventory all four before you start.

Most exit panics focus entirely on the code, which is actually the safest asset because Lovable syncs it to GitHub. The real risk lives in your backend: the rows in your tables, the users who signed up, and the files they uploaded. These are the things that do not exist anywhere except inside the connected Supabase project, and they are the things people discover are missing only after they have cancelled.

Lovable Exit Inventory — What to Extract and Where It Lives
Asset	Where it lives	How to extract	Recoverable after cancel?
Frontend + backend code	Lovable editor, synced to GitHub	GitHub sync / repo clone	Usually — if GitHub was connected
Database schema + rows	Connected Supabase project	pg_dump or Supabase dashboard export	Hard — needs Supabase access
Auth users	Supabase auth.users table	Supabase Auth export / SQL	Hard — passwords are hashed, not portable
Storage bucket files	Supabase Storage	Supabase Storage download / API	Hard — must be pulled file by file
Environment variables / secrets	Lovable + Supabase settings	Copy values manually before leaving	No — never shown again once gone
Edge functions	Supabase Functions	Supabase CLI pull	Hard — needs project ref + access token

How do I get my code out of Lovable first?

Connect Lovable to GitHub and push your code to a repository you own, then clone it locally to prove the export is real. The GitHub sync is the cleanest, most complete code export Lovable offers — it includes your full frontend, backend, and config. Do this while subscribed, because the GitHub connection screen is a paid-plan control that can disappear on downgrade.

In the Lovable editor, open the GitHub integration and connect it to a GitHub account you personally own — not a client's, not a shared one.
Push the project to a new repository and confirm the latest commit timestamp matches your most recent changes in the editor.
Clone the repo locally: git clone https://github.com/your-username/your-repo.git
Run npm install then npm run dev and confirm the app boots locally without missing-file errors.
If the build fails on a missing import or a missing env var, note it now — that is a What-Breaks-on-Export gap, not a reason to stop. Capture it and continue.

Verify the commit is current before you celebrate. A connected repo that stopped syncing weeks ago is The Stale-Commit Deploy in disguise — you have an export, but it is an old one. Check the latest commit hash and timestamp against the editor before trusting it.

How do I export my Supabase database, users, and storage?

Go straight to the Supabase project connected to your Lovable app — this data lives in Supabase, not Lovable, so Supabase access is what you need. Dump the database with pg_dump, export auth users, and download every storage bucket. This is the part people skip and regret, because rows, accounts, and uploaded files do not regenerate from a code export.

If your Lovable plan provisioned a managed Supabase instance for you, confirm you have direct Supabase dashboard access to it before you cancel anything. Without that access, your database is reachable only through the Lovable editor, and losing the editor means losing the path to your own data.

Open the Supabase dashboard for the project linked to your Lovable app and confirm you can log in directly.
Database: run a full dump — pg_dump "postgresql://USER:PASS@HOST:5432/postgres" > backup.sql — or use the dashboard backup export.
Auth users: export the auth.users table via SQL or the dashboard so you keep emails, IDs, and metadata (note: password hashes are not portable to a new provider).
Storage: download every bucket's contents — via the dashboard for small sets, or the Storage API / Supabase CLI for large ones.
Restore the dump into a throwaway local Postgres or a fresh Supabase project to prove the backup is complete and not corrupt.

Auth password hashes do not transfer cleanly between providers. If you move to your own Supabase you can often migrate the hashes; if you move to a different auth system entirely, plan a password-reset flow for every user. Decide this before you cancel, not after.

What about my environment variables and secrets — do those come out too?

Copy every secret value manually before you leave, because secrets are write-only — once you navigate away you cannot read them again, only overwrite them. Your Stripe keys, API tokens, and service credentials live in Lovable and Supabase settings panels that often mask the value after saving. If you have not recorded them somewhere safe, a cancelled account can take them with it.

This is The Vanishing Env-Var, and it bites hardest at exit time. The exported code references variables like VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, and your Stripe secret key by name, but the actual values are not in the repo — they live in the platform's environment settings. Clone the code, find every process.env or import.meta.env reference, and make sure you have captured a value for each one.

Store the captured secrets in a password manager, never in a committed file. If any secret was ever exposed in client-side code or a public repo during the build, treat the exit as your moment to rotate it — generate a fresh key on the provider side once you are off Lovable.

Grep your cloned repo for env references before cancelling: grep -rE 'process.env|import.meta.env' src/ — every match is a variable whose value you must have captured from the platform settings, because it is not in the code.

How do I verify the export is actually complete before I cancel?

Stand the app up somewhere you fully control and click through it before you touch billing. An export that sits in a folder is not a proven export. Clone the repo, restore the database dump, wire in your captured secrets, and run the real user flows. If sign-up, login, a data read, a data write, and a file upload all work, your exit is safe.

Clone the GitHub repo and run npm install && npm run dev locally with no errors.
Restore your database dump into a fresh Supabase or local Postgres and point the app at it.
Add your captured environment variables to a local .env file and restart.
Sign up a new test user, then log out and log back in — confirm auth works end to end.
Create a record, reload, and confirm it persisted; upload a file and confirm it lands in storage.
Only when all five flows pass: return to Lovable billing and cancel or downgrade.

Do not trust 'it looks fine in the Lovable preview.' The Lovable preview still runs against Lovable's connected backend. The only export that counts is one running on infrastructure you own with secrets you captured. Verify there before you cancel.

When should I have someone do this migration for me instead?

Bring in a senior engineer when the app has real users, real revenue, or a managed backend you cannot directly access. A failed self-export at exit time is uniquely dangerous: you discover the gap after cancelling, when the editor is already locked. A migration specialist exports all four assets, stands the app up on infrastructure you own, and verifies it before any billing change.

The judgement call is simple. If your Lovable app is a side project with no live users, the steps above are very doable in an afternoon. If real customers have accounts, if money flows through Stripe, or if you are unsure whether you even have direct Supabase access, the downside of a botched exit is losing customer data — and that is not worth saving a single subscription month. We do this as a fixed-scope migration: full export, your own GitHub and Supabase, verified live, with you keeping ownership throughout.

Frequently asked questions

If I cancel Lovable, do I lose my code and data immediately?

Your data is not deleted the moment you cancel, but your self-service access to export it can be. The GitHub sync toggle, the editor, and project settings often sit behind your paid plan. After a cancel or downgrade you may be locked out of the buttons that pull your code and connect your backend. Export everything first, verify it, then cancel.

What is the correct order to leave Lovable?

Export code to a GitHub repo you own, then export your Supabase database, auth users, and storage, then capture every secret value, then verify the app runs on your own infrastructure — and only after all of that, cancel or downgrade your plan. Cancelling first risks locking the export controls before you have pulled your data out.

Does downgrading to the free plan have the same risk as cancelling?

Often yes. Downgrading can immediately remove paid-plan controls like GitHub sync and certain project settings, which are exactly what you need to export. Treat a downgrade with the same caution as a full cancel: export and verify everything while you are still on the paid plan, then change your billing as the final step.

Will my users' passwords transfer when I leave Lovable?

Not cleanly. Auth passwords are stored as one-way hashes. If you migrate to your own Supabase project you can often carry the hashes over so users keep their passwords. If you move to a completely different auth system, the hashes will not port, so plan a password-reset flow for every user. Decide this before you cancel, not after.

I already cancelled and lost access — can I still get my project out?

Often yes, but it gets harder. If GitHub was connected before you cancelled, your code is safe in that repo. Your database and storage depend on whether you still have direct Supabase access. Do not start a new project or overwrite anything. Book a call and we can assess what is still recoverable and pull it out for you.

Where is my Lovable app's database actually stored?

In Supabase, not in Lovable. Lovable generates and edits the code, but your tables, rows, authenticated users, and uploaded files live in a connected Supabase project. That is why the most important part of leaving Lovable is securing direct access to that Supabase project — your real data lives there, and a code export alone does not include it.

Do I need to copy my environment variables before leaving?

Yes, and this is the most-missed step. Secrets like your Supabase keys and Stripe keys are referenced by name in the exported code, but their actual values live in platform settings and are usually masked after saving. Copy every value into a password manager before you cancel. Once the account lapses, you may not be able to read them again — only overwrite them.

How long does a proper Lovable exit take?

For a small side project with direct backend access, an afternoon: connect GitHub, dump the database, download storage, capture secrets, and verify locally. For an app with live users, payments, or a managed backend you cannot directly reach, it is a larger job where the risk of a missed asset is real. That is where a fixed-scope migration is worth it.

Can I keep my app running while I migrate off Lovable?

Yes. The safe pattern is to stand up a verified copy on your own infrastructure first, confirm every user flow works, then cut over and only afterward cancel Lovable. Because you are exporting rather than deleting, your live Lovable app keeps serving users the entire time you build and test the migration target. No downtime is required.

What is the single biggest mistake people make leaving Lovable?

Cancelling first to stop the billing, then trying to export. The plan change can take effect immediately and strip away the GitHub, editor, and settings controls you need to pull your code and data. By the time you realise, you are locked out of an account that still holds your only copy of your users and database. Always export and verify before you cancel.

Keep reading

Talk to a senior engineer — not a salesperson.

Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.

Book a free audit call