How do you move your app off Lovable?

The short answer

You can leave Lovable in three separable moves, and the code part is nearly free. Connect GitHub sync and your full codebase (a standard Vite and React app) lives in a repository you own; clone it and it builds anywhere with npm run build. The frontend redeploys on Vercel or Netlify in an afternoon. The sticky part is the backend. If your app uses Lovable Cloud (database, logins, file storage), your data lives on Lovable’s managed, Supabase-based service, and moving it is a real migration: since July 2026 an official export gives you the database as an SQL dump, but storage files download separately, secrets are left out, and user passwords do not export in a usable form. If you connected your own Supabase instead, there is nothing to migrate, because the backend was yours all along. Match the effort to your situation before you start.

Leaving Lovable is three separate moves

In Reddit threads and a small industry of migration blog posts, Lovable Cloud earned a reputation as the database you could check into but never out of. Your data checked in, and nobody could say how you check out. The fear was understandable and, as of mid-2026, it is mostly out of date. Untangling it starts with seeing that “my app” is three things that move separately: the code, the frontend hosting, and the backend with your data in it.

Lovable’s own position, in its documentation: “You own your code,” “You own your data,” and “We want you to stay with Lovable by choice, never by necessity.” Ownership of AI-generated code has its own wrinkles (covered in who owns AI-generated code), but Lovable’s terms are on your side here. Permission is settled. Effort is the real question, and it depends almost entirely on where your backend lives.

Your code already has an exit: GitHub sync

Connect GitHub from inside Lovable and the platform creates a repository under your GitHub account, then keeps it in sync both ways: edits you make in Lovable push to GitHub, and commits you push to GitHub flow back into Lovable. Sync covers one branch at a time (your repo’s default branch unless you change it), and the docs warn that transferring the repository to another owner can break the connection, while deleting it always does; a plain rename is fine, Lovable detects it and keeps syncing. You can keep prompting in Lovable for as long as you like after connecting. Sync is insurance; leaving stays optional.

Once the repo exists, the exit for your code is ordinary git: run git clone and a complete copy of the project sits on your machine. What you get is a standard Vite and React app, the same kind of project a human team might set up by hand. No proprietary format, no Lovable runtime the code depends on. That is why the code part of leaving barely qualifies as a migration.

Two caveats worth knowing. Lovable can export to GitHub but cannot import an existing repository, so the connection has to start from Lovable’s side. And if you disconnect and later reconnect, Lovable creates a fresh repository rather than reattaching to the old one.

The hard part is Lovable Cloud, and its export has gaps

Lovable Cloud is the built-in backend: the database, user accounts, file storage, and server-side functions Lovable spins up when your app needs them. Under the hood it runs on “Supabase’s open-source foundation,” per Lovable’s docs, but Lovable manages the instance and you work with it through the Cloud tab, not through a Supabase dashboard of your own. That management layer is exactly what made people nervous.

That reputation dates from the era when there was no official door. On July 3, 2026, Lovable shipped one: Cloud tab, then Overview, then Advanced settings, where an Export data button gives you your database as an SQL dump. Lovable emails you when the export is ready and saves the file to your project’s Cloud storage. The limits: 5 GB per export, one export every 24 hours. Older Reddit threads insisting there is no way out are describing the old reality.

Read the exclusions before you celebrate, because the docs are explicit about them:

• Files in storage buckets are not in the dump. Download them separately from the Cloud tab’s Storage section.
• Secrets (the API keys your backend functions use) are not exported. You will recreate those by hand wherever you land.
• “User passwords are not exported in a usable form.” Your users’ accounts can move, but they will reset their passwords on the other side.
• Edge function code is not in the export either. Check your synced GitHub repo for a supabase/functions folder; the docs do not state whether function code always syncs there, so verify you have a copy before deleting anything.

The same Advanced settings screen holds two more buttons. Pause stops the backend (database, auth, storage, functions) while your data stays in place; you can resume any time, though storage keeps counting toward usage while paused. Remove Lovable Cloud permanently deletes the Cloud-managed database, storage, authentication, and functions, and cannot be undone. Export your database and download your storage files before you ever touch Remove.

The cleaner path is bringing your own Supabase

