Lovable export code: download, sync and verify a backup

How do I download my Lovable code?

In the project, open the Code editor and look for Download codebase below the file panel, or use Project settings → Git → Download codebase. The full ZIP requires a paid plan and edit access; an Enterprise policy can further restrict it to owners and admins. Downloading a single open file uses its own Download control and is available on any plan to users with the required project access.

After saving a ZIP, give the saved copy a recognisable project-and-date name. Extract it into a new folder and check that it opens. Keep your original download while you inspect it; an empty folder or a download error is not a successful backup.

When is Git sync the better choice?

Choose Git sync when work will continue outside Lovable or a developer needs a maintained repository. Lovable supports GitHub, GitLab and Bitbucket. Check the active branch: Lovable edits and syncs one branch at a time, so a change on a different branch is not evidence that the project is out of sync. Repository access and Lovable project access are separate.

Write down the exact commit ID you intend to preserve, not just “main” or “latest”. A branch can advance while a handover is being discussed. Ask the receiving developer to confirm that same commit before comparing screenshots or reporting a missing change.

Avoid a disconnect-and-reconnect surprise

The GitHub sync setup creates a new repository; it does not attach a project to an arbitrary existing repository. Disconnecting and later reconnecting also creates a new repository. Do not disconnect a working link merely to obtain a ZIP. If starting a new Lovable project from existing code, follow the documented ZIP import path and assess that as a separate project.

Before changing anything, compare the project name, Git provider, repository owner and active branch. A similarly named repository can be a different copy. Keep a note of where the working version is before asking someone else to investigate.

A snapshot is different from repository history

GitHub’s Code → Download ZIP creates a source snapshot. It does not include the repository’s entire commit history. A clone is the appropriate starting point when history is required. Record a commit ID for a repeatable file snapshot: branch and tag names can later point elsewhere.

Keep two questions separate in your handover: “Can I inspect these files?” and “Can I trace how they changed?” A ZIP can answer the first without answering the second. Neither answer alone establishes that an app is running correctly.

What does the code copy leave out?

Lovable’s export documentation distinguishes source and migration files from database records and storage files: the latter need separate handling. Hosting requirements also depend on the app. Current TanStack Start projects have server output and static assets; older React + Vite projects use a different deployment shape. Inspect package.json and the documented project scripts before assuming every export can go on a static host.

For each dependency, record its purpose, owner and the evidence that it can be recovered. A list of environment-variable names is useful; a public document containing their secret values is not. This is a planning record, not an instruction to move services or change a working production site.

• Code: exact project, repository or ZIP, branch and commit if available.
• Data: database and uploaded files, with their separate backup owner and date.
• Runtime: required build/start scripts and external service names.
• Access: who can retrieve the backup and carry out a restore.
• Evidence: what was actually checked, what failed, and what remains untested.

Worked example: a directory with a contact form

Consider a fictional directory app with public listings, a contact form and image uploads. Its ZIP opens and contains the page code, package.json and migration files. That is a successful file inspection. It does not establish that the current listings, submitted enquiries or uploaded images are in the ZIP.

A useful handover note could read: “Code snapshot: directory-2026-10-22.zip. File inspection: complete. Database backup: not yet checked. Image backup: not yet checked. Clean local run: pending. Contact-form delivery: pending.” These are illustrative labels, not results from a real Lovable customer test.

The next step follows the missing evidence: identify who maintains the data backups before promising recovery. If the only immediate goal is a developer reviewing the interface, the file snapshot may be enough for that limited purpose.

Use a short acceptance check before relying on the copy

Have the person receiving the copy confirm the project and version, open the extracted folder, locate the README and dependency lockfile, and identify the documented installation and run commands. Run a clean local check only in a suitable development environment. Record the actual result and unresolved requirements.

If deployment is later required, validate the affected user journey in a test environment before switching traffic. A green build alone cannot prove that login, a saved record, a file upload or an email reached its destination. Keep the previous working service available until the responsible owner has reviewed the evidence.