Getting your code out of Lovable

Most Lovable migrations go wrong for the same reason: people treat “get my code out” as one job when it is three. Your frontend code, your backend, and your hosting leave Lovable by three different routes, on three different timelines, through three different sets of one-way doors. Conflate them and you’ll end up with a repository full of code that doesn’t run against anything.

This is the map. It covers what each export route actually moves, what it silently leaves behind, and which actions you cannot undo. Read the one-way doors section before you click anything, because two of the most common “obvious” moves (transferring the repo to your company org, and disconnecting GitHub to fix a sync problem) are both destructive.

The three migrations, and why the distinction matters#

Layer 1 is easy and mostly safe. Layer 2 is where the real lock-in lives and where irreversible buttons are. Layer 3 is where people discover that the thing they moved for, usually cost or SEO, didn’t actually improve, because they only moved one layer.

A useful sanity check before you start: you can do layer 1 without doing 2 or 3. Syncing to GitHub (walkthrough) and working locally in Claude Code or Cursor while Lovable keeps hosting the app is a legitimate place to stop for good. Plenty of people should stop there.

Before anything else: which stack are you on?#

On 13 May 2026 Lovable changed the default stack for new projects from React + Vite (client-rendered, static files) to TanStack Start with server-side rendering on Cloudflare Workers. Existing projects were not force-migrated: Lovable’s own blog says every project already built continues to run as before.

This changes what your export contains and how it behaves once you host it yourself. Check package.json rather than guessing:

grep -E '"(@tanstack/react-start|@tanstack/react-router|react-router-dom)"' package.json

• @tanstack/react-start present → you have the SSR stack. Server logic lives in the app as TanStack server functions, and SSR travels with the code to any host that can run it, but it only includes data that a route loader fetched. Lovable’s generated pages typically query Cloud or Supabase from a hook after mount, so the product, listing and profile content is still fetched in the visitor’s browser and is still absent from the first response. The curl test in the hosting section below is how you check that, and it has to run against a page with dynamically loaded content (CMS posts, product pages, directory listings: anything that isn’t written into the page’s source code) rather than the homepage.
• Only react-router-dom → you’re on the older Vite SPA. Server logic sits in separately deployed edge functions, and you are relying on Lovable’s request-time pre-rendering for crawlers.

Lovable’s docs contradict themselves here, which is worth knowing before you cite one at a colleague. The deployment/hosting/ownership page still calls them “standard Vite + React projects”, and the llms.txt index still summarizes the platform as “Built on React + Vite with upgrade paths to TanStack Start”. The blog, the SEO docs and the TanStack upgrade page describe the new default. Treat the latter set as current.

Layer 1: getting the frontend code out#

There are two supported routes, and they are not equivalent.

Route A: the ZIP download#

A point-in-time snapshot. No ongoing relationship, no sync, no history. Lovable’s FAQ describes downloading the codebase as a ZIP from the code editor or from Project settings → Git.

The catch is plan gating. Lovable’s subscription-plans doc is explicit that Free has no code editing, no custom domains and no code downloads. Which paid tier enables it is reported inconsistently by third-party guides (some say Business specifically, while Lovable’s own materials say “paid plans” without naming a tier) and those same third-party guides report that Enterprise admins can disable downloads across an organization, which surprises employees who assumed the button would be there. The full ZIP walkthrough, including the plan question covers where the button actually lives.

Use the ZIP when you want an archive, a one-time handoff, or a copy to read offline. Don’t use it as the foundation of an ongoing migration: you’ll be re-downloading it every time Lovable changes something.

Route B: Git sync#

This is the real export path, and almost everything written about it online gets at least one detail wrong. The precise facts:

It is export-only. Lovable’s GitHub integration doc lists “importing existing GitHub repositories into Lovable” as unsupported: you can only export from Lovable to Git. There is no BYOR (bring-your-own-repository) flow on any provider.

Connecting always creates a new repository. Not sometimes. Always. The git-sync overview states it directly: connecting a project always creates a new repo, private by default. Each Lovable project maps to exactly one repository on exactly one provider.

