--- title: "Getting your code out of Lovable: the full guide | Lovable Field Guide" description: "A Lovable migration is really three migrations: frontend, backend, hosting. What each export path moves, which one-way doors break sync, and the safe order." lang: en json-ld: | { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://prerenderlovable.com/#website", "url": "https://prerenderlovable.com", "name": "The Lovable Field Guide", "description": "A working journal on Lovable SEO: getting apps built with Lovable indexed, ranked and cited, plus the migration and integration work that comes with it.", "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "inLanguage": "en" }, { "@type": "Organization", "@id": "https://prerenderlovable.com/#organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, { "@type": "BlogPosting", "@id": "https://prerenderlovable.com/blog/lovable-migration#article", "headline": "Getting your code out of Lovable: the full guide", "description": "A Lovable migration is really three migrations: frontend, backend, hosting. What each export path moves, which one-way doors break sync, and the safe order.", "datePublished": "2026-09-11T00:00:00.000Z", "dateModified": "2026-09-11T00:00:00.000Z", "inLanguage": "en", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://prerenderlovable.com/blog/lovable-migration" }, "author": { "@type": "Organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "keywords": "lovable migration, export lovable project, get code out of lovable, leave lovable, lovable vendor lock-in", "articleSection": "Migration" }, { "@type": "BreadcrumbList", "@id": "https://prerenderlovable.com/blog/lovable-migration#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://prerenderlovable.com/" }, { "@type": "ListItem", "position": 2, "name": "Migration", "item": "https://prerenderlovable.com/migration" }, { "@type": "ListItem", "position": 3, "name": "Getting your code out of Lovable: the full guide", "item": "https://prerenderlovable.com/blog/lovable-migration" } ] }, { "@type": "FAQPage", "@id": "https://prerenderlovable.com/blog/lovable-migration#faq", "mainEntity": [ { "@type": "Question", "name": "Does exporting my Lovable code give me the whole app?", "acceptedAnswer": { "@type": "Answer", "text": "No. A ZIP download or a Git sync gives you source code and database migration files. It does not include your database rows, storage objects, secret values, deployed edge functions, or auth users. Those live in the backend and have to be moved separately." } }, { "@type": "Question", "name": "Can I connect my Lovable project to a GitHub repository I already have?", "acceptedAnswer": { "@type": "Answer", "text": "No. Lovable's docs list importing an existing repository as unsupported: the sync is export-only, and connecting a project always creates a brand-new repository. This is true for GitHub, GitLab and Bitbucket Cloud alike." } }, { "@type": "Question", "name": "What happens if I transfer my Lovable-connected repo into a company GitHub org?", "acceptedAnswer": { "@type": "Answer", "text": "Sync breaks, and Lovable's docs say you have to contact support to re-attach the project. Renaming the repository itself is safe and Lovable follows the rename automatically, but transferring ownership, renaming your GitHub account or org, or deleting the repo all break the connection." } }, { "@type": "Question", "name": "Is there a one-click migration from Lovable Cloud to my own Supabase project?", "acceptedAnswer": { "@type": "Answer", "text": "No, and there is none in the other direction either. Lovable's Supabase integration page states plainly that there is no one-click migration from the built-in backend to Supabase or back. Moving means exporting data, standing up the destination yourself, and rebuilding the schema." } }, { "@type": "Question", "name": "Will exporting to GitHub and deploying on Vercel improve my SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Not by itself, and it can make things worse. Lovable's request-time pre-rendering runs on its own deployed public URLs, so it does not travel with your repository. On an older React + Vite project, self-hosting without adding SSR, static generation or a pre-render layer means crawlers get the empty SPA shell. On a TanStack Start project the shell is rendered, but dynamically loaded content that Lovable's generated code fetches from a React hook after hydration is still missing from the first response: verify with a curl of a page with dynamically loaded content, such as a product page, before and after you move." } }, { "@type": "Question", "name": "Can I download my code on the Lovable free plan?", "acceptedAnswer": { "@type": "Answer", "text": "No. Lovable's subscription-plans doc states the Free tier has no code editing, no custom domains and no code downloads. Git sync to github.com is documented as available across plans, which makes it the practical escape hatch when the ZIP is gated." } } ] } ] } --- [Skip to content](#main) [Lovable Field Guide ](/) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) [Start here](/blog/lovable-seo) [SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog) 1. [Home](/) 2. / [Migration](/migration) 3. / Getting your code out of Lovable: the full guide # Getting your code out of Lovable A Lovable migration is really three migrations: frontend, backend, hosting. What each export path moves, which one-way doors break sync, and the safe order. Published September 11, 2026 · 16 min read 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[#](#the-three-migrations-and-why-the-distinction-matters) Layer What it is How it leaves Reversible? **1\. Frontend code** React/TypeScript source, components, routes, migration files ZIP download, or Git sync to GitHub / GitLab / Bitbucket Cloud Yes: copying code is non-destructive **2\. Backend** Database rows, auth users, storage objects, secrets, edge functions, scheduled jobs Manual export and rebuild. No automated path either direction **No**: removing Lovable Cloud is permanent **3\. Hosting** The published site, the domain, request-time pre-rendering, the runtime bill Deploy the exported code somewhere else Yes, but you lose platform behavior that doesn’t travel 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](https://encited.com/blog/lovable-export-to-github)) 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?[#](#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](https://encited.com/blog/lovable-seo-update) 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](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership) still calls them “standard Vite + React projects”, and the [`llms.txt`](https://docs.lovable.dev/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](https://docs.lovable.dev/features/upgrade-to-tanstack-start) describe the new default. Treat the latter set as current. An in-place upgrade is an option too If you’re on React + Vite and the reason you’re leaving is rendering rather than ownership, Lovable documents an in-place upgrade to TanStack Start, triggered from chat or project settings. It costs credits, preserves page protection, metadata, analytics scripts and styling, and is reversible from version history without affecting your published site. The documented risk is browser-only libraries that break under server rendering in ways the upgrade’s checks don’t catch. Cheaper than a migration if rendering was the whole problem. ## Layer 1: getting the frontend code out[#](#layer-1-getting-the-frontend-code-out) There are two supported routes, and they are not equivalent. ### Route A: the ZIP download[#](#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](https://encited.com/blog/how-to-download-your-lovable-project-code-without-github) from the code editor or from Project settings → Git. The catch is plan gating. Lovable’s [subscription-plans doc](https://docs.lovable.dev/introduction/subscription-plans) 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](/blog/download-lovable-code) 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[#](#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](https://docs.lovable.dev/integrations/github) 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](https://docs.lovable.dev/integrations/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](/blog/lovable-github-sync) 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[#](#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:** Action What happens Recovery **Rename the repository** Sync continues. Lovable detects the rename and updates the connection Nothing needed: this one is safe **Rename your GitHub username or organization** Connection breaks entirely Revert the name to restore sync **Delete the repository on GitHub** Connection breaks Restore the deleted repo on GitHub and syncing resumes **The actual one-way doors:** Action What happens Recovery **Transfer the repo to another owner or org** Sync **breaks** Contact Lovable support to re-attach: you cannot fix it yourself **Disconnect, then reconnect** Lovable creates a **new** repository with the current project state None. The original repo and its history are orphaned **Remove Lovable Cloud** Permanent, and it does not move your data for you None 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. Disconnect is not a reset button The instinct when sync misbehaves is to disconnect and reconnect. Lovable’s docs list “reconnecting to the same repository after disconnecting” as unsupported: you get a second, new repository containing the current state, while your original repo sits on GitHub with all the history and no connection to anything. Treat the disconnect control as destructive and exhaust every other diagnostic first. 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](/blog/move-lovable-project-to-another-repo) 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[#](#layer-2-the-backend-and-why-the-code-export-isnt-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-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](https://docs.lovable.dev/features/cloud) 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](/blog/lovable-cloud-vs-supabase) lays out the documented trade-offs on both sides. ### There is no migration path, in either direction[#](#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](https://docs.lovable.dev/integrations/supabase) 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 accounts of the same migration exist Lovable’s docs describe the Cloud → Supabase route as ending in a new project. Several third-party migration guides instead describe removing Cloud from the existing project and connecting your own Supabase to the same project afterwards, keeping the Lovable editor. As of September 2026 the contradiction is unresolved. Since removal is permanent, verify the path in your own editor, and with Lovable support, before you rely on either version. 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](/blog/lovable-cloud-to-supabase) 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[#](#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](https://docs.lovable.dev/features/hosting) 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](/blog/lovable-not-indexed-on-google) and [how Lovable’s pre-rendering works](/blog/lovable-prerendering) before you move. **Moving the editor doesn’t stop the meter.** Lovable’s [credits and usage doc](https://docs.lovable.dev/introduction/credits-and-usage) 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](/blog/save-lovable-credits) 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[#](#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](/blog/self-host-lovable-app) puts effort estimates against each tier. ## Pre-flight checklist[#](#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](/blog/run-exported-lovable-app-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[#](#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](/blog/lovable-with-claude-code-and-codex) 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[#](#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](/blog/lovable-github-sync) and stop there. If the backend is moving, read [the Cloud to Supabase runbook](/blog/lovable-cloud-to-supabase) 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. Found something wrong or out of date? Lovable changes fast and we'd rather fix a guide than let it rot. Disclosure: the team behind this guide also builds Encited, mentioned above. On this page - [The three migrations, and why the distinction matters](#the-three-migrations-and-why-the-distinction-matters) - [Before anything else: which stack are you on?](#before-anything-else-which-stack-are-you-on) - [Layer 1: getting the frontend code out](#layer-1-getting-the-frontend-code-out) - [Route A: the ZIP download](#route-a-the-zip-download) - [Route B: Git sync](#route-b-git-sync) - [The one-way doors](#the-one-way-doors) - [Layer 2: the backend, and why the code export isn’t the app](#layer-2-the-backend-and-why-the-code-export-isnt-the-app) - [Lovable Cloud is built on Supabase, but it is not your Supabase](#lovable-cloud-is-built-on-supabase-but-it-is-not-your-supabase) - [There is no migration path, in either direction](#there-is-no-migration-path-in-either-direction) - [Layer 3: getting the hosting out](#layer-3-getting-the-hosting-out) - [What you can and cannot self-host](#what-you-can-and-cannot-self-host) - [Pre-flight checklist](#pre-flight-checklist) - [The order that works](#the-order-that-works) - [What to do next](#what-to-do-next) [More on Migration](/migration) - [Getting your code out of Lovable: the full guide](/blog/lovable-migration) - [How to download your code from Lovable](/blog/download-lovable-code) - [Lovable Cloud vs your own Supabase: how to choose](/blog/lovable-cloud-vs-supabase) - [Lovable GitHub sync: how it really works](/blog/lovable-github-sync) - [Migrating from Lovable Cloud to your own Supabase](/blog/lovable-cloud-to-supabase) - [Moving a Lovable project to a different repo](/blog/move-lovable-project-to-another-repo) - [Running an exported Lovable app on your machine](/blog/run-exported-lovable-app-locally) - [Self-hosting a Lovable app, and what you lose](/blog/self-host-lovable-app) ## Frequently asked questions Does exporting my Lovable code give me the whole app? No. A ZIP download or a Git sync gives you source code and database migration files. It does not include your database rows, storage objects, secret values, deployed edge functions, or auth users. Those live in the backend and have to be moved separately. Can I connect my Lovable project to a GitHub repository I already have? No. Lovable's docs list importing an existing repository as unsupported: the sync is export-only, and connecting a project always creates a brand-new repository. This is true for GitHub, GitLab and Bitbucket Cloud alike. What happens if I transfer my Lovable-connected repo into a company GitHub org? Sync breaks, and Lovable's docs say you have to contact support to re-attach the project. Renaming the repository itself is safe and Lovable follows the rename automatically, but transferring ownership, renaming your GitHub account or org, or deleting the repo all break the connection. Is there a one-click migration from Lovable Cloud to my own Supabase project? No, and there is none in the other direction either. Lovable's Supabase integration page states plainly that there is no one-click migration from the built-in backend to Supabase or back. Moving means exporting data, standing up the destination yourself, and rebuilding the schema. Will exporting to GitHub and deploying on Vercel improve my SEO? Not by itself, and it can make things worse. Lovable's request-time pre-rendering runs on its own deployed public URLs, so it does not travel with your repository. On an older React + Vite project, self-hosting without adding SSR, static generation or a pre-render layer means crawlers get the empty SPA shell. On a TanStack Start project the shell is rendered, but dynamically loaded content that Lovable's generated code fetches from a React hook after hydration is still missing from the first response: verify with a curl of a page with dynamically loaded content, such as a product page, before and after you move. Can I download my code on the Lovable free plan? No. Lovable's subscription-plans doc states the Free tier has no code editing, no custom domains and no code downloads. Git sync to github.com is documented as available across plans, which makes it the practical escape hatch when the ZIP is gated. Read next ## Keep going - ### [How to download your code from Lovable](/blog/download-lovable-code) Two routes to download Lovable code (a ZIP from the code editor and Git sync) the plan gate on both, and the backend pieces neither one exports. - ### [Lovable GitHub sync: how it really works](/blog/lovable-github-sync) Lovable GitHub sync is two-way but only one branch at a time, and it can never import an existing repo. Every rule, limit and failure mode. - ### [Migrating from Lovable Cloud to your own Supabase](/blog/lovable-cloud-to-supabase) There is no one-click Lovable Cloud to Supabase migration. The honest manual runbook: export, schema, RLS, edge functions, storage, secrets, auth and rollback. - ### [Self-hosting a Lovable app, and what you lose](/blog/self-host-lovable-app) How to self host Lovable app code on Vercel, Cloudflare Pages or Netlify: build settings, SPA rewrites, and the crawler pre-rendering you leave behind. The Lovable Field Guide A working journal on Lovable SEO. SEO - [SEO hub](/seo) Migration - [Migration hub](/migration) Integrations - [Integrations hub](/integrations) © 2026 The Lovable Field Guide. Independent guides to shipping Lovable apps. [RSS](/rss.xml) [Sitemap](/sitemap.xml) [About](/about)