To move a Lovable app to your own GitHub and hosting, connect GitHub sync, import the repository into Vercel or Netlify with npm run build and Node 22, copy the VITE_SUPABASE environment variables, add your domain to Supabase's sign-in URLs, then point your domain at the new host. Moving the backend off Lovable Cloud is a separate, manual step.
There are really two moves. The first, code and hosting, takes an afternoon and is easy to undo. The second, moving the database from Lovable Cloud to a Supabase project in your own account, is a real migration that needs planning. Lovable's docs say the apps, code, and content you create are yours, and that it is built so you are never locked in. This guide follows Lovable's own steps, adds what its docs leave scattered across several pages, and notes where Lovable's and Supabase's docs disagree. If you're moving because the app keeps breaking, read fix or rebuild a Lovable app first: new hosting won't fix the code.
Which kind of Lovable app do you have?
Two things change every step below, so check them first.
TanStack Start or React and Vite
Lovable's docs say new apps created from 13 May 2026 use TanStack Start, which runs server code, while older apps use React and Vite and build to static files. To check, open package.jsonin Lovable's code view or on GitHub. If it lists @tanstack/react-start, you have a TanStack Start app. If not, it's React and Vite. Many guides online were written before May 2026 and assume Vite, which is why their routing advice breaks newer apps.
Lovable Cloud or your own Supabase
If you connected your own Supabase project, the database is already yours, and you only move code and hosting. If the app uses Lovable Cloud, the built-in backend, Supabase's docs say those projects are owned and managed by Lovable, not your Supabase account. You can move the hosting and keep using Cloud, or move both.
Step 1: export your Lovable app to GitHub
In Lovable, open the GitHub integration and connect your account. Lovable's docs say GitHub sync is available on all plans, that connecting creates a new repository, and that the repository is private by default. From then on, sync runs both ways on one branch, usually main.
- Renaming is fine.Lovable's docs say sync continues when you rename the repository. Some older guides say otherwise.
- Don't delete it. Deleting the repository stops the sync.
- Transferring needs a connection. Moving the repository to another account or organization keeps sync running only if your Lovable workspace has a GitHub connection for the new owner.
- Data isn't included. The repository holds the code and the database migration files that define its structure, not the records in the database or the files users uploaded.
Downloading the code as a single file is also possible, but Lovable's docs list it under paid plans, and it's a one-off snapshot rather than something that stays up to date.
Step 2: deploy a Lovable app to Vercel or Netlify
Import the GitHub repository into your host. The settings depend on the kind of app from the first section:
| Setting | TanStack Start (since May 2026) | React and Vite (older) |
|---|---|---|
| Build command | npm run build | npm run build |
| Node version | 22 | 22 |
| Output directory | None on Vercel; dist on Netlify | dist |
| Page routing | Handled by the server; add no rewrite | Needs a rewrite to index.html |
| Own server | NITRO_PRESET=node-server npm run build, then node .output/server/index.mjs | Any static file host |
Vercel and TanStack Start
Vercel's Lovable guide says Lovable projects deploy with zero configuration: sync to GitHub, then import the repository at vercel.com/new. It adds that this needs @lovable.dev/vite-tanstack-configversion 2.6.2 or higher in the project, so update it if the build isn't detected.
Older Vite apps: fix the 404 on refresh
An older Lovable app is a single page app: every route is drawn in the browser from index.html. Without a rewrite, opening any address other than the home page directly, or refreshing it, gives a 404. Vercel's Vite docs give this vercel.json, placed at the root of the repository:
{
"rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}On Netlify, the same rule is a file named _redirects in the public folder, which Vite copies into the build:
/* /index.html 200Don't add either to a TanStack Start app. Lovable's guide says its server handles routing, and a catch-all rewrite gets in the way.
Step 3: set environment variables on the new host
Lovable's docs list the variables the app needs. Copy their values from the .envfile in the repository into your host's environment settings:
- Both kinds of app:
VITE_SUPABASE_URL,VITE_SUPABASE_PUBLISHABLE_KEY, andVITE_SUPABASE_PROJECT_ID - TanStack Start server code:
SUPABASE_URL,SUPABASE_PUBLISHABLE_KEY, andSUPABASE_PROJECT_ID, plus any secrets your server functions read, which aren't in the repository
Two rules. Variables starting with VITE_are built into the browser code when the app is built, so after changing one you must redeploy, and they must never hold a secret: Lovable's docs describe the Supabase URL and publishable key as safe to be public, and nothing else is. Payment, AI, and Supabase secret keys belong in the host's secret settings or in Supabase, without the prefix. And don't remove .envfrom the repository: Lovable's docs say it needs the file committed, or its preview breaks.
Step 4: update Supabase sign-in URLs
This is the step most often missed, and it's why sign-up emails send people back to the old address. In Supabase, open Authentication, then URL Configuration. Supabase's docs say the Site URL is where users are sent by default after email confirmations and password resets, and that any other address the app sends users to must be in the Redirect URLs list.
- Set the Site URL to your new production address
- Add the production address with its exact path to Redirect URLs
- For preview deployments, add the wildcard Supabase's docs give for your host, such as
https://*-your-team.vercel.app/**on Vercel - If you use Google or another sign-in provider, add the new domain to that provider's allowed redirects too
On Lovable Cloud, Lovable updates these settings itself only for its own published address and for domains you connect in Lovable. A domain you point at Vercel or Netlify is neither, so add it yourself. If logins hang or loop after the move, the causes are in Lovable app hangs after login.
Step 5: move your domain off Lovable hosting
Before you move the domain, test the new deployment on its temporary address the way a customer would: sign up with a new email and click the confirmation link, log in, reset a password, open a page deep in the app directly, upload a file, and make a test payment. Each of those exercises a different setting from the steps above, and each is cheaper to fix now than after customers arrive.
When it all works, point your domain at the new host, following its instructions. Lovable's docs describe what happens on the Lovable side:
- Your
lovable.appaddress keeps serving the version you last published there. Unpublish it when you no longer want it live. - Lovable's Publish button keeps publishing to Lovable hosting only.
- Moving the code or the domain doesn't cancel your Lovable subscription or Cloud usage.
- Custom domains on Lovable hosting need a paid plan. A domain already connected keeps working after a downgrade, but you can't connect a new one.
Can you keep editing in Lovable after moving?
Yes, if Git sync stays connected. Lovable's docs say that while another host serves the live app, Lovable keeps editing and previewing it, and each change Lovable pushes to the repository can trigger a deployment on the new host. That's often the best of both: you keep prompting for copy and layout, and the live app runs on accounts you control.
If a developer also works on the code, agree a branch rule, because Lovable syncs one branch at a time and diverged histories need merging by hand. The details are in how to hire a developer to fix a Lovable app.
Moving from Lovable Cloud to your own Supabase
This is the bigger move. Lovable's docs say there's no one-click migration from Cloud to your own Supabase project. Here is what the official export gives you, and what it doesn't.
| Included | Not included: move separately |
|---|---|
| The full database, structure and data | Files in storage |
| Users' accounts and password hashes | Edge Function code |
| All tables in one archive file | Secrets, API keys, and sign-in provider settings |
Lovable's docs set limits: databases up to 15 GB, an export file up to 5 GB, one export every 24 hours, and only while the backend is running. The export is under More, then Cloud, then Overview, then Advanced settings. It's a PostgreSQL .backup archive with zstd compression, not a SQL file you can paste into an editor, so you restore it with pg_restore, which needs zstd support. Look inside before restoring anything:
pg_restore --list your-export.backupThe order Lovable recommends
- Create the new Supabase project
- Move the structure, from the migration files in the repository
- Move the data from the export
- Set up sign-in again, including providers like Google
- Copy the storage files
- Set the secrets and deploy the Edge Functions
- Point a test deployment at the new backend
- Check everything works there
- Switch: pause writes, take a final export, restore it, go live
With the Supabase CLI, steps 2 and 6 look like this, run from the repository:
npx supabase login
npx supabase link --project-ref your-new-project-id
npx supabase db push
npx supabase functions deployWhat's easy to miss
- Rehearse the restore.Restoring data into tables that already exist, with triggers on them, takes care. Do a full run on a throwaway Supabase project first, and don't add
--cleanwithout reading what it does: Lovable's docs warn that it drops the objects being restored. - Re-point payment webhooks.A Stripe webhook that called a Cloud function must point at the new project's function, with that endpoint's own signing secret set again. How to check it works is in Stripe webhook not working in a Lovable app.
- Replace Lovable's AI and connectors. Lovable's docs say AI model calls and app connectors run through Lovable while you use Cloud, so set up your own provider accounts before switching.
- Download before you delete.Lovable's docs say removing Cloud deletes the backend permanently, including exports saved in its storage.
Where the docs disagree
Lovable's Cloud FAQ describes moving by connecting your Supabase project to a new Lovable project, and Supabase's troubleshooting page says a Cloud project can't be disconnected or switched to an external Supabase project. Lovable's newer hosting guide describes switching the same project by editing its settings files. The safe order works either way: point a separate test deployment at the new backend first, and only switch the live app once that's been checked.
When to get help moving a Lovable app
Moving code and hosting is usually fine to do yourself with the steps above. Get help with the backend move if the app has paying users, stored files, Stripe webhooks, or more than a few tables, or if you can't pause writes for the switch. The cost of a mistake there is lost data or locked-out users, not a 404.
A deploy on hosting you control, with environment variables, migrations, monitoring, and backups set up properly, is part of my Production Sprint, after a Launch-Ready Review that checks hosting, backups, and who controls each account. The Chat Company started as an AI-generated demo; I kept about 20%, rewrote the rest, and it now serves 30+ businesses. To plan your move, send me the link and tell me whether it's on Lovable Cloud.
Sources
- Deployment, hosting, and ownership, Lovable Docs
- Deploy and host outside Lovable, Lovable Docs
- GitHub integration: private repositories and two-way sync, Lovable Docs
- Advanced settings: export Lovable Cloud data, Lovable Docs
- Secrets and .env variables, Lovable Docs
- Custom domains: paid plans, Lovable Docs
- Lovable Cloud: no one-click migration to your own Supabase, Lovable Docs
- Can't access a Supabase project created by Lovable Cloud, Supabase Docs
- Deploy a Lovable app on Vercel, Vercel Docs
- Vite on Vercel: rewrites for single page apps, Vercel Docs
- Rewrites and proxies: single page app rule, Netlify Docs
- Redirect URLs and the Site URL, Supabase Docs