The UI action is called Connect. There is no “Export to GitHub” button, and writing that phrase is an instant tell that an article was written by someone who never opened the product. The docs describe the feature as “export and two-way sync”, and the first-time flow is: Add account → a GitHub popup → choose the account or organization → choose All repositories or Only select repositories → Install & Authorize. Lovable then registers the installation as a reusable workspace connection, and you click Connect next to the connection where the new repo should be created.

It is genuinely two-way, on one branch. Changes in Lovable push to Git, and commits pushed to the active branch flow back into Lovable. But Lovable edits and syncs one branch at a time (the repo’s default branch unless you change it) and you cannot switch or create branches while Lovable is actively editing. New branches are cut from whichever branch is currently active, which is a quiet foot-gun if you expected the repository default.

Three providers. GitHub (github.com on all plans), GitLab (including self-managed), and Bitbucket Cloud. GitHub Enterprise Cloud with data residency and self-hosted GitHub Enterprise Server are Enterprise-plan only, where you create your own copy of the Lovable app.

Two more details worth knowing before your security reviewer asks. The GitHub app requests Contents (write), Metadata (read), Pull requests (write), Workflows (write) and Administration (write): that last one is what lets it create repositories. And commits are authored by lovable-dev[bot], co-attributed to whichever workspace member triggered the sync, so your git blame will look unusual.

Hard limits: files over 100 MB fail (that’s GitHub’s own limit), files over 10 MB can’t be edited inside Lovable, and you cannot install the Lovable GitHub app more than once on the same account or organization.

The complete Git sync setup and troubleshooting guide goes deeper on failure modes, including the one everybody hits: when a push fails because of branch protection or a conflict, Lovable’s docs say it pushes to a branch named lovable-sync instead. That is the first place to look for code you think vanished.

The one-way doors#

These actions break sync in two different ways, and telling them apart matters. Most of what looks alarming is recoverable by putting the setting back the way it was. The rest are genuinely one-way, and they are the reason to read this section before you touch anything.

Looks bad, is recoverable:

The actual one-way doors:

The transfer row is the single most common way people break a working Lovable project, because moving a personal repo into a company org is an ordinary, sensible thing to do, and GitHub’s Transfer button gives you no warning that a third party depends on the ownership path. Lovable’s docs carry the warning, but you have to already be reading the GitHub integration page to see it.

If you need the repo to live under a different owner, do it deliberately rather than through GitHub’s transfer flow. The safe ordering for moving a Lovable project to another repo or org walks through it, including the trade-off you cannot avoid: you can keep the commit history or the live sync, and you have to pick one.

Layer 2: the backend, and why the code export isn’t the app#

Here is the part that catches experienced engineers, because the export looks complete. You have a repo. It has components, routes, config, and a supabase/migrations folder full of SQL. It compiles. It is not your app.

What Git sync and the ZIP both give you:

• All application source code
• Edge function source
• Database migration files: the SQL that defines your schema

What neither gives you:

• Database rows. Data is never in the repository. Migration files describe the shape of your tables. Your rows aren’t in them.
• Storage objects. Every uploaded file, image and document.
• Secret values. Lovable’s secret store is write-only: you see a name and a creation date, never the value. Nothing to copy even if you wanted to.
• Deployed edge functions. The source comes with you; the deployment, the environment it runs in, and its secrets do not.
• Auth users in a usable state. Third-party migration guides report that Lovable says passwords are not exported in a form that keeps sign-in working, and recommend putting every user through a password reset.
• Scheduled jobs, OAuth provider config, and webhook endpoints. All of which keep pointing at the old backend until you repoint them, and all of which fail silently when you don’t.

That last category is the dangerous one. A missing database is obvious within thirty seconds. A cron job still calling an edge function on a backend you’re about to delete is invisible until the backend disappears.

Lovable Cloud is built on Supabase, but it is not your Supabase#

