People ask "how do I export my code from Lovable?" as if it's one button. It's two separate exports, sitting in two different parts of the app, and each one is missing things the other doesn't cover. If you only know about one of them you'll think you have a backup when you have half of one.
Exporting the code
There are two ways to get your Lovable code out.
The first is Git sync. Project settings, Git, connect GitHub (GitLab and Bitbucket work too). Lovable creates a new repository, private by default, and from then on it's two-way: every change you make in chat lands as a commit, and anything you push to the synced branch shows up back in Lovable. This works on the free plan. One annoying limit: you can't point it at a repo you already have. It only exports into a fresh one.
The second is the zip. "Download codebase" lives in Project settings under Git, and also at the bottom of the file tree in the code editor. That one needs a paid plan.
Use Git sync. I mean it. A zip is a snapshot from one afternoon and it's stale by the next prompt. A synced repo gives you history, so when the agent rewrites your auth hook at 11pm and breaks login, you can see exactly which commit did it and roll back without asking the chat to "undo the last change" and hoping it understands.
What the code export contains: your React source, package.json, and the supabase/ folder with migrations/ (the SQL that builds your tables and policies) and functions/ (your edge function code). It does not contain a single row of data. It doesn't contain your uploaded files. And supabase/config.toml holds the project ref of whatever backend the app is connected to, which matters later.
Exporting the data
This is the newer one, and the one most people miss. If your app runs on Lovable Cloud, go to Cloud, then Overview, then Advanced settings, and you'll find Export project data.
What you get is a Postgres dump of the whole database, up to 5 GB, and you can run it once every 24 hours. That rate limit bites if you're rehearsing a migration and mess up the first restore. Plan for one good export per day, not three.
The good news is it's a real dump. Schema, every table's data, RLS policies, database functions and triggers, and your auth users including their password hashes. That last bit is a big change from how things used to work: done properly, your users move to a new project and sign in with the password they already have. Nobody gets a "please reset your password" email they'll assume is phishing.
It's a Postgres custom-format file, not a .sql you can open in a text editor. You need pg_restore to do anything with it, and an old one won't read it.
What neither export gives you
Put the code export and the data export together and you still don't have a working copy of your app. Missing:
Storage files. The data export has the rows in storage.objects that describe your files. Not the files. Your users' avatars, the PDFs they uploaded, product images, all of it has to be pulled down separately. Private buckets can be downloaded from the Cloud storage view as a zip. Public ones you can fetch from their URLs while the old project still exists.
Secret values. You get the names (STRIPE_SECRET_KEY, RESEND_API_KEY, OPENAI_API_KEY), never the values. Go find them in each provider's dashboard before you need them, not during the cutover.
Google sign-in. If your app uses Lovable's managed Google login, that's Lovable's OAuth client, not yours. On your own Supabase project you need your own Google OAuth client, and it has to be published "In production" in Google Cloud. Leave it in Testing and only the test users you listed can log in, which is a fun way to find out at launch.
File URLs saved in your tables. This one is sneaky. If your app saved full public URLs into a column (avatar_url, image_url), those URLs contain the old project's host. They keep working right up until the old backend is removed, and then every image on the site 404s at once.
The trap we walked into
We rehearse every migration before touching the real thing: a throwaway Supabase project, plus a remix of the client's Lovable project. On one of our early ones, the rehearsal went perfectly. Every check passed. Then on the real cutover, two things that never showed up in rehearsal broke.
First, the remix lived in our Lovable workspace, where we're admins. The client's real project lived in theirs, where linking the Supabase organization needed workspace Admin rights that the person on the call didn't have. Twenty minutes lost waiting for the right person to wake up.
Second, during the rehearsal the old Cloud project was still alive, so every stale image URL in the database still loaded. The test said "images fine". They were fine because the thing they pointed at hadn't been deleted yet. We now treat "it loads" as meaningless until the old backend is actually gone.
Neither of those is in any export. That's the general lesson: an export is a copy of what's stored. A migration also has to move what's configured, and what's assumed.
So what should you actually do?
If you just want a backup: turn on Git sync today, and run a data export once a week and keep the file somewhere that isn't Lovable. That's ten minutes and covers the worst case.
If you're leaving Lovable Cloud for your own Supabase, the exports are step one of about a dozen. Before you start, run your project through our free Lovable Cloud migration checker. Paste your public GitHub repo and it tells you which of the problems above apply to your app. Our Lovable Cloud to Supabase page lists everything we move and what it costs.
Or skip the 24-hour export roulette and book a call. We've done the cutover enough times to know where it breaks.
Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.
Top comments (0)