The calmer version of this story is the one where the backend was never Lovable’s to begin with. A new Lovable project can use your own Supabase project as its backend from the start: on the dashboard, press the + button, open Databases, and pick a Supabase project. From then on your database, auth users, storage, and edge functions live in your Supabase account, visible in the regular Supabase dashboard, and schema changes are saved as migration files under supabase/migrations/ in your code. How the two products fit together has its own entry: Lovable and Supabase.

If you are on Cloud today, the docs are blunt about the path over: “There is no automatic migration in either direction.” The move is manual. Export the SQL dump, download your storage files, remove Cloud, connect your own Supabase project, then restore the data there. Supabase’s own docs cover the receiving end with the CLI (supabase db dump, restores through psql) and include a script for moving storage objects between projects. Community-built migration tools also script this handoff; treat them like any third-party script pointed at your production data and read what they do before running them. One gap to flag honestly: Lovable’s docs describe connecting Supabase to projects that “don’t have a backend yet,” which is the state your project reaches after removing Cloud, but Lovable publishes no step-by-step for the full swap. Keep your export files safe and test against a throwaway Supabase project first.

Redeploying the frontend is the small move

Whatever you decide about the backend, moving the frontend is genuinely small. A Lovable app deploys anywhere static hosting exists, because the build is plain files: npm run build, output in dist/, Node 22. Import the GitHub repository into Vercel or Netlify, confirm those build settings (most platforms auto-detect them, per Lovable’s own deployment guide), and after that every push deploys on its own.

Two details trip people up:

1. Client-side routing. Lovable apps handle routes in the browser, so your host must serve /index.html for every route. Skip the fallback rewrite and refreshing any page except the homepage returns a 404. On Vercel that is a rewrite rule in vercel.json; on Netlify, a _redirects file.
2. Environment variables. Vite bakes any variable prefixed with VITE_ into the built files at build time, not runtime. If your app talks to Cloud or Supabase, set VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY in the new host’s settings before the first build, plus any other VITE_ values sitting next to them. They live in the .env file of your synced repo, and they are the publishable, client-side kind, which is why they are allowed in the repo at all.

Your custom domain moves the way domains always move. You own it at your registrar regardless of what Lovable was serving, so add it in Vercel’s or Netlify’s domain settings and update the DNS records to point there, then allow a short propagation wait.

Moving the frontend does not break the backend. Lovable’s docs confirm the backend keeps working when the frontend is hosted elsewhere, so serving from Vercel while your data stays on Cloud or Supabase is a legitimate middle state. You can even keep prompting in Lovable, since the repository keeps syncing either way.

What each situation costs, honestly

Your situation	What has to move	Realistic effort
Frontend-only app (no accounts, no database)	Code and domain	An afternoon: connect GitHub, import to Vercel or Netlify, add the SPA rewrite, point DNS
App built on your own Supabase from the start	Frontend and env vars	An afternoon: the backend is already yours and does not move at all
App on Lovable Cloud (accounts, data, files)	Everything: SQL dump, storage files, secrets, functions, restore into your own Supabase	A focused weekend, plus password resets for your users and real testing before you press Remove

The third row is the price of the convenience you enjoyed earlier. Cloud gave you a backend without setup, and the bill arrives as a migration weekend. Keep the Cloud instance alive, or paused, until the new backend serves real traffic. Remove is the last step, never the first.

When staying is the right call

Lovable’s docs recommend moving pieces “only when you hit a real constraint, not a hypothetical one,” and call self-hosting an edge case rather than the default path. Self-interested advice can still be correct. If you are mid-build and reshaping your app daily through prompts, a migration buys you a week of not shipping. GitHub sync alone gives you most of the safety people are looking for: a full, current copy of your code, in your account, from day one, with no leaving involved.

Real constraints do exist. A compliance requirement to control your own database. Costs that stopped matching usage, though pausing Cloud may fix that for less. Backend access Lovable’s interface does not give you. A developer joining who needs a normal local workflow. Any of those justifies the weekend. A scary subreddit thread does not, and connecting GitHub today costs you nothing either way.

What Glim would tell you

Lock-in feeds on fog. People who feel trapped in a tool are rarely trapped by contracts; they just cannot say where their code, their data, and their domain actually live. Now you can, which turns staying with Lovable into a choice instead of a default. Glim, the firefly Glimfly is building, sits beside you while you build and explains each moving piece as it appears, so the day a thread about lock-in crosses your feed, you already know which parts are yours and which button you would press first. If that sounds like a saner way to ship, the waitlist is open.