How to Migrate Lovable Cloud to Supabase

What Lovable Cloud actually is

Lovable Cloud is Lovable's managed backend: a dedicated Postgres database with authentication, storage and Edge Functions that Lovable provisions and operates for you inside your project. Migrating away from it means standing up a Supabase project you create and control yourself, moving the schema, data and configuration onto it, and pointing your frontend at the new project instead of Lovable's managed one.

Before you start

Have these ready before you touch any data:

• A Supabase account and a new, empty project created in the region you want to run in
• The Supabase CLI installed locally (npm install -g supabase)
• psql or another Postgres client available on your machine
• Read access to your Lovable project's underlying database connection details — check Project Settings → Cloud/Database in Lovable, or ask Lovable support for direct Postgres credentials if they aren't exposed on your plan
• A GitHub repository for the frontend code, since it will be redeployed independently of Lovable

Step 1: Export the schema

Start with structure only, no rows, so you can review it before anything gets loaded into the new project.

pg_dump "$LOVABLE_DB_URL" \
  --schema-only \
  --no-owner \
  --no-privileges \
  -f schema.sql

Read through schema.sql before loading it. Check for extensions your app depends on (uuid-ossp, pgvector and similar) — Supabase enables some by default, but not all, so add create extension if not exists statements for anything missing.

psql "$SUPABASE_DB_URL" -f schema.sql

Step 2: Migrate the data

Once the schema matches, copy the rows across. Disabling triggers during the load avoids RLS and trigger logic firing while historical data is being inserted.

pg_dump "$LOVABLE_DB_URL" \
  --data-only \
  --disable-triggers \
  -f data.sql

psql "$SUPABASE_DB_URL" -f data.sql

For large tables, load them one at a time with COPY instead of a single combined dump, so a failure partway through only costs you one table's retry, not the whole database.

Step 3: Recreate Row Level Security (RLS) policies

A schema-only dump usually captures CREATE POLICY statements, since they're DDL, but verify this explicitly rather than assuming it. A table with RLS enabled and no policies blocks everyone, including your own app.

alter table public.projects enable row level security;

create policy "Users can read their own projects"
on public.projects for select
using (auth.uid() = owner_id);

Run select * from pg_policies; on both the old and new database and compare the results table by table, so nothing is silently left wide open or fully locked.

Step 4: Migrate authentication

Supabase auth lives in the auth schema (auth.users, auth.identities), which is regular Postgres, so email and password accounts move the same way as any other table.

pg_dump "$LOVABLE_DB_URL" --data-only -t auth.users -t auth.identities -f auth.sql
psql "$SUPABASE_DB_URL" -f auth.sql

Existing bcrypt password hashes carry over, so users don't need to reset passwords for email and password logins. What doesn't carry over automatically:

• OAuth providers (Google, GitHub and similar) — each needs reconfiguring in the new project with its own client ID, secret and callback URL
• Magic links and OTP codes issued before the migration, since they're signed with the old project's JWT secret
• Active sessions — every signed-in user is logged out once the frontend switches to the new project's API URL and anon key, because tokens are signed per project

Step 5: Move storage buckets and files

Storage buckets and their policies aren't part of a schema dump — they live in Supabase Storage, not a plain Postgres table you can pg_dump. Recreate the same bucket names and policies, then copy the files across.

• Recreate each bucket with the same name and the same public or private setting
• Recreate the storage policies for each bucket to match the old project
• Copy the objects themselves — the Supabase CLI for a handful of files, or a small script against the Storage API for larger buckets

supabase storage cp \
  --experimental \
  ss:///old-bucket/path/file.pdf \
  ss:///new-bucket/path/file.pdf

For buckets with thousands of files, script it against the Storage REST API instead — list, download, upload — so a failed file can be retried without redoing the whole bucket.

Step 6: Redeploy Edge Functions

If your app uses server-side functions, Lovable Cloud runs these as Supabase Edge Functions behind the scenes. Pull the function source into your repository and redeploy it against the new project.

supabase functions deploy your-function-name --project-ref <new-project-ref>

Function code doesn't bring its environment variables with it — those need to be set again on the new project, covered next.

Step 7: Move secrets and environment variables

• The new project's Supabase URL and anon/public key, from its API settings
• The service role key for server-side calls, kept server-side only and never shipped in frontend code
• Edge Function secrets (Stripe secret key, Resend API key, OpenAI key and similar), reset with supabase secrets set
• Third-party webhook secrets — a Stripe webhook signing secret changes whenever the endpoint URL changes

supabase secrets set STRIPE_SECRET_KEY=sk_live_... RESEND_API_KEY=re_...

Step 8: Update the frontend and deploy independently

Point the Supabase client at the new project, push the code to GitHub, and deploy the frontend on Vercel rather than through Lovable's own hosting.

VITE_SUPABASE_URL=https://<new-project-ref>.supabase.co
VITE_SUPABASE_ANON_KEY=<new-anon-key>

Step 9: Test before you cut over

• Sign up and log in with email and password, and with every OAuth provider you support
• Confirm RLS by testing as at least two different user roles, not just as an admin
• Upload and download a file through every storage bucket the app uses
• Trigger each Edge Function and check its logs in the new project
• Send a real Stripe test webhook and confirm the signature validates against the new signing secret
• Send a real transactional email through your provider end to end
• Check OAuth redirect URLs and your custom domain or DNS records point at the new deployment
• Watch error monitoring closely for the first 24 to 48 hours after cutover

Common migration errors and what they mean

• "new row violates row-level security policy" — a policy wasn't recreated on that table, or was recreated with different conditions than the original
• "JWT expired" or "invalid signature" right after cutover — expected once, since the project's JWT secret changed and old tokens are void until users log in again
• Foreign key errors during the data load — the schema wasn't loaded before the data, or tables loaded out of dependency order
• An Edge Function returning 401 when called from the frontend — it's still using the old project's service role or anon key as a secret
• Stripe webhook signature failures — the webhook endpoint in Stripe still points at the old URL, or the signing secret wasn't updated for the new endpoint

Where teams usually get stuck

The steps above look linear, but in practice schema and RLS migration is where most manual migrations lose the most time — Lovable Cloud's generated policies aren't always documented anywhere outside the database itself, and a missed policy either locks users out or opens a table that should have stayed restricted. Edge Functions with hardcoded secrets are the second most common source of silent failures, since they pass in testing and then fail in production once the old keys stop working.

If you'd rather not run this yourself, our team handles the full process end to end — schema, data, authentication, storage, Edge Functions, secrets and production deployment. See our Lovable to Supabase migration service for pricing, or get help migrating your Lovable app and we'll review your project first.