©Code byMilanParmar

How to move a Lovable app to your own GitHub and hosting

Which kind of Lovable app you have, exporting to GitHub, build settings for Vercel and Netlify, environment variables, Supabase sign-in URLs, what happens to your lovable.app address, and moving off Lovable Cloud to your own Supabase.

9 min read

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:

Build settings for a Lovable app outside Lovable
SettingTanStack Start (since May 2026)React and Vite (older)
Build commandnpm run buildnpm run build
Node version2222
Output directoryNone on Vercel; dist on Netlifydist
Page routingHandled by the server; add no rewriteNeeds a rewrite to index.html
Own serverNITRO_PRESET=node-server npm run build, then node .output/server/index.mjsAny 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:

vercel.json (older React and Vite apps only)
{
  "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:

public/_redirects (older React and Vite apps only)
/*    /index.html   200

Don'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, and VITE_SUPABASE_PROJECT_ID
  • TanStack Start server code: SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, and SUPABASE_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.

  1. Set the Site URL to your new production address
  2. Add the production address with its exact path to Redirect URLs
  3. For preview deployments, add the wildcard Supabase's docs give for your host, such as https://*-your-team.vercel.app/** on Vercel
  4. 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.app address 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.

What Lovable Cloud's data export includes
IncludedNot included: move separately
The full database, structure and dataFiles in storage
Users' accounts and password hashesEdge Function code
All tables in one archive fileSecrets, 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:

Terminal: list what's in the export
pg_restore --list your-export.backup

The order Lovable recommends

  1. Create the new Supabase project
  2. Move the structure, from the migration files in the repository
  3. Move the data from the export
  4. Set up sign-in again, including providers like Google
  5. Copy the storage files
  6. Set the secrets and deploy the Edge Functions
  7. Point a test deployment at the new backend
  8. Check everything works there
  9. 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:

Terminal: push the structure and functions
npx supabase login
npx supabase link --project-ref your-new-project-id
npx supabase db push
npx supabase functions deploy

What'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

  1. Deployment, hosting, and ownership, Lovable Docs
  2. Deploy and host outside Lovable, Lovable Docs
  3. GitHub integration: private repositories and two-way sync, Lovable Docs
  4. Advanced settings: export Lovable Cloud data, Lovable Docs
  5. Secrets and .env variables, Lovable Docs
  6. Custom domains: paid plans, Lovable Docs
  7. Lovable Cloud: no one-click migration to your own Supabase, Lovable Docs
  8. Can't access a Supabase project created by Lovable Cloud, Supabase Docs
  9. Deploy a Lovable app on Vercel, Vercel Docs
  10. Vite on Vercel: rewrites for single page apps, Vercel Docs
  11. Rewrites and proxies: single page app rule, Netlify Docs
  12. Redirect URLs and the Site URL, Supabase Docs
Milan Parmar

The developer

Freelance full-stack developer in Bengaluru with 5+ years of experience. I redesign websites, take over broken apps, and build SaaS products, with 18 case studies to show for it.

FAQs

Is exporting my Lovable app to GitHub free?

Yes. Lovable's docs say GitHub sync is available on all plans, and the repository it creates is private by default. Downloading the code as a single file from Lovable needs a paid plan, but you rarely need that once the code is on GitHub. Neither way includes the records in your database or the files your users uploaded.

Will my users have to reset their passwords if I leave Lovable Cloud?

No, if you restore the official export. Lovable's docs say it includes your users' accounts and their password hashes, so users keep their passwords in the new Supabase project. Anyone signed in at the moment you switch has to sign in again, and sign-in providers such as Google have to be set up again in the new project.

Why does my Lovable app show a 404 when I refresh a page on Vercel?

Because it's an older React and Vite app, which is a single page app: every route is handled in the browser from index.html. The host needs a rewrite that sends every path to index.html, a vercel.json on Vercel or a _redirects file on Netlify. Apps created since May 2026 run on TanStack Start, handle routing on the server, and don't need it.

Does moving hosting cancel my Lovable subscription?

No. Lovable's docs say a code export or a domain change doesn't cancel anything: your subscription and any Cloud usage continue until you change them. If you keep editing in Lovable, you still need a plan. If you leave completely, cancel it yourself after the move, and download any exports first.