How to update a Lovable project: GitHub sync and a one-time export

Updated 2026-11-03

Lovable keeps the project in its own editor and, when you connect GitHub, creates a new repository and syncs one branch in both directions. You update the app by editing in Lovable, or by pushing commits to that synced branch. A zip download is a copy of the code, not a live sync.

You do not need GitHub to change a Lovable project. Edits in the chat are the update, and they stay inside Lovable until you connect a host. Connect a host when you want a copy you own, a pull request, a local editor, or a deploy that is not Lovable’s. The behavior below is from Lovable’s GitHub guide and the Git sync overview. GitLab and Bitbucket use the same two-way model. This page uses GitHub because that is the remote the upkeep report can read.

Decide between a live sync and a one-time download

Git sync is on every plan. It keeps working after you connect it: Lovable commits its edits to your repository, and commits you push to the synced branch show up in the project. Use it if you will update the app more than once.

Download codebase is a zip of the project code, on paid plans. Open Project settings, Git, Download codebase, or open the code editor and use Download codebase at the bottom of the file tree. On an Enterprise workspace, an admin can limit that download to admins and owners. The zip is a snapshot. It does not keep syncing. Use it for a one-time copy without a GitHub connection.

Neither one is your database. Rows, storage files, and secret values are not in the repository. A clone of a project on the built-in backend does include .env values such as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY. Lovable’s guide says a local app that keeps those values reads and writes the same backend as the published app. A git branch is not a separate database. Use test records, or you will edit production data from your laptop. Schema changes, if you use your own Supabase project, belong in the flow in running Supabase migrations safely.

Connect GitHub, which creates a new repository

There are two layers. A workspace connection authorizes Lovable for a GitHub account or organization. A project link attaches one Lovable project to one repository. When you connect the project, Lovable creates a new repository. It is private until you change the visibility on GitHub. Lovable cannot import a repository that already exists, and reconnecting a project that you disconnected creates another new repository. You cannot re-link the old one.

Open Project settings, Git, GitHub, and connect. A Bolt.new project uses a different GitHub sync, covered in updating a Bolt project. If the project already syncs to GitLab or Bitbucket, the GitHub card stays hidden until you disconnect that provider. One project, one repository, one provider.

The separate GitHub API connector lets your app call GitHub’s API. Use Git sync to export code.

Change code on the synced branch

Lovable edits and syncs one branch at a time. By default that is the repository’s default branch, which is usually main. The branch picker in the project’s GitHub settings shows the name. Clone the new repository and look at that branch.

git clone git@github.com:you/the-new-repo.git
cd the-new-repo
git status
ls package-lock.json pnpm-lock.yaml yarn.lock

Install with the tool that owns the lockfile: npm ci for package-lock.json, pnpm install --frozen-lockfile for pnpm-lock.yaml, yarn install --frozen-lockfile on Yarn 1, or yarn install --immutable on Yarn 2 and later. Read the README for the dev script. Then change files, commit, and push to the synced branch.

git checkout main
git pull
git add -p
git commit -m "Update the contact form copy"
git push

Use the branch name from the picker if it is not main. Commits on any other branch do not appear in Lovable. Drafts inside Lovable are the mirror image: a draft is not a branch in the repository until you accept it.

The sync card in Project settings, Git, is the status that matters. Re-check compares the two copies and does not sync anything. Lovable compares the 50 most recent commits, so a count can read 50+.

An empty commit is enough when the card says GitHub is ahead:

git commit --allow-empty -m "Sync with Lovable"
git push

Do this only when your latest Lovable edits are already on GitHub. If the card says the two sides have diverged, a push from GitHub replaces Lovable’s copy of the branch. Lovable saves a backup first, and the project owner can restore it from the notice in the editor or in Project settings, Git. Read that notice before you decide the push “won”.

Bring a feature branch back into Lovable

Keep local work on a feature branch so unreviewed commits stay out of the project. Lovable’s overview says to avoid force-push, rebase, and squash on commits that are already on the synced branch. Lovable has its own copy of that branch. Rewriting history makes the next sync save a backup and then replace Lovable’s copy with yours. To undo a commit, add a new commit that reverts it.

When the feature is ready, merge it into the synced branch with a merge commit and push. Lovable then pulls the result. If main is protected, Lovable cannot push there either. It pushes its own edits to a branch named lovable-sync and tells you to merge that branch. Review it and merge with a merge commit, not a squash or rebase. If you had added your own commits on lovable-sync, Lovable leaves them and pushes to lovable-sync- plus a suffix instead. If someone deletes the synced branch, Lovable switches the project to lovable-fallback so editing can continue. Pick the branch you actually want, or recreate the old one.

You can also switch the synced branch from the picker: open it, choose the branch, and Lovable starts editing that branch immediately. Create a branch from the same picker if you want the new branch to start from the branch Lovable is on. Switch to main first when the new branch should start there. You cannot switch while Lovable is mid-edit.

GitHub rejects files over 100 MB, and the GitHub settings card lists them after a few failed syncs. Delete those files from the project and let sync retry. Separately, Lovable cannot save a file over 10 MB into the project. A file you pushed that is larger can sync in, and Lovable then fails any edit that touches it. For large media, Lovable’s docs say to ask it to move those files to CDN assets.

Update dependencies without losing the lockfile

A dependency change you push is still an update Lovable will see. The overview says synced commits that change dependencies go through the same checks as an edit in Lovable, including Lovable’s dependency audit and the project’s Security view. That view is not a substitute for reading the diff. Commit the lockfile in the same commit as package.json. A package.json bump without the lockfile installs a different tree on the next machine.

Do not run npm audit fix --force inside a generated app to “update everything”. It will move packages outside the ranges the app was built with. The path that stays small is in npm audit fix is not working. A Next.js major is the checklist in upgrading Next.js 15 to 16, done on a feature branch, then merged.

After the merge, wait until the sync card says both sides match, open the changed files in Lovable’s editor, and try the preview. Then tell Lovable what you changed so the next edit has context. Syncing a commit does not update the published app: publish again when the preview is ready. For the built-in backend, syncing migration or Edge Function files also does not apply or deploy them; follow the backend steps in the linked Git sync guide.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.

Commands and product behavior on this page were checked against the vendor documentation linked here on 3 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Read next

Run Supabase migrations safely in a Lovable project · npm audit fix is not working: why, and what to do instead