What does NOT transfer automatically
Lovable's export docs say plainly that the export "does not include files in storage, Edge Function code, or your project's secrets," and that "sign-in provider settings and your project's API keys are not part of the database" (Lovable advanced settings). Here is the full list to plan for.
Storage files. Bucket definitions and policies come across with the database, but the files themselves do not. Download them from Cloud and upload them to the new project (Lovable hosting guide). Supabase's backup and restore guide has a script for copying objects between projects.
Secrets and API keys. Stripe, Resend and similar keys stored as Cloud secrets must be set again in the new project. Your new Supabase project also has its own URL and keys, so the app's VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID all change (Lovable hosting guide).
Edge Functions. The code lives in supabase/functions/ in your repo. Deploy it to the new project with the Supabase CLI after linking it (Lovable hosting guide).
Sign-in providers (Google, GitHub and others). Reconfigure each provider in the new Supabase project and update the redirect URLs in the provider's own console (Lovable hosting guide). Also set the Site URL and allowed redirect URLs in Supabase, since the Site URL is the default for email confirmations and password resets (Supabase redirect URLs).
User sessions. Password hashes move, but logged-in sessions may not. Supabase notes that if the JWT secret differs between projects, "existing tokens will become invalid, and users will be required to log in again" (Supabase auth migration). Plan for everyone to sign in once after the switch.
Cron jobs. Lovable advises comparing scheduled jobs after the restore, recreating missing database schedules with cron.schedule, and moving schedules that call your app to a scheduler of your own (Lovable hosting guide).
Database webhooks. Supabase webhooks are triggers that use pg_net, and the target URL is written into the trigger (Supabase webhooks docs). If a webhook points at a function on your old Cloud backend, it will keep calling the old URL. Check each one and update it.
Email sending. Supabase's built-in email service only delivers to your project's team members and is "not meant for production use" (Supabase SMTP docs). Set up custom SMTP before real users try to sign up or reset a password. Lovable notes that sending app emails needs an email domain you own (Lovable Cloud docs).
AI features and app connectors. Lovable says these calls "keep running through Lovable until you replace them" with your own provider accounts (Lovable hosting guide).
Your custom domain. Move it to the new host as the last step, once the new backend is tested (Lovable hosting guide).
Step-by-step migration checklist
This follows the order in Lovable's hosting guide, with the gaps above added.
- Inventory first. List your tables, buckets, Edge Functions, secrets, sign-in providers, cron schedules, webhooks and email settings. Write down each secret's name.
- Export the database from Lovable Cloud and download the
.backup file.
- Download every storage file. Do this before you touch anything else. Removing Cloud "permanently deletes your Cloud instance and cannot be undone" (Lovable Cloud docs).
- Create the new Supabase project and enable any extensions your schema needs.
- Restore with
pg_restore into the new project. Check for errors, then count rows in your main tables and in auth.users.
- Reconfigure auth: providers, redirect URLs, Site URL and custom SMTP.
- Upload storage files and confirm a few file URLs load.
- Set secrets in the new project.
- Deploy Edge Functions with the Supabase CLI.
- Recreate cron jobs and fix webhook URLs.
- Point a test build at the new backend by updating the environment variables. Test sign-up, login, password reset, uploads and payments.
- Check RLS with two accounts. User B must not see User A's data. Our guide on the RLS insert error covers this test.
- Switch traffic and move the domain. Keep the Cloud project until you are sure nothing still calls it.
FAQ
Can I export Lovable Cloud auth users with their passwords? Yes. Lovable says the database export includes user accounts and their password hashes, so users keep their passwords after you restore. They will probably need to sign in again, because the new project uses different keys.
Does the Lovable Cloud export include my uploaded files? No. Storage files, Edge Function code and secrets are excluded. Download the files separately and upload them to the new project.
Can I switch my existing Lovable project from Cloud to my own Supabase? Lovable's docs describe connecting your Supabase project to a new Lovable project and rebuilding the schema there. We could not confirm a supported way to switch an existing Cloud project in place, so plan for the new-project route.
Can I move back from Supabase to Lovable Cloud later? Not at the moment. Lovable's docs say migration from Supabase to Cloud is not supported.
Why can't I restore the export with psql? It is a custom-format archive with zstd compression, not plain SQL. Use pg_restore from a PostgreSQL client that supports zstd.
Planning a move off Lovable Cloud? Our free Launch Check looks at your live app with your permission and shows the top risks we can see. If you want help, see how we fix Lovable apps and Supabase apps, read about our Rescue & Migration service, or try our pricing calculator for an estimate.
Sources: Lovable Cloud docs, Lovable: Export Lovable Cloud data, Lovable: Deploying and hosting outside Lovable, Lovable self-hosting docs, Lovable Supabase integration, Supabase backup and restore between projects, Supabase: migrating auth users between projects, Supabase redirect URLs, Supabase custom SMTP, Supabase Database Webhooks. Checked October 2026.