Lovable Cloud is the built-in backend (database, auth, storage, realtime, edge functions) and Lovable’s Cloud doc says it is enabled by default for your workspace. The same doc says it is built on “Supabase’s open-source foundation”. That sentence has caused more confusion than any other in the product’s documentation, because it does not mean you have a Supabase account. There is no Supabase organization, no project, no dashboard login, no direct connection string. Everything happens inside the Lovable editor under the More tab → Cloud: database viewer, SQL editor, users and auth, storage buckets, secrets, jobs, edge functions, logs and usage.

The alternative is connecting your own Supabase, which is a two-level flow: a workspace owner or admin links a Supabase organization to the Lovable workspace, then anyone with edit access connects a specific Lovable project to a Supabase project inside it. Individual team members don’t each need a Supabase account. The full Cloud versus own-Supabase comparison lays out the documented trade-offs on both sides.

There is no migration path, in either direction#

This is the fact every Lovable Cloud migration turns on, so here it is without hedging. Lovable’s Supabase integration page states there is no one-click migration from the built-in backend to Supabase or the other way. The Cloud page adds that migration from Supabase to Cloud is not supported at all.

The documented Cloud → Supabase path in Lovable’s own docs is fully manual and has a sting in it: export your Cloud data, create a new Lovable project, connect a Supabase project to that new project, and rebuild the schema there. Not an in-place swap: a new project, which means you lose the original project’s continuity. Remixing a Cloud project doesn’t help either; you just get another Cloud project.

Two operational limits reported by third-party migration guides, which Lovable’s public docs don’t appear to publish: exports capped at 5 GB, and one export request per 24 hours. If those hold for your account, a failed export costs you a day, which turns the migration into a single-shot operation. Rehearse against a test restore first, and check your database size before you begin.

The sequencing that keeps you safe is the same regardless: removing Lovable Cloud is the last step, never the first. The end-to-end Cloud to Supabase runbook covers the ordering, the auth-users problem, the storage 404s that appear after a restore that reported success, and the verification gate to pass before you press the irreversible button.

Layer 3: getting the hosting out#

Three things surprise people here.

Pushing commits does not deploy anything. Lovable’s git-sync and hosting docs both say it: publishing is a separate action, and it creates a snapshot. Changes made after publishing don’t reach the live site until you republish, and the editor preview is not the published site. As of September 2026 the hosting doc describes no separate staging environment, though Drafts, shipped 9 September 2026, give you a separate copy of the project to test changes in before merging them into the main version. If you’ve come from a Git-driven deploy pipeline, this is backwards from your instincts.

Pre-rendering does not travel with the code. On older React + Vite projects, Lovable applies request-time pre-rendering on deployed public URLs, served only to verified crawlers: Google, Bing, social unfurlers and AI engines. That runs on Lovable’s hosting. Export the repo, deploy it on Vercel or Cloudflare Pages, and the clients that don’t run JavaScript get the SPA shell again: every major AI crawler except Applebot, plus every social unfurler. Googlebot will render it, but only after a pass through the render queue, and Bing’s own guidance still recommends dynamic rendering rather than relying on its JavaScript execution.

Lovable’s docs say external pre-rendering services are unnecessary for Lovable-hosted projects. That holds for your shell, your nav and static route content. It does not hold for anything your page fetches from Lovable Cloud or Supabase after hydration: that query runs in the visitor’s browser and never reaches the cached HTML, so it is not in what a crawler gets, on Lovable’s hosting or anywhere else. Check it against a page with dynamically loaded content, never the homepage:

curl -sS https://yourdomain.com/products | grep -c 'product-card'
# Compare against what you count in the browser. A gap is the whole problem.

Run that before you move and again after, on both stacks. If SEO is part of your reason for migrating, read what actually breaks when a Lovable site isn’t indexed and how Lovable’s pre-rendering works before you move.

Moving the editor doesn’t stop the meter. Lovable’s credits and usage doc describes a single credit pool covering three kinds of usage: Build (messages to the AI), Cloud (database, network, storage, compute and realtime in your deployed app), and AI Gateway (runtime model calls from your app). Move your development to Claude Code and you eliminate Build usage only. Cloud usage keeps accruing for as long as the backend and hosting stay put. This is why the “should I leave Lovable” question is really “how far should I go”: a partial migration can leave you paying two bills instead of one. If cost is the driver, the practical ways to cut credit burn may get you most of the benefit for none of the risk.

