In short
Yes, you can leave Lovable, and Lovable states that what you create belongs to you. But nothing happens in one click. The code goes through GitHub, the database through an export, and the files, secrets and sign-in setup have to be redone by hand. If you restore the database into Supabase, your users keep their passwords.
This guide is based on Lovable’s official documentation, read on 31 October 2026. Lovable changes fast: check each point before you act.
Do you really need to leave?
Lovable itself says most teams don’t need to leave. The good reasons are concrete: a rule about where your data is stored, your own deployment pipeline, or a company policy on hosting.
If your app is struggling because of bugs or security holes, changing host won’t fix them. They’ll follow you. And every piece you move becomes yours to run, update and protect.
You don’t have to move everything: move only the app and keep Lovable’s backend, or move the backend and keep using the editor.
Check your app’s version first
Lovable builds apps in two ways, and they aren’t hosted the same way. Open package.json: if you see @tanstack/react-start, your app runs on TanStack Start.
| Your app | What it needs |
|---|---|
| TanStack Start (created since 13 May 2026) | A host that runs server code. Plain static files are not enough. |
| React + Vite (older) | A static file host, with a fallback to index.html for inner pages. |
So a guide written before May 2026 may not cover your case.
What comes with you and what doesn’t
| Item | How it works |
|---|---|
| The code | Git sync on all plans, or a .zip download on paid plans. |
| The database structure and RLS rules | In the SQL migration files, with the code. |
| The data | Full database export (a PostgreSQL archive to restore with pg_restore), or CSV table by table. |
| User accounts | In the export, with hashed passwords. Restored into Supabase, they keep their passwords, but everyone has to sign in again. |
| Files uploaded by users | Neither in the code nor in the export. Download them, then upload them again by hand. |
| Secrets and API keys | Not exported. Create them again. |
| Sign-in with Google or GitHub | Set it up again, adding the new URL to the allowed redirect URLs. |
| Edge functions | The code is in supabase/functions/. Deploy them with the Supabase command-line tool. |
| Scheduled tasks | List them, then create them again if they’re missing after the restore. |
| App connectors | Not exported. Replace them with your own integration with each service. |
| AI features | They go through Lovable. Replace them with your own account with a provider. |
The order to follow
Keep the current app online throughout the preparation. The switch comes at the end.
Connect the project to GitHub
Lovable creates a new repository: you can’t connect it to an existing one. Don’t rewrite the history of the synced branch (
force-push,rebase).Run the app on your computer
This shows what it needs to install and which variables it needs, before a host complicates things.
Deploy to a temporary URL
Use Node.js 22 and fill in the variables. The secrets read by your server functions are not in the repository.
Create the destination Supabase project
Choose the region carefully: Lovable says it can’t be changed afterwards when it creates the project itself. Check this point if you create it yourself.
Restore the data and test
Restore the export and the files, connect your test version to them, then test with migrated accounts: open an inner page, sign in, sign out, write data, upload a file.
Look for what still calls Lovable
Search the code: connectors, AI features, the old backend’s URL. All of it keeps going through Lovable until you replace it.
Make the final copy
Anything written after the export isn’t in it. Stop writes from users, scheduled tasks and webhooks, run another export, copy the changed files, restore.
Switch over
Point your domain to the new host, then unpublish the app on Lovable.
Shut down the old services
Once you have checked the export and the files, delete the database, then disconnect Git or delete the project. Check your subscription too.
The traps to know about
Only one export every 24 hours
If the final copy fails, you may have to wait a day to try again, so plan for it. The export is also limited to a 15 GB database and a 5 GB file. Beyond that, you have to contact support.
The database has to be running
No export if the project is paused, including when your workspace is out of credits. You have to restart it first.
Deleting the database deletes the exports
The export is saved in the project’s storage. Download it and keep it somewhere else before deleting anything.
VITE_variables are frozen at build timeThey end up in the code sent to the browser. You have to rebuild to change them, and they must never hold a secret.
PostgreSQL alone is not enough
The supported destinations are managed Supabase and self-hosted Supabase. With a plain PostgreSQL database, you’re missing user sign-in, storage, realtime and functions.
Payments don’t come with you
If you change payment provider, products and prices have to be created again. Subscribers stay with the old provider until they subscribe again or you move them.
The old URL stays online
Your
lovable.appURL keeps serving the last published version until you unpublish. And your subscription keeps running until you change it.