Migrating off Lovable Cloud without losing a day of uptime

Lovable is excellent at getting you to v1. The day you outgrow it, you discover three things in quick succession:

1. You don’t have your Supabase database password.
2. Your migrations history isn’t yours either — it lives in their managed instance.
3. The deploy pipeline, the staging environment, the secrets, and the cron jobs are all Lovable’s. You can read them. You can’t move them.
4. Your site is not AIO-friendly — the generated markup and URL structure were optimised for Lovable’s renderer, not for LLM crawlers.

I just shipped a 4-month port of RankRush off Lovable onto self-managed Supabase + a VPS + Cloudflare DNS. Apex cutover happened at 24-hour TTL with zero customer-visible downtime, and Lovable stayed warm as a fallback for the first 24 hours after switch.

This is the playbook. Four hardest pieces, what failed first, and the pattern that ended up working.

1. Schema drift: 103 migrations and only 47 of them reconcile

Lovable’s managed Supabase had ~103 migration files in the dashboard. The local repo had 47. The other 56 were applied directly through Lovable’s UI editor — no migration file ever generated.

What worked: dump the live schema with pg_dump --schema-only, diff it against supabase db reset’s output of the local migrations, and write a single squash migration that brings any fresh database from “empty” to “what production actually is.” Throw away the historical migrations. Forward-only from cutover.

What failed first: trying to back-port the missing 56 into the migrations folder. Two days lost. Don’t.

2. Edge function secrets handoff

20+ Deno Edge Functions were running on Lovable’s Supabase. Each had its own secrets. None of those secrets were in our .env files — they’d been set through the Lovable UI, never copied anywhere.

What worked: a one-page secrets inventory, function by function, with three columns — secret_name, where_it_lives_today, where_it_must_live_tomorrow. Filled in by walking the function source files. Then the migration was 30 minutes of supabase secrets set against the new project.

What failed first: assuming supabase functions list --project-ref <old> would tell us. It does not surface secrets. The audit had to come from the code.

3. OAuth redirects

Two providers, four redirect URIs each (web app, marketing site, dev, preview). Each provider has its own approval delay. Reddit took weeks. Google was instant. We did not learn this evenly.

What worked: register the new redirect URIs first, weeks before cutover. Keep both old and new authorized at the same time. Cut over the URI in the app after DNS — not before.

What failed first: cutting over redirects ahead of DNS to “be safe.” It just produced a long window where neither stack worked.

4. The DNS cutover

Apex on Cloudflare. The plan: drop TTL to 60s 24 hours before cutover, point apex at the VPS, leave Lovable warm for 24 hours as a rollback target, then quiet-pause Lovable.

This is the only step that worked exactly as planned. Boring is the goal here.

The shape that worked

A migration like this is mostly a sequencing problem, not a technical one. The order that survived contact with reality:

1. New stack stood up in parallel. Marketing site on Astro, app dashboard on the VPS, fresh Supabase project — all running before any DNS touched.
2. Schema squashed once. Forward-only from cutover.
3. Secrets audited from source, not from the old dashboard.
4. OAuth URIs registered ahead, swapped after DNS.
5. Apex flipped at low TTL with the old stack kept warm.
6. 24-hour fallback window with the old stack still answering, before quiet-pause.

If you’re a founder whose team built v1 on a managed platform and the lock-in is starting to feel expensive, the migration is a 4-week project for one engineer if you sequence it like this. It’s a 4-month project if you don’t.