To migrate a Lovable Cloud app to your own Supabase project, you export the database from Lovable, restore it into a new Supabase project, carry the storage files, edge functions and secrets across by hand, then remove Lovable Cloud and connect the new project to the same Lovable project. Lovable's own docs put it plainly: "There is no automatic migration between the built-in backend and your own Supabase project, in either direction." (checked October 23, 2026, Supabase integration docs).
So it's a manual job, but a well-defined one. Here's how the five stages go, and where they go wrong.
1. Export the database
The export moved in Lovable's UI this year. It now lives under More, Database, Manage, Settings, as "Export project data". You start it, Lovable emails you when the file is ready, and you download it from More, Storage. The details from the database backups docs:
- it's a compressed PostgreSQL archive, loaded with
pg_restore, with your full schema and data, auth users and their password hashes included - databases up to 15 GB, an export file of at most 5 GB, one export every 24 hours
- the database has to be running, so a project paused for zero credits gets woken up first
- removing the database deletes the export too, so download it before anything else
What it leaves out is the list that matters: files in storage, edge function code, secrets, sign-in provider settings and API keys.
2. Create the Supabase project and restore
Make the project in your own Supabase organization, on the region your users are closest to. Then restore the archive with pg_restore.
Lovable's docs suggest a different route: connect the new project and ask Lovable to rebuild the schema. I don't like it. A rebuilt schema is the AI's reading of your code, not your database. Policies, triggers and functions that the code doesn't mention don't come back, and you still have to load the data into whatever it built. The archive is the real thing. Restore that.
A straight restore has its own trap, though. It leaves the public anon role with more access to tables and functions than it had on Cloud. Nothing breaks, so nobody notices, and the app is now less private than it was the day before. Check the grants before the app talks to the new database.
3. Move what the export left behind
This is the part that takes the time.
Storage files. The export has the bucket records, not the files. Every file has to be downloaded and uploaded again with its path intact. On one migration we rehearsed the whole thing on a throwaway project first and still got caught here: image URLs saved in a table pointed at the old Lovable Cloud host. They kept working, right up until Cloud was removed, and then every image in the app 404'd.
Edge functions. The code is in your repo, so it deploys again with the Supabase CLI. Check each function's verify_jwt setting while you're at it.
Secrets. You can see their names in Lovable, never their values. Stripe, OpenAI, Resend and the rest have to be re-entered from the providers' own dashboards. Make the list before the cutover, not during it.
Sign-in. Lovable's managed Google login doesn't follow you. You need your own Google OAuth client, published "In production", plus redirect URLs, email templates and SMTP set again in the Supabase dashboard.
4. Remove Cloud and connect
Linking a Supabase organization to a Lovable workspace needs a workspace owner or admin. After that, anyone with edit access can connect the project. Lovable's Cloud settings have the option to remove Cloud from the project. Then the same project connects to your Supabase project, and you keep building in Lovable as before.
Two things catch people here. The published site keeps talking to the old backend until you republish. And supabase/config.toml in the repo still names the old project, so the next edge function deploy can go to the wrong place.
5. Check before you tell anyone
Count rows table by table against the old backend, sign in as a real test user (with a password and with Google), open a few uploaded files, and trigger every email the app sends. Users who were signed in at the switch have to sign in again. Plan the cutover for your quietest hour.
How long it takes
A small app (under 10 tables, a few hundred users, one bucket) is a day of careful work if you know Postgres. Most of that day is stages 3 and 5, not the export. If you don't know what pg_restore --list prints, or what a grant is, it's longer, and the mistakes are the quiet kind.
We do this as a fixed-price job: Lovable Cloud to Supabase migration, $150 to $600 by table count, usually done in 1 to 2 days, and you keep building in the same Lovable project. If you're not sure the move is worth it yet, the Lovable cost check shows what your app would cost on Cloud and on your own Supabase, side by side. For the full list of what moves and what breaks, there's our migration checklist.
Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.
Top comments (0)