Moving a Lovable project to a different repo

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, 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#

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.

Two more constraints shape every playbook below:

• Git sync 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.

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#

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)#

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#

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.

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.
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#

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#

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 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.
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 covers the backend side.

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 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#

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#

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.