Worth crediting Lovable for what it does do here: hosting has no plan caps on visitors, requests or bandwidth, with automatic HTTPS and global edge delivery. “Unlimited traffic” is about plan limits, and Cloud usage still draws credits, but the frontend genuinely is a standard build you can deploy elsewhere.

What you can and cannot self-host#

Lovable’s ownership doc says the platform “is intentionally built so that you are never locked in”. That claim is fair about the frontend and misleading about everything else, so split it into three:

1. Hosting the built app: fully supported and straightforward. It’s a standard build output.
2. Hosting the backend: supported via your own Supabase, which is a real project with real effort. Moving to plain PostgreSQL is a different matter: the same doc concedes it would require reimplementing equivalent auth, storage and edge services and is not supported out of the box, because the app depends on Supabase-specific behavior.
3. Self-hosting the Lovable editor and agent: not possible. The doc states the platform itself is a managed service that cannot be self-hosted or deployed inside a customer VPC.

The realistic self-hosting guide puts effort estimates against each tier.

Pre-flight checklist#

Work through this before you change any setting. Most of it is reconnaissance, and none of it is destructive.

1. Identify the stack. Run the package.json grep above. Write down the answer; several later decisions depend on it.
2. Confirm your plan’s export rights. If the ZIP is gated, Git sync is the documented path available across plans.
3. Decide the repo’s final home now. Which account or organization should own it, permanently. Getting this right on the first Connect avoids the transfer and disconnect doors entirely.
4. Inventory your secrets. Grep the exported code for every environment variable your edge functions read. You cannot recover the values from Lovable, so plan to regenerate each one at its source provider (Stripe, Resend, OAuth clients, model APIs) and re-install at the destination.
5. Inventory your invisible infrastructure. Scheduled jobs, OAuth redirect URIs, inbound webhooks, and any hardcoded project URLs in the code. These fail silently and usually aren’t noticed for days.
6. Measure the database. Row counts per table, bucket sizes, and total export size, so you know whether you’re near any cap.
7. Create a canary user. Sign up a throwaway account with a password you write down. After the restore, attempt a real sign-in with it before you believe the auth migration worked.
8. Take a ZIP even if you’re using Git sync. It costs nothing and gives you a frozen reference copy independent of the sync connection.
9. Run the exported app locally and walk every major flow. Not a build: an actual click-through. Getting an exported Lovable app running locally covers the environment variables, which differ by stack.
10. Write down your rollback position for each step. For layer 1 it’s “keep using Lovable”. For layer 2, past the removal of Cloud, there isn’t one, which is the whole reason removal goes last.

The order that works#

1. Connect Git sync, to the right owner, the first time.
2. Clone locally, get it running, walk the app. Fix nothing yet.
3. Decide how far you’re going: code only, code plus backend, or everything including hosting.
4. If you’re keeping Lovable as an editor, establish branch discipline before two tools start writing to one branch. Lovable syncs one branch; keep your own work on feature branches and merge deliberately. The Lovable plus Claude Code and Codex workflow is the common shape of this.
5. If the backend is moving: stand up the destination, restore, redeploy edge functions, re-enter secrets, repoint cron and OAuth, then verify against the checklist.
6. Cut over hosting and DNS. Re-verify search properties, confirm sitemap.xml and robots.txt still resolve, and confirm unknown URLs return a real 404.
7. Only now, after everything is verified against the new backend, remove Lovable Cloud.

What to do next#

Run the package.json grep and the secrets inventory today, both are read-only, both take ten minutes, and both change what the rest of the plan looks like. Then pick your layer: if you only need the code, set up Git sync properly and stop there. If the backend is moving, read the Cloud to Supabase runbook end to end before you start.

And if you take one thing from this page: owning your source code is not the same as owning your app. The repository is the easy third.