Several of the top guides on exporting a Lovable project to GitHub are out of date. They point to a GitHub button Lovable removed in May 2026, say you need a paid plan (sync works on every plan), and warn you never to rename the repository, a rule Lovable dropped this year. Follow them and you lose an afternoon looking for a button that isn't there.
The bigger problem is the one none of them cover. Exporting is easy. Owning the code is not the same thing, and the hard part comes when an app was built by a freelancer or an agency and the repository sits in their account. I sorted 136 public reports of Lovable and GitHub going wrong, and nine were exactly that: a handover stuck because the developer held the repository or the project.
This is the setup I'd use: how to export, what you actually get, the rules that keep the sync working, and the order for moving an app out of a developer's accounts and into yours without breaking anything.
What goes wrong between Lovable and GitHub
The reports come from Reddit, YouTube, Hacker News, Trustpilot and GitHub, from 2025 to October 2026. I put each one in a group by the cause the thread confirmed.
Most problems are about the sync and the account the repository lives in, not the code itself.
One caution on the chart: the reports about renaming or moving the repository all date from before Lovable changed its rules in 2026. Today renaming is safe, and moving is safe if you do it in the right order, which is most of what this post is about.
How to export a Lovable project to GitHub, step by step
- Open Project settings, Git, GitHub. The GitHub button in the editor's top bar moved there on May 18, 2026. You can also reach it from the + button next to the chat, then Project, GitHub.
- Add a connection. A GitHub popup asks you to pick your personal account or an organization, then All repositories or Only select repositories, then Install & Authorize. If nothing happens, your browser blocked the popup.
- Connect the project. Lovable creates a brand-new private repository under the account you picked and starts two-way sync straight away.
- Check it. The project settings should show Connected, a sync status card, a branch picker and links to clone or view the repository on GitHub.
Two permission traps come up often. Only a Lovable workspace owner or admin can add the GitHub connection. And in a GitHub organization, only an organization owner can install Lovable's app, because it asks for administration rights to create repositories; anyone else can only send a request. Lovable's GitHub docs cover both.
Sync works on every plan, with GitHub, GitLab or Bitbucket. Downloading the whole codebase as a zip is for paid plans, and Lovable recommends sync over zip snapshots anyway. One thing you can't do is connect a repository you already have: Lovable always creates a new one, so if you have existing code, let it create the repository and copy your code in.
What is in the repository, and what is not
This is where "I exported it, so I own it" usually goes wrong. According to Lovable's sync overview:
| In the repository | Not in the repository |
|---|---|
| Your app code | Your database records |
| Edge functions and database migration files | Uploaded files, and since May 2026 large images, which live on Lovable's CDN |
| A .env file pointing at the live backend | Secrets, and the credentials behind connectors and Lovable AI |
Two of those surprise people. The .env file means a copy of the code on your laptop reads and writes the same live database as your published app; a Git branch doesn't give you a separate database. And because large images now sit on Lovable's CDN, a downloaded copy has small pointer files where the images were, so they fail to load outside Lovable. If you plan to host it elsewhere, I covered what breaks in Lovable app not working, and how the backend works in Lovable Supabase integration.
Rules that keep the two-way sync working
Every edit in Lovable is committed and pushed to the repository, and commits pushed to the synced branch show up in Lovable. Pushing never changes your live site, though; only Publish in Lovable does. The rest is a handful of rules:
- Don't rewrite history. No force-pushing, rebasing or squashing commits that are already on the synced branch; undo with a revert commit. Since October 5, 2026, if something does replace Lovable's commits, Lovable keeps a backup that only the project owner can restore.
- Protected branches reject Lovable. If GitHub refuses a push, Lovable pushes to a branch called lovable-sync and asks you to merge it. If your team requires pull requests on main, point Lovable at its own branch instead.
- Code you push isn't deployed. Lovable doesn't deploy a changed edge function or run a new migration that arrives through Git; ask Lovable in chat to do it.
- Big files fail. GitHub rejects files over 100 MB, and Lovable itself can't save files over 10 MB.
- Renaming is fine now. Renaming the repository, your username or the organization keeps the sync running. Older guides say otherwise because that was the rule until mid-2026.
If commits you pushed don't appear in Lovable, GitHub probably never told Lovable about the push. Lovable's official fix is to push any new commit, even an empty one. What I wouldn't do is disconnect and reconnect: reconnecting always creates a new repository, and in the reports it often made things worse.
Is the code really yours? Check whose account it is in
Lovable's FAQ says you own the projects and code you create. Its terms put that as between Lovable and the account holder, which is the account that built the project. If a freelancer or an agency built it in their account, who owns it between the two of you comes down to your contract. That's a question for a lawyer, not for me. What I can tell you is how to see where things stand.
The first part of a GitHub address is the owner: in github.com/someone/your-app, someone owns it. In the repository's Settings, Collaborators and teams lists everyone with access. Two details from GitHub's docs matter here. A personal account's repository has exactly one owner, and every collaborator gets write access, never admin. And if the repository sits in an organization, every owner of that organization can always see it. So if it lives in your agency's organization, being given access isn't the same as owning it, however friendly everyone is.
The apps I build live in GitHub repositories, and on any codebase the first thing I check is whose account it's in. If you're setting up your own, use a GitHub organization rather than a personal account: it can have several owners, and GitHub recommends at least two.
How to move it from your developer's account into yours
The order matters, because two of Lovable's rules interact. Transferring a repository keeps the sync only if the Lovable workspace already has a GitHub connection for the new owner. And moving a Lovable project to another workspace breaks its GitHub link, so reconnecting there creates a new repository with fresh history. This is the order I'd use:
Set up your side first, transfer the repository second, and close old access only after the live site checks out.
Transferring the repository
On GitHub the developer opens the repository's Settings, Danger Zone, Transfer, and types your username or organization. A transfer to a personal account sends you an email that expires if you don't accept within one day. Issues, pull requests, history, webhooks, secrets and deploy keys move with it, and old links and git addresses redirect, according to GitHub's transfer docs. Afterwards the original owner is added as a collaborator, so remove them when you're ready. If a transfer isn't possible, the developer can give you read access and you can mirror the repository into your account with its full history.
Taking over the Lovable project
If the developer built your app in a workspace of its own, this is the easy case: since September 7, 2026, the workspace's main owner role, which covers billing and domains, can be handed to any Lovable account by email, on every plan. Nothing moves, so nothing breaks. If your project sits in the developer's shared workspace, move it to yours with Move workspace. Its GitHub link breaks, so reconnect it in your workspace and keep the repository you were transferred as the history. A Cloud backend travels with the project, and your workspace pays for it from then on.
Avoid remixing as a handover. A remix is a separate copy that leaves behind the GitHub sync, secrets, database data, custom domain and collaborators.
Everything that isn't code
The domain, your own Supabase project if you use one, Stripe, and the email service each need to be in your name too. Then publish, check the live site page by page, and only after that remove the developer from the repository and the workspace. Exporting the code doesn't cancel anything either: Lovable says the subscription and any Cloud usage carry on until you change them.
When the sync breaks
- "Install the GitHub App for to enable gitsync". Usually after a workspace transfer or a removed connection. Reconnect and install the app on the owner shown.
- Every project on a connection disconnected at once. Someone uninstalled the Lovable GitHub app. Reinstalling works, but each project reconnects to a new repository.
- Lovable lost access to one repository. Someone switched the app to Only select repositories and left yours out. Reconnect and add it back.
- The repository was deleted. Restore it on GitHub, which is possible for 90 days, and the sync resumes. Otherwise reconnect to get a new repository.
- You need a different GitHub account on the project. You can't switch it in place; disconnect and reconnect to the other account, which creates a new repository.
Own the accounts, not just a copy
A zip file or a repository in someone else's account is a copy of your app. Ownership is the repository, the Lovable project, the backend and the domain all sitting in accounts you control, with at least two people able to get in. Export early, check whose name is on each one, and move them in order. More guides like this are in Fix an AI-built app.
And if you'd rather hand it over, I take these on as client projects: send me what you have and where each piece lives.
Common questions
How do I export my Lovable project to GitHub?
Open Project settings, Git, GitHub, then Add connection. Pick your personal account or organization in the GitHub popup and click Install & Authorize. Lovable creates a new private repository there and starts two-way sync. The old GitHub button in the editor top bar was removed in May 2026.
Is Lovable's GitHub sync free?
Yes. Two-way sync with GitHub, GitLab and Bitbucket works on every Lovable plan, including Free. Downloading the whole codebase as a zip file needs a paid plan, and the Free plan code editor is read-only.
Can I connect an existing GitHub repository to Lovable?
No. Connecting always makes Lovable create a brand-new repository, and reconnecting later creates another one. The workaround is to let Lovable create its repository, then copy your existing code into it.
Can I rename or move the repository after connecting?
Renaming the repository, your GitHub username or the organization now keeps the sync running. Transferring it to another owner keeps the sync only if your Lovable workspace also has a GitHub connection for that new owner; otherwise Lovable disconnects the project. Many older guides still say never rename it, which was the rule until mid-2026.
Does the GitHub export include my database?
No. The repository holds your code, edge functions and database migration files, plus a .env file pointing at the live backend. It does not hold your data, uploaded files, secrets or the credentials behind Lovable AI, and since May 2026 large images live on Lovable's CDN instead of in the repository.
How do I get my Lovable project from my developer?
Get your own GitHub account and Lovable access first, add a GitHub connection for your account in the workspace that holds the project, then have the developer transfer the repository to you and hand over the project. Move the domain, backend and payment accounts too, and remove the developer's access last.
Why did my Lovable GitHub sync stop?
Usually GitHub never told Lovable about a push; the official fix is to push any new commit, even an empty one. Other causes are a protected branch, a removed or suspended GitHub app, or a repository moved to an owner the workspace is not connected to. Avoid disconnecting and reconnecting, which creates a new repository.
This post first appeared on tusharbhendarkar.com. I fix apps built with Lovable, Replit, Bolt and Base44, and I build free checkers for live apps. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.
Top comments (0)