Export Lovable code: GitHub sync, zip download and running it outside Lovable

Symptom

You want your Lovable code somewhere you control, for a developer, an investor's due diligence, or another host. Then:

• There's no option to pick your existing repository.
• The .zip builds locally, but the app shows a blank page or can't reach the database.
• It deploys, but refreshing any page other than the home page gives a 404.
• A teammate pushes to GitHub and work in Lovable seems to vanish.
• The Git settings refuse to sync, with this message:

Why it happens

Git sync creates, it doesn't import. Connecting always makes a new repository, private by default. You can't attach an existing repository. Reconnecting a project on GitHub, GitLab.com or Bitbucket Cloud links it back to the same repository; on GitHub Enterprise Server or self-managed GitLab it makes a new one. GitHub and Bitbucket follow a renamed repository or owner, but GitLab breaks the sync if the project or its group is renamed or moved. Deleting the repository stops sync.

Lovable works on one branch. By default that's the repository's default branch, usually main. If a push from Lovable is rejected, for example by branch protection, Lovable pushes to a branch called lovable-sync instead, and someone has to merge it. If you delete the synced branch, Lovable moves the project to lovable-fallback.

The repository holds code, not your running app. Secrets aren't in the repository. Database data, stored files and connector connections aren't either. AI features and connectors keep running through Lovable until you replace them.

Lovable apps come in two stacks, and they build differently. Projects created from 13 May 2026 use TanStack Start, which needs a host that runs server code. Older projects are React and Vite apps that build to static files. A guide written for one will break the other. I cover the stack change itself in taking a Lovable app to production, so here I'll stick to what it means for export.

Big files. GitHub rejects files over 100 MB, and Lovable can't save files over 10 MB.

The fix

1. Connect Git sync (any plan)

Open Project settings, then Git, then GitHub, then Add connection, or set it up once for the workspace under Workspace settings, then Git. Install and authorise the Lovable GitHub app, then click Connect next to the connection. Lovable creates the repository and starts syncing. Git sync also supports GitLab and Bitbucket Cloud.

If you only need a snapshot on a paid plan, use Download codebase in the code editor's file tree, or in Project settings, then Git. It won't stay in sync.

2. Check the stack and install

git clone git@github.com:your-org/your-lovable-app.git
cd your-lovable-app
 
# Which stack is this?
grep -q '"@tanstack/react-start"' package.json && echo "TanStack Start" || echo "React + Vite"
 
# Which package manager? If only bun.lock exists, use Bun
# or generate and commit a package-lock.json before using npm ci.
ls bun.lock package-lock.json 2>/dev/null
 
npm ci        # or npm install if there is no package-lock.json yet
npm run dev   # check the scripts in package.json for the exact command

Lovable's hosting guide builds with Node.js 22, so use that version locally too.

3. Set the environment variables

The variable names differ by stack. For older React and Vite apps, the browser needs these, and they are baked in when you build, not read at runtime. Change them and you must rebuild:

# .env (React + Vite). Never commit real values.
VITE_SUPABASE_URL=https://your-project-ref.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=your-publishable-key
VITE_SUPABASE_PROJECT_ID=your-project-ref

TanStack Start apps read SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and SUPABASE_PROJECT_ID on the server, plus any function secrets. Those secrets were never in the repository, so collect them before you switch hosts. Never put a service role key in a VITE_ variable: anything with that prefix ships to every visitor's browser.

4. Build for the stack you have

React and Vite:

npm run build   # output goes to dist/

Then tell your host to serve index.html for any path it doesn't recognise, or direct visits to nested pages return 404. On Vercel:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Netlify and Cloudflare use a _redirects file for the same job.

TanStack Start, on a host Nitro doesn't detect automatically (Vercel, Netlify and Cloudflare Pages need no preset):

NITRO_PRESET=node-server npm run build
PORT=3000 node .output/server/index.mjs

Static hosting or a CDN on its own can't run a TanStack Start app.

5. Export what the repository leaves out

Database data comes from More, then Database, then Manage, then Settings, then Export project data. Lovable emails you when it's ready, and you download it from More, then Storage. It's a PostgreSQL custom-format .backup archive (zstd compressed), restored with a pg_restore that supports zstd, not pasted into a SQL editor. You can run one export every 24 hours. Download stored files separately and copy each secret by hand. Then add your new domain to your auth provider's allowed redirect URLs before switching traffic.

6. Keep two-way sync from eating work

If you'll keep prompting in Lovable while a developer works in GitHub, agree who works where. Lovable now saves a backup and shows a notice when a Git push replaces its work, so you can restore it. If commits from GitHub aren't showing in Lovable, push a new commit to the synced branch to make it pull:

git commit --allow-empty -m "Trigger Lovable sync"
git push origin main

How to prevent it

• Connect Git sync on day one. It's free on every plan and gives you history from the start.
• Keep large media out of the repository. Use storage for anything near 10 MB.
• Don't delete the synced branch. If you add branch protection, expect Lovable's changes to land on lovable-sync for someone to merge.
• Keep a private note of every secret name and where its value lives.
• If you need a dependency list for a security review, Lovable can now produce an SBOM in SPDX or CycloneDX format.

When to get help

Exporting is the easy part. Getting a second copy of the app to behave exactly like the first, with auth, payments, files and AI features all reconnected, is where the time goes. My guide to taking a prototype to a product covers where export fits in a launch. For the general process across tools, read exporting AI-built code, and if you are leaving Lovable's hosting altogether, moving off Lovable or Bolt hosting goes further.

The Lovable to production guide explains when moving is worth it at all. If you want a second opinion first, run the free vibe-code health check. If the code needs fixing before anyone else sees it, a Rescue Sprint does that at a fixed price agreed after the check.