How to migrate off Lovable Cloud to your own Supabase

Lovable Cloud or your own Supabase: which should you use?

Lovable Cloud is Lovable's built-in backend: database, authentication, storage, edge functions and AI, built on Supabase's open-source foundation and paid for from your Lovable credits. Connecting your own Supabase project means you hold the account, the keys and the bill. Neither is wrong. They suit different stages.

Stay on Cloud while you are still finding out what the product is: it is the fastest way to have a backend at all. Moving is one answer to Lovable limitations, not the only one. Move when you need something Cloud does not give you, such as direct database access for engineers, your own backups and point-in-time recovery, a specific region for compliance, a data processing agreement in your own name, or simply no vendor lock-in on the system of record. Once you own the project, set up Supabase backups and disaster recovery before anything else.

What does Lovable's Cloud export include, and what does it leave behind?

Lovable's Database settings let you export, pause or remove Cloud. Per Lovable's backup documentation, the export contains your full database, both structure and data, and your users' accounts with their password hashes. It does not contain files in storage, Edge Function code or your project's secrets, and sign-in provider settings and API keys have to be configured again at the destination. It works for databases using up to 15 GB of storage, the export file can be at most 5 GB, and you can request one export every 24 hours.

Two more controls matter during a move. Per Lovable's pause and remove documentation, pausing Cloud stops the database, authentication, storage and edge functions, so anything that sends email, takes payments or calls AI stops too, while storage keeps being billed. Removing Cloud permanently deletes the instance and cannot be undone. Do not remove anything until the new setup has run in production for a while.

How do you migrate from Lovable Cloud to Supabase, step by step?

1. 01

   Create and secure the new project

   Create a Supabase project in your own organization, in the region you need, on a plan with backups. Turn on multi-factor authentication for everyone with dashboard access.

2. 02

   Export and import the database

   Export from Lovable's Database settings and restore the export into the new Supabase project. Keep the schema as versioned migrations from here on, so it can be rebuilt from code.

3. 03

   Move what the export leaves out

   Copy storage buckets and files, redeploy Edge Functions from your code, and create new secrets and API keys. Treat every old key as retired rather than copying it.

4. 04

   Connect Lovable to the new backend

   Lovable's documentation describes connecting your own Supabase project to a fresh Lovable project. Do that, and agree how your team keeps prompting there before the switch.

5. 05

   Reconnect authentication

   Set up your sign-in providers (Google, email) again in the new project and test with a real account. Lovable notes that users who are signed in when you switch need to sign in again.

6. 06

   Re-check access rules

   Run Supabase's Security Advisor and the two-user test from our security checklist. Policies do not always survive a move unchanged.

7. 07

   Rehearse, then cut over

   Rehearse the whole move on a copy, then switch production during a quiet hour with a written rollback plan. Keep Cloud paused, not removed, until you are sure.

Will my users have to reset their passwords?

No, if you restore Lovable's export into a Supabase project: Lovable's documentation says the export includes users' accounts and password hashes, so users keep their passwords. Test it before cutover by signing in to the new project with an existing account. What users will notice is having to sign in again if they were signed in when you switched, and any social sign-in you forgot to set up again.

What usually breaks during a Lovable Cloud migration?

• Files. Images and uploads stay behind unless you move storage yourself, and their URLs change.
• Background work. Emails, payment handlers and AI calls live in Edge Functions, which the export does not include.
• Webhooks. Stripe and other providers still point at the old endpoints until you change them, and their signing secrets change with the new functions.
• Access rules. A policy that referenced something Cloud-specific can fail closed (features break) or open (data leaks).
• Lovable itself. Lovable's documentation describes connecting the new Supabase project to a fresh Lovable project, so plan how your team keeps prompting after the move.

Should you migrate yourself or have engineers do it?

A small app with no payments, few files and a handful of users is a reasonable weekend project with the steps above. The risk grows with live payments, many users and files, because a mistake shows up as lost uploads, double charges or data visible to the wrong people. For those apps the move is an engineering job with a rehearsal and a rollback plan. On our plans it is part of the work, followed by running the new backend, with monitoring and emergency production support. If the app is already misbehaving before the move, our vibe coding rescue starts with an architecture review of what exists, then fixes what is risky.