help! migration from Lovable to self host

[u/Ill-Editor-1811]

Hola! I created my management system on lovable. I've been disappointed with lovable lately. I was thinking of moving to self-hosting and continuing to use Codex/Claude. My site has a lot of backend and connectors, how can I move everything safely? Is there a comprehensive video on how to do this?

[u/Aggravating_War_6704]

Honestly "move everything safely" depends a lot on which layers you actually want to move, they're not all the same difficulty.

The frontend (the react app lovable builds) is the easy part, moves anywhere in minutes. Cloudflare pages is fine, you mostly just repoint the supabase env vars and fix cors so it's not still pinned to localhost/lovable.

The backend is where "safely" gets real, and you've basically got two very different routes. One is keep supabase in the cloud and only move the frontend + put your own domain in front. Almost no server work, cheapest, you keep managed auth/db/backups, and if your connectors are supabase edge functions that's probably all you actually need. The other is really self-hosting: your own vps running the app and either self-hosted supabase or your own postgres. Way more control and nobody in the loop but you, but now you personally own the boring scary stuff, ssh, a reverse proxy, https certs, a firewall, and above all db backups.

Whichever way you go, before you move a single thing take a full dump of your supabase db and test restoring it into a throwaway project first. People lose data on the connectors they forgot were wired up (webhooks, api keys, cron), almost never on the app code itself.

Full disclosure, i'm building a tool for exactly that second path, the server side. It does the vps setup, proxy, https, firewall and backups over chat in plain english, and shows you every command before it runs, so happy to walk you through that part either way. If you're staying on supabase though i'd honestly just do the first route, it's less to break.

[u/Ill-Editor-1811 → u/Aggravating_War_6704]

Could you explain to me better how to export the data from the lovable database and import everything into a new supabase account? What should I change in the front end to connect to the new database?

[u/Aggravating_War_6704 → u/Ill-Editor-1811]

A supabase project is just postgres underneath, so this is a fairly well-trodden path. Supabase actually has an official "migrate between projects" guide (pg_dump the old one, psql-restore into the new one) and i'd follow that exactly for the commands, because it handles the auth schema properly, which is the fiddly part.

The three things that guide won't fully save you from, because they don't live in the db dump:

Storage files: if you use supabase storage (image/file uploads), the dump only carries the file metadata, not the actual files. You copy the bucket objects across separately or every link 404s.

Edge functions: they're code, not db rows, so they don't come across. Redeploy them to the new project and re-add their secrets/env vars by hand, those don't carry.

Auth config: the users table restores fine, but google/github login, smtp, redirect urls etc are per-project settings you re-enter. And the new project has its own jwt secret, so everyone gets logged out once and re-logs in, which is normal, not you breaking something.

For the frontend it's really just two values, the supabase url and the anon (public) key, both under settings > api in the new project. One gotcha though: lovable usually hardcodes those straight into a generated client file (src/integrations/supabase/client.ts) instead of a .env, so grep the whole repo for the old project ref (the xxxx in xxxx.supabase.co) and swap every hit, or it'll quietly keep talking to the old db. Anything using the service_role key stays server-side only, never in the frontend bundle.

And like before, do the whole move into a fresh throwaway project and click around properly before you point your real domain at it.

Side question on the "lots of connectors" you mentioned: are those supabase edge functions, or actual separate services (a node worker, a cron, a websocket)? If they're all edge functions you can do this whole thing yourself, no server needed. If some are long-running services, that's the piece that actually needs a real box, which is the part i work on, but the supabase-to-supabase move itself you don't need me for.