Moving your project out of Lovable, Bolt or Replit

Sooner or later a project built in Lovable, Bolt or Replit outgrows its home. You want proper code review, your own server for background jobs, real access to logs, a second developer working in their own editor. Moving looks like “download the code and host it somewhere”, but the code is only the visible part. The rest is spread across dashboards, and you tend to find it when something stops working.

Start with an inventory

Before exporting anything, list everything the project actually consists of. Usually that’s:

• frontend code and server functions;
• the database, often a Supabase project or the platform’s built-in one;
• authentication: where users live and how they sign in;
• uploaded files;
• environment variables and third-party keys;
• the domain and DNS;
• everything outside that knows your app’s address: payment webhooks, OAuth redirect URLs, links in emails.

Also find out who owns the external accounts. Sometimes the Supabase project was created by the platform or a contractor, and the product owner has no admin access to it. Fix that before the move, not halfway through.

What to export

Code goes into your own repository. Lovable and Bolt can sync with GitHub; Replit can use git or give you an archive. Check right away that the project builds locally from scratch: npm ci, then the build. If it doesn’t, the platform was filling something in for you, and now is the time to find out what.

The database goes out as a full pg_dump: schema, data, functions, triggers and access policies. RLS policies are part of your security, not decoration. Lose them in transit and your data is open.

Files move separately from the database. The database usually stores only their paths, so after the move, check that every reference points at a file that exists.

Users are best left alone in the first phase. Moving auth to a different provider often means everyone has to set a new password, and that’s a project of its own, not a step in this one.

What usually breaks

• Environment variables. The platform injected them; the new host doesn’t have them. Check prefixes too: Vite only exposes variables starting with VITE_ to the browser.
• Hardcoded addresses: the platform’s preview domain, its CDN, absolute URLs in emails.
• Sign in with Google or GitHub. The new domain has to be added to the allowed redirect URLs, or the login button will just return an error.
• Webhooks. Your payment provider will keep sending events to the old address.
• Packages that only work inside the platform: its database, its auth, its storage.
• The Node version and build command the platform used to pick for you.

The order of steps

Don’t move everything in one evening. This is safer:

1. A repository and a local build that reproduces what runs today.
2. A deploy to the new host on a temporary domain, still talking to the old backend. Walk through the main flows by hand.
3. Moving the database and files, if needed, as a separate step with a short window and a dump you’ve rehearsed.
4. Lower the DNS TTL a day ahead, then switch the domain.
5. Update webhooks and OAuth redirect URLs within the same hour.
6. Keep the old version alive for a week so you have somewhere to roll back to.

Where the truth lives now

The most common source of confusion after a move is two-way sync. Someone keeps editing in Lovable, someone else in an editor, and changes overwrite each other. Agree that the repository is the source of truth. If the platform is still useful for quick prototypes, work there on a separate branch and merge through an ordinary pull request.

If you’d rather move without downtime and without a week of untangling, SUBXCAT can run the migration together with your team.