How to migrate from Lovable Cloud to your own Supabase project

To migrate from Lovable Cloud to your own Supabase, create the destination project, apply the migrations from your repository and restore Lovable’s .backup export with pg_restore. Then copy the storage files, recreate secrets, Edge Functions and scheduled jobs, and switch the app’s variables. Users keep their passwords. Open sessions end.

Heartscale’s recommendation: run at least one full restore on a test Supabase project and time it before you schedule the cutover. If the app already has real users, social sign-in or payments, get the plan reviewed before you pause writes.

This guide covers only the database and backend. For the code, build, server and domain, see how to leave Lovable.

Lovable Cloud vs. Supabase: what changes

Lovable Cloud is Lovable’s built-in backend, and it is built on Supabase (Lovable Cloud). It bundles the database, auth, storage, Edge Functions, secrets, jobs and logs, and bills all of it from one credit balance.

In your own Supabase project, each piece becomes yours: the account, the billing, the dashboard and the maintenance. Three rules from Lovable’s docs:

• The supported destinations are managed Supabase and self-hosted Supabase. Plain PostgreSQL or another provider means rebuilding auth, storage and functions yourself.
• Moving only the PostgreSQL database does not move auth, storage, realtime or Edge Functions.
• There is no way back: migrating from Supabase to Lovable Cloud is not currently supported (Lovable Cloud).

If you choose to self-host Supabase, the recommended route is Docker. Supabase’s own docs say backups, security and Postgres maintenance are on you, and that support comes from the community.

What the export includes and what it leaves out

From the Database backups page:

Included	Not included
Database structure and data	Storage files
User accounts	Edge Function code (it lives in the repository)
Password hashes	Secrets
	Sign-in provider settings
	Project API keys

Limits: databases up to 15 GB, an export file of up to 5 GB and one export every 24 hours. The database must be running. If the project paused because credits ran out, resume it before exporting.

The 24-hour limit drives your schedule. You will need at least two exports: one for the test run and one for the cutover.

Step 1: create the destination project

In Supabase, click New project. Pick a strong database password and a region close to your users. Note the Project ID, the URL (https://<id>.supabase.co) and the publishable key.

Before restoring, enable on the new project any extensions the old database used, plus Database Webhooks if you had them. Supabase’s backup and restore guide asks for this before loading data.

Step 2: apply the schema from your migrations

The schema comes from the migrations stored in your repository. Per Lovable’s docs:

• supabase/migrations/ folder: run the SQL files in order of their timestamp prefix, oldest first.
• drizzle/migrations/ folder: follow the order in meta/_journal.json. The Supabase CLI does not apply this format.

With the CLI, for the Supabase layout:

npx supabase login
npx supabase link --project-ref <new-project-id>
npx supabase db push

To check for drift between the repository and the database, run npx supabase db diff --linked with Docker running.

Migrations also create the buckets and their access policies. Check that your RLS policies came through complete: see how to configure Supabase RLS.

Step 3: export and restore the data

In Lovable, go to More → Database → Manage → Settings → Export project data → Export data. On the Database card, click Export, then Start export. Lovable emails you when it is ready. Download the file from More → Storage and keep a copy outside Lovable.

The file is a PostgreSQL custom-format .backup with zstd compression. If it arrives inside a .zip, extract it first. pg_dump gained zstd compression in version 16 (PostgreSQL 16 release notes), so use pg_restore 16 or newer, built with zstd.

Since step 2 already applied the schema, restore only the data. Here is the sequence, using the options described in the pg_restore docs:

# 1. list the archive contents
pg_restore --list export.backup > export.list

# 2. edit export.list: comment out with ";" anything you do not want restored

# 3. restore data only, in list order, all or nothing
PGOPTIONS="-c session_replication_role=replica" \
pg_restore --data-only --no-owner --single-transaction \
  --use-list=export.list \
  --dbname "<Session pooler connection string>" \
  export.backup

What each part does:

• --data-only restores table data and sequence values without recreating the schema.
• --single-transaction applies everything or nothing. If something fails, the database stays as it was.
• session_replication_role = replica stops triggers from firing during the load. Supabase uses the same setting in its restore guide. Without it, a trigger that creates a profile for each new user would create duplicate profiles or make the load fail. It also turns off foreign key checks, so compare row counts afterwards (PostgreSQL).
• The Session pooler connection string works on IPv4-only networks. The direct connection needs IPv6 or the IPv4 add-on.

In the list, keep the data for public, auth.users and auth.identities. Leave out the sessions and tokens in auth, which are useless on the new project. Also leave out the storage schema tables: the file records are created when you upload the files in step 5.

Do this on a test project first. Lovable flags two issues: records that migrations already inserted can collide with the ones in the archive, and sequence values must come along. Do not add --clean without reading what it does: it drops the objects before restoring them.

In our reviews, after the test restore, we compare the row count of every public table and of auth.users on both databases. Only then do we sign in with a migrated account and clear the cutover.

Step 4: auth, with passwords and without sessions

The password hashes are in the archive, so users sign in with the same password. Supabase’s guide to migrating auth users explains why sessions end: each project signs tokens with its own secret, so old tokens stop working. Tell your users they will need to sign in again.

On the new project:

1. In Authentication → Sign In / Providers, enable each provider the app used.
2. In each provider’s console (Google, GitHub and others), update the redirect URL to the new Supabase project.
3. On the URL Configuration page, set the Site URL to your production address and list under Redirect URLs the addresses sign-in may return to (Redirect URLs). The Site URL is used in confirmation and password reset emails.

If any account does not come back, offer a password reset flow.

Step 5: storage files

In Lovable, open More → Storage and download the files from each bucket. In Supabase, open Storage and upload them to buckets with the same names, keeping the folders. If your database stores file paths, they depend on those names. If it stores full URLs, they point to the old project’s address and need updating.

Before deleting anything, compare the file count in each bucket on both sides.

Step 6: secrets and Edge Functions

Secrets are not in the export or the repository. Recreate each one on Supabase’s Edge Function Secrets page or with the CLI (Secrets):

supabase secrets set --env-file .env.production
supabase secrets list

Names starting with SUPABASE_ are reserved. SUPABASE_URL and the project keys reach your functions without any setup.

Function code lives in supabase/functions/. Deploy it with:

npx supabase functions deploy

Step 7: scheduled jobs

List the jobs in Lovable’s jobs area and compare them with what exists in the new database after the restore. Recreate missing ones with cron.schedule in SQL. Jobs that call your app from outside need an external scheduler.

Check each job’s destination URL and credentials. Turn on the new side’s jobs only at cutover, so the same job does not run on both databases.

Step 8: test, then cut over with writes paused

Leave the Lovable project as it is. On a separate copy of the app, set VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID and build again: these variables are embedded at build time. On TanStack Start, also set SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and SUPABASE_PROJECT_ID.

Test that the app loads, writes and reads records, that a migrated account can sign in, that uploads and downloads work and that functions respond. Time the export and the restore.

At cutover, per Lovable’s docs:

1. Replace anything in the code that still runs through Lovable: app connectors, AI features and the built-in backend URL.
2. Pause writes from users, jobs, webhooks and integrations.
3. Request the final export and restore it into the new project.
4. Copy the files that changed since your last copy.
5. In .env, switch the Supabase variables. In supabase/config.toml, switch the project_id.
6. Turn on the scheduled jobs on the new side and reopen the app.

The time you measured in the test run is how long the app goes without writes.

Before you remove Lovable Cloud

Removing the database under More → Database → Manage → Settings → Remove database deletes the database, its backups, user accounts and files. That includes exports saved in the project’s storage, and it cannot be undone (Lovable Cloud). Download and verify everything first.

The .backup holds password hashes and personal data. Keep it somewhere safe and delete stray copies. Your Lovable subscription and Cloud usage continue until you change your plan.

Do it yourself or hire help?

This guide is enough for many projects. What changes the decision is the cost of a cutover that goes wrong.

Situation	Path
App still in testing, no real users, and someone on the team uses the terminal and SQL	Do it yourself with this guide, on a test project first
Real users signing in with Google or another provider	Worth bringing in a team: sessions, redirect URLs and password resets have to line up in the same window
Payments, webhooks or scheduled jobs writing to the database	Worth bringing in a team like ours: the write pause has to cover every entry point
Personal data in the database, a tight deadline or nobody technical on the team	Request a Heartscale diagnostic before you export: you get the plan and the estimated write pause before anyone touches the database

Request a Heartscale diagnostic

Our team measures your database and storage, lists your project’s jobs, secrets and functions, and runs the restore on a test Supabase before the cutover. You receive a platform migration plan with the estimated write pause and a fixed price.

The launch-price diagnostic costs US$ 19 (was US$ 79) and is credited toward the migration if you go ahead. We only work on apps whose owners can prove they own them.

Request the diagnostic