Lovable Cloud to Supabase migration
A Lovable Cloud to Supabase migration puts your database, files, functions and secrets in a Supabase project you own. I've moved 10,187 accounts into Supabase without a single password reset.
Where you are
Your app runs on Lovable Cloud with paying users on it, and you want its database in a Supabase project of your own. Until July 2026 there was no standard way to get it out.
What the export carries, and what it leaves
Lovable added Export data and Remove Lovable Cloud in July 2026. The export is a pg_dump of the database, with the schema, the row-level security rules and the users' password hashes, so a restore into Supabase keeps each password working. It's capped at 5 GB and can be run once every 24 hours.
Source r/lovable, Export data and Remove Lovable Cloud, 3 July 2026
What it leaves out is everything around the database, and that's where a move breaks.
- Storage files. Every bucket copied across, and any file address saved in the database rewritten to point at the new project.
- Edge functions. Redeployed to the new project and called at their new address, with the settings each one ran on.
- Secrets. The Stripe, OpenAI and email keys set again in the new project, since none of them travel in the file.
- Sign-in providers. Google and any other provider pointed at the new project's callback, with the site address and redirect URLs set to match.
- Stripe webhooks. A new endpoint on the new project with its own signing secret, and the old one switched off only once the new one is taking events.
How the move runs
A rehearsal comes first, from one export into a fresh Supabase project, with sign-in tested on real accounts and a Stripe event sent through every webhook. The real move comes a day or more later, when the next export is allowed. Writes pause, the final export is restored, the app switches to the new project's address and keys, and Stripe starts posting there. Anyone signed in at that moment signs in once more with the password they already have. Lovable Cloud stays in place until the new project has held up under real use.
What I do
- A Supabase project in your name, where pg_dump and the database credentials are yours whenever you want them.
- An inventory of everything your app keeps outside its database, made before anything moves.
- Every flow tested on the new project before the switch, from sign-up to a paid renewal.
- The switch timed for your quietest hours.
- A written record of what moved, where it lives now and how to go back.
The work
Saif is the true definition of not compromising on quality.
The first reply lists what sits outside your database and the order to move it.