--- title: "Moving a Lovable project to a different repo | Lovable Field Guide" description: "Transferring the repo breaks Lovable sync. Move Lovable project to another repo or GitHub org safely: what breaks, what you lose, and when support has to re-attach it." 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/move-lovable-project-to-another-repo#article", "headline": "Moving a Lovable project to a different repo", "description": "Transferring the repo breaks Lovable sync. Move Lovable project to another repo or GitHub org safely: what breaks, what you lose, and when support has to re-attach it.", "datePublished": "2026-09-11T00:00:00.000Z", "dateModified": "2026-09-13T00:00:00.000Z", "inLanguage": "en", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://prerenderlovable.com/blog/move-lovable-project-to-another-repo" }, "author": { "@type": "Organization", "name": "The Lovable Field Guide", "url": "https://prerenderlovable.com" }, "publisher": { "@id": "https://prerenderlovable.com/#organization" }, "keywords": "move lovable project to another repo, transfer lovable repo to organization, lovable sync broken after transfer, lovable created a second repo, change lovable github repo", "articleSection": "Migration" }, { "@type": "BreadcrumbList", "@id": "https://prerenderlovable.com/blog/move-lovable-project-to-another-repo#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": "Moving a Lovable project to a different repo", "item": "https://prerenderlovable.com/blog/move-lovable-project-to-another-repo" } ] }, { "@type": "FAQPage", "@id": "https://prerenderlovable.com/blog/move-lovable-project-to-another-repo#faq", "mainEntity": [ { "@type": "Question", "name": "Does transferring a GitHub repo break Lovable sync?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Lovable's GitHub integration docs state that transferring the repository to another owner or organization breaks the sync, and that you must contact Lovable support to re-attach it. Renaming the repository itself is safe: Lovable detects the rename and updates the connection automatically." } }, { "@type": "Question", "name": "Can I disconnect and reconnect Lovable to the same GitHub repo?", "acceptedAnswer": { "@type": "Answer", "text": "No. Reconnecting to the same repository after disconnecting is on Lovable's unsupported list. Lovable creates a new repository containing the current state of the project, which leaves your original repo and its commit history orphaned on GitHub." } }, { "@type": "Question", "name": "Can I connect a Lovable project to a repo that already exists?", "acceptedAnswer": { "@type": "Answer", "text": "No. Git sync is export-only. Lovable's docs say you cannot import an existing repository, and that connecting a project always creates a new repository. This applies to GitHub, GitLab and Bitbucket Cloud alike." } }, { "@type": "Question", "name": "Can a Lovable project live inside a monorepo?", "acceptedAnswer": { "@type": "Answer", "text": "Not directly. Each Lovable project syncs to exactly one repository that Lovable creates itself, so it cannot be a subdirectory of a repo you own. The workable pattern is to mirror the Lovable repo into your monorepo with git subtree and treat the Lovable-synced branch as the boundary." } }, { "@type": "Question", "name": "What happens to my GitHub repo if I disconnect Lovable?", "acceptedAnswer": { "@type": "Answer", "text": "Sync stops, but nothing is deleted. The repository stays on GitHub with its full history, and the project and its code stay in Lovable. The catch is that you cannot re-link that same repo afterwards." } } ] } ] } --- [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. / Moving a Lovable project to a different repo # Moving a Lovable project to a different repo Transferring the repo breaks Lovable sync. Move Lovable project to another repo or GitHub org safely: what breaks, what you lose, and when support has to re-attach it. Published September 11, 2026 · Updated September 13, 2026 · 11 min read Short version: do not press GitHub’s **Transfer** button. Transferring a Lovable-connected repository to another owner or organization breaks the sync, and Lovable’s own docs say you have to contact support to re-attach it. Disconnecting and reconnecting is not the workaround, because Lovable creates a _brand-new_ repository from the current project state rather than re-linking the one you already have. So “moving the repo” is really a choice between keeping your Git history and keeping your sync, and the rest of this post is about picking the least-bad trade for your situation. This is the sharpest edge in the whole [Lovable migration story](/blog/lovable-migration), and Lovable documents it. It catches people because moving a personal repo into a company org is a completely normal thing to do on every other platform. ## What the docs actually say about each operation[#](#what-the-docs-actually-say-about-each-operation) Lovable’s GitHub integration page enumerates four distinct outcomes. They are not intuitive, and the difference between the safe one and the destructive one is one menu item apart in GitHub’s settings. What you do on GitHub What happens to Lovable sync Recovery Rename the repository Keeps working. Lovable detects the rename and updates the connection automatically Nothing to do Transfer to another owner or organization **Breaks.** Lovable can no longer update the project Contact Lovable support to re-attach Delete the repository Breaks Restore the deleted repo on GitHub and syncing resumes Rename your GitHub username or organization Breaks entirely Revert the name and sync is restored Two more constraints shape every playbook below: - **[Git sync](https://encited.com/blog/lovable-export-to-github) is export-only.** You cannot point a Lovable project at a repo that already exists. Connecting always creates a new repository, on GitHub, GitLab or Bitbucket Cloud. - **Reconnecting is not re-linking.** “Reconnecting to the same repository after disconnecting” is explicitly unsupported; Lovable creates a new repo on reconnect. One migration write-up reports the new repo arriving with a `-1` suffix when the original name is taken, which matches what the docs describe even if the exact naming is not something Lovable documents. The disconnect button is destructive Disconnecting does not delete anything: your repo stays on GitHub with full history, and your project stays in Lovable. But it is a one-way door: you can never bind that project back to that repository. Treat **Disconnect** as “abandon this repo”. There’s no way to pause sync and resume it on the same repo. ## Decision tree[#](#decision-tree) ``` Do the commit history, issues and PRs need to move with the repo? │ ├─ No ──────► Disconnect in Lovable, rename the old repo out of the way, │ reconnect into the target org. Lovable creates the new repo. │ No support ticket. → Playbook 1A │ └─ Yes ─────► Is the destination an org you control, and can you tolerate sync being down for days? │ ├─ Yes ──► GitHub Transfer, then a support ticket. → Playbook 1B │ └─ No ───► What are you actually doing? ├─ Handing the project to a client → Playbook 2 ├─ Folding it into a monorepo → Playbook 3 └─ Leaving Lovable's editor behind → Playbook 4 ``` ## Playbook 1: personal repo into a company org[#](#playbook-1-personal-repo-into-a-company-org) This is the common case. You prototyped on your own GitHub account, the project is real now, and it needs to live under `acme-corp`. ### 1A: Let Lovable create the repo in the org (no support ticket)[#](#1a-let-lovable-create-the-repo-in-the-org-no-support-ticket) You are deliberately giving up the old repo. In exchange, you keep a working two-way sync and you never wait on a ticket. 1. **Install the Lovable GitHub app on the destination org first.** In Lovable, add the account, pick the org in the GitHub popup, choose _All repositories_ or _Only select repositories_, then _Install & Authorize_. Lovable registers it as a reusable workspace connection. Note the app cannot be installed more than once on the same account or organization, so if the org already has an install, reuse it rather than trying to add a second. 2. **Push everything you care about in Lovable before you touch anything.** Confirm the latest commit in the old repo matches what the editor shows. 3. **Rename the old repo** to something like `my-app-legacy` on GitHub. Renaming is safe while connected, and it frees the name so the new repo can take it. 4. **Disconnect** the project from GitHub in Lovable. 5. **Connect** again, this time choosing the org connection. Lovable creates a fresh repository there containing the current project state. 6. **Give the history back**, as a separate branch on the new repo, so nothing is actually lost: ``` # Run against a clone of the OLD repo. git clone git@github.com:you/my-app-legacy.git old-app cd old-app git remote add newrepo git@github.com:acme-corp/my-app.git # Push the old history to a clearly-labeled branch. It shares no commits # with the new repo's initial commit, which is fine: it is an archive branch, # not something you merge. git push newrepo main:archive/pre-transfer-history ``` **You keep:** current code, working two-way sync, the repo name, the old history as an archive branch (and in the old repo itself, which you should archive rather than delete). **You lose:** linear history on the default branch, open PRs, issues, stars, watchers, release tags on the synced branch, and any GitHub Actions state tied to the old repo. Branch protection rules and required checks have to be recreated. **Support ticket:** not needed. ### 1B: Use GitHub’s Transfer, then file a ticket[#](#1b-use-githubs-transfer-then-file-a-ticket) Choose this when the history and issue tracker genuinely matter more than uptime: a repo with a year of PR review context, or one that external references point at. 1. Push everything from Lovable and verify the repo is current. 2. Transfer the repo in GitHub’s repository settings. GitHub sets up redirects from the old path, so existing clones and links keep resolving. 3. Sync is now broken. Do **not** disconnect in Lovable to try to fix it: that is what creates the duplicate repo and makes the situation unrecoverable. 4. Contact Lovable support and ask them to re-attach the project to the transferred repository. Tell them the project, the old repo path and the new one. 5. While you wait, treat Lovable as the source of truth and stop pushing from your side, or you will have two divergent heads when sync comes back. **You keep:** full history, issues, PRs, tags, stars, redirects from the old URL. **You lose:** working sync for however long the ticket takes. As of September 2026, Lovable’s docs do not publish a turnaround time for this, so plan for it being days rather than minutes. **Support ticket:** required. This is the only documented path back. Warning If you have already transferred the repo _and_ already hit Disconnect, you now have an orphaned repo with the history and a new repo with the code. Do not try to merge them into one clean line. Keep the old one archived as the historical record, diff the two to confirm nothing was dropped, and move on. The unrelated-histories merge is technically possible and almost never worth the mess it leaves. ## Playbook 2: handing the project to a client[#](#playbook-2-handing-the-project-to-a-client) Agency handover is Playbook 1 plus seven other things people forget. The repo is rarely the hard part. The trap that gets named most often in handover guides: the project stays attached to the _original owner’s_ connection even after the project moves workspaces, and a repo created under your agency’s GitHub account does not travel with it. Your client ends up with an app they cannot deploy. Work through every ownership surface, starting with the code: 1. **Workspace**: who owns the Lovable workspace and who is billed for credits. 2. **Repository**: under the client’s org, created through their connection, per Playbook 1A. 3. **Deployment**: remember that pushing commits does not update the live site. Publishing is a separate snapshot action, and whoever publishes needs access. 4. **Database**: Lovable Cloud does not give the client a Supabase dashboard, so decide before handover whether they need their own Supabase. There is no one-click migration in either direction; see [moving from Lovable Cloud to Supabase](/blog/lovable-cloud-to-supabase). 5. **Domain and DNS**: moved into the client’s own registrar account. 6. **Analytics**: full property ownership transferred to the client. 7. **Payment accounts**: Stripe or Paddle live under the client’s legal entity from day one, because this one is genuinely painful to retrofit. 8. **Secrets**: API keys are write-only in Lovable’s secret store. You cannot read them back out to hand over, so the client must re-issue and re-enter every key. The real advice is contractual, not technical: **create the project in the client’s workspace and their GitHub org at kickoff.** Retrofitting ownership is precisely where sync breaks, and it costs a support ticket every time. ## Playbook 3: consolidating into a monorepo[#](#playbook-3-consolidating-into-a-monorepo) Be honest with yourself here: there is no good path, because the requirements are contradictory. A monorepo means your repo contains the app in a subdirectory. Lovable requires exactly one repository per project, created by Lovable, with the app at the root. You cannot have both. Two workable compromises: **Mirror it in, keep Lovable as the source.** The Lovable repo stays the canonical location for that app; your monorepo carries a copy under a prefix. ``` # In the monorepo, one time: git remote add lovable git@github.com:acme-corp/marketing-site.git git subtree add --prefix=apps/marketing lovable main --squash # Whenever Lovable has shipped changes: git subtree pull --prefix=apps/marketing lovable main --squash # To send monorepo-side edits back to the branch Lovable syncs: git subtree push --prefix=apps/marketing lovable main ``` That last command is the one to be careful with. Lovable edits and syncs **one branch at a time**, so you must push to exactly the branch Lovable has active, and you must not push while Lovable is mid-edit. Two writers on one branch is the standard Lovable-plus-IDE conflict problem, and it clusters in `package.json`, route files and generated components. If pushes start failing because of branch protection or conflicts, check for a branch named `lovable-sync`: that is where Lovable parks commits it could not land on the main branch. **Or stop syncing and vendor the code.** Copy the current state into `apps/marketing`, disconnect Lovable’s GitHub sync, and accept that the app is now maintained like any other package in the monorepo. You keep the Lovable editor for as long as you want to keep using it, but the monorepo becomes the source of truth and any Lovable edit is a manual copy job. For most teams reaching for a monorepo, this is the honest end state: Playbook 4 with extra steps. ## Playbook 4: the clean break[#](#playbook-4-the-clean-break) You want the code, you are done with sync. This is the simplest path and the one with the fewest surprises, provided you know what does not come with you. 1. Push from Lovable and confirm the repo is current, or [download the ZIP](https://encited.com/blog/how-to-download-your-lovable-project-code-without-github) from the code editor or Project settings → Git. Note the ZIP needs a paid plan: Free explicitly has no code downloads. Git sync to github.com is available on all plans, which makes it the free-tier escape hatch. Details in [getting your code out of Lovable](/blog/download-lovable-code). 2. Disconnect in Lovable, or simply stop editing there. The repo keeps its full history either way. 3. Move the repo wherever you like: transfer it, fold it into a monorepo, mirror it to GitLab. Nothing can break, because nothing is attached any more. What stays behind: your database contents, storage files, and every secret value. Migration files describing the schema are in the repo; the data is not. Edge functions and backend configuration need redeploying by hand against whatever backend you land on. If you are going all the way to your own infrastructure, [self-hosting an exported Lovable app](/blog/self-host-lovable-app) covers the backend side. One SEO consequence worth knowing before you leave Lovable hosting If your project is on the older React + Vite stack, Lovable serves pre-rendered HTML on deployed public URLs to _verified crawlers_: Google, Bing, social bots and AI engines. That behavior belongs to Lovable’s hosting, not to your code, so it does not travel with the repo. Deploy the same code to Vercel, Netlify or Cloudflare Pages and crawlers get the SPA shell instead. Projects created from 13 May 2026 onward are TanStack Start, where SSR is on by default, and it travels with the code, provided the new host runs the server build rather than serving the output as static files. Drop that same build into an S3 bucket or a static-only Pages project and you have shipped a client-rendered app again. That settles less than it sounds like it does either way, because SSR only includes data that a route loader fetched. React’s docs state that effects [“only run on the client”](https://react.dev/reference/react/useEffect) and don’t run during server rendering, and [TanStack Query’s SSR guide](https://tanstack.com/query/latest/docs/framework/react/guides/ssr) says queries that aren’t prefetched are fetched on the client after the app is interactive. So whether your dynamically loaded content (CMS posts, product pages, directory listings: anything that isn’t written into the page’s source code) lands in the HTML depends on where the fetch lives: a route `loader` or `createServerFn` puts it there, a `useEffect` or un-prefetched `useQuery` inside the component does not. Moving hosts doesn’t change that either way, but it’s worth knowing which of the two you have before you blame the move. See [Lovable pre-rendering](/blog/lovable-prerendering) for how to check which stack you are on. ### Check where your data actually gets fetched[#](#check-where-your-data-actually-gets-fetched) Pick a page whose content comes out of your database (a product, a listing, a blog post) never the homepage, which is usually static JSX either way. Then look for a phrase that isn’t in your source code. This test only works on the TanStack Start stack. On React + Vite curl returns the empty shell whatever user agent you send, and what verified crawlers receive can’t be verified from outside. ``` curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \ https://yourdomain.com/products > /tmp/page.html # The search phrase must be one contiguous text run: markup splits phrases across elements. grep -qiF 'Ceramic Pour-Over Kettle' /tmp/page.html \ && echo 'server-rendered' || echo 'client-fetched: crawlers never see it' ``` Run it against your current TanStack Start deployment. A hit means the fetch lives in a loader and will keep landing in the HTML wherever you deploy the server build. A miss means the fetch lives in a component, and no host will fix that for you. The fix is a code change. If you can’t move the fetch, the alternative is a pre-rendering layer on the new host, because Lovable’s own crawler pre-rendering stays behind when you leave. [Encited](https://encited.com) runs one at the edge on Vercel, Netlify, Cloudflare or your own server. Rewriting the route to fetch in a `loader` needs no third party at all. ## Side by side[#](#side-by-side) 1A: reconnect into org 1B: transfer + ticket 3: monorepo mirror 4: clean break Keeps commit history on the synced repo No Yes Yes Yes Keeps issues and PRs No Yes Yes Yes Keeps two-way Lovable sync Yes After support re-attaches Yes, via one branch No Support ticket needed No Yes No No Downtime on sync Minutes Unknown, plan for days None Permanent, by choice Ongoing maintenance cost None None Subtree pulls forever None ## A few things that are safe[#](#a-few-things-that-are-safe) Not everything about the repo is a landmine. Renaming the repository is fine and tracked automatically. Deleting it breaks the connection but restoring the repo on GitHub resumes syncing, so an accidental delete is recoverable if you act before GitHub’s restore window closes. Switching branches and cutting new ones from Lovable’s branch picker is supported, as long as Lovable is not actively editing at the time, and remember new branches are cut from the _currently active_ branch. Worth flagging to whoever reviews app installs at your company: the Lovable GitHub app requests Contents (write), Metadata (read), Pull requests (write), Workflows (write) and **Administration (write)**. Administration:write is what allows it to create repositories, which is the mechanism behind every behavior in this post. Commits land authored by `lovable-dev[bot]` and co-attributed to the workspace member who triggered the sync, so `git blame` will not point at a human. ## What to do next[#](#what-to-do-next) Open the project’s GitHub settings and check the repo owner right now. If it is a personal account and this app is going to outlive the prototype, run Playbook 1A this week while the history is still short enough that losing the default branch’s log costs nothing. That single move saves you the support ticket later. If you are handing something over, write the eight ownership surfaces from Playbook 2 into the statement of work before you write any code. And if sync is already broken, do not press Disconnect: file the ticket first. For the mechanics of sync itself, branch behavior and the failure modes that look like a transfer problem but are not, read [how Lovable’s GitHub sync actually works](/blog/lovable-github-sync). 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 - [What the docs actually say about each operation](#what-the-docs-actually-say-about-each-operation) - [Decision tree](#decision-tree) - [Playbook 1: personal repo into a company org](#playbook-1-personal-repo-into-a-company-org) - [1A: Let Lovable create the repo in the org (no support ticket)](#1a-let-lovable-create-the-repo-in-the-org-no-support-ticket) - [1B: Use GitHub’s Transfer, then file a ticket](#1b-use-githubs-transfer-then-file-a-ticket) - [Playbook 2: handing the project to a client](#playbook-2-handing-the-project-to-a-client) - [Playbook 3: consolidating into a monorepo](#playbook-3-consolidating-into-a-monorepo) - [Playbook 4: the clean break](#playbook-4-the-clean-break) - [Check where your data actually gets fetched](#check-where-your-data-actually-gets-fetched) - [Side by side](#side-by-side) - [A few things that are safe](#a-few-things-that-are-safe) - [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 transferring a GitHub repo break Lovable sync? Yes. Lovable's GitHub integration docs state that transferring the repository to another owner or organization breaks the sync, and that you must contact Lovable support to re-attach it. Renaming the repository itself is safe: Lovable detects the rename and updates the connection automatically. Can I disconnect and reconnect Lovable to the same GitHub repo? No. Reconnecting to the same repository after disconnecting is on Lovable's unsupported list. Lovable creates a new repository containing the current state of the project, which leaves your original repo and its commit history orphaned on GitHub. Can I connect a Lovable project to a repo that already exists? No. Git sync is export-only. Lovable's docs say you cannot import an existing repository, and that connecting a project always creates a new repository. This applies to GitHub, GitLab and Bitbucket Cloud alike. Can a Lovable project live inside a monorepo? Not directly. Each Lovable project syncs to exactly one repository that Lovable creates itself, so it cannot be a subdirectory of a repo you own. The workable pattern is to mirror the Lovable repo into your monorepo with git subtree and treat the Lovable-synced branch as the boundary. What happens to my GitHub repo if I disconnect Lovable? Sync stops, but nothing is deleted. The repository stays on GitHub with its full history, and the project and its code stay in Lovable. The catch is that you cannot re-link that same repo afterwards. Read next ## Keep going - ### [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. - ### [Getting your code out of Lovable: the full guide](/blog/lovable-migration) 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. - ### [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. - ### [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)