Guide Lovable
Moving from Lovable Cloud to your own Supabase: what to check so nothing breaks or leaks
Short answer
You can move, but Lovable doesn't do it in one step, and Lovable calls the move developer work. If you don't write code, Lovable suggests asking it in the project chat to walk you through the steps, or getting a developer to help. You export your database and restore it into your own Supabase project, then move your storage files and your code, and set up sign in, secrets and any outside services again. If you restore the export into a Supabase project, your users keep their passwords. The risk is in what doesn't come over on its own, so check your security settings again after the move.
Before you start
- Your database needs to be running. You can export only while it is running. If the project is paused, including when credits run out, resume it first.
- Export the database. In your project, open More, then Database, then Manage, then Settings, and use Export data. Lovable emails you when the export is ready and saves it to your project's storage. Download it from More, then Storage, and keep it somewhere else.
- Download your storage files too. They aren't in the export; get them from More, then Storage.
- Know what the export holds. It includes your users' accounts and their password hashes (the scrambled form passwords are stored in).
- Download before you remove anything. Removing the built in database permanently deletes the database, its backups, your users' accounts and your stored files, and it can't be undone. Removing the database also deletes the export saved in storage.
What doesn't come over on its own
The export covers your database structure, your data and your users' accounts. It doesn't include these, so you move them yourself:
- Files in storage
- Server code (Edge Functions)
- Secrets and your project's API keys
- Sign in provider settings and their redirect links
- Scheduled jobs (list them and recreate any missing schedules)
- App connectors and AI features
Your table structure, access rules (RLS) and storage bucket settings come over through your migration files, but the files inside the buckets don't.
The order Lovable suggests
Keep the app running on Lovable Cloud while you prepare the new backend:
- Create a new Supabase project.
- Apply your project's database changes (migrations) in order.
- Restore the database export, which includes user accounts.
- Set up sign in: turn on each provider and update the redirect links.
- Copy storage files into matching buckets.
- Set secrets and deploy server code.
- Replace any Lovable app connectors and AI features with your own integrations.
- Point a test copy of the app at the new backend, and leave the Lovable project unchanged.
- Check everything on that test copy.
- Switch: restore the final export, update
.envandsupabase/config.tomlin the Lovable project, and move traffic.
Security checks after the move
- Run the Supabase Security Advisor on the new project and fix what it flags.
- Confirm every table still has its access rules (RLS). See How to fix Supabase RLS in a Lovable app.
- Check that private files are in private buckets. See Supabase storage bucket public.
- Keep admin keys (
service_roleor secret keys) out of the browser. See Supabase secret key exposed. - Test with two different accounts, and again while signed out. See Check your Supabase app before launch.
Switching over
Users who are signed in when you switch need to sign in again, so test that sign in works after restoring. Lovable's own Publish button keeps publishing to Lovable hosting only.
Why move at all?
On Lovable Cloud you can't get the database address for outside tools or the admin key for services like n8n or Make.com. For those, Supabase says you need your own project.
Want help with the checks?
AI agents run the checks and a human engineer reviews and approves every report and change. It is not a penetration test, a security guarantee or a compliance certification.