How to download your code from Lovable

There are two supported ways to get your source code out of Lovable. Route one is a ZIP: Lovable’s FAQ says you can download your codebase as a zip from the code editor or from Project settings → Git. That one needs a paid plan: Free explicitly has no code downloads. Route two is Git sync, which creates a new GitHub, GitLab or Bitbucket Cloud repository and keeps pushing to it; Lovable documents github.com sync as available on all plans, which makes it the escape hatch when the ZIP is gated. Neither route exports your backend, and that is the part that catches people out.

The short version#

If you just want a copy of the code on your laptop, take the ZIP. If you want to keep building in an IDE, or hand the project to another engineer, set up Git sync, but read the Git sync failure modes first, because several of its operations are irreversible in ways the UI doesn’t warn you about. Both routes are one step in a bigger job; the full sequence lives in the Lovable migration guide.

The plan gate: what Free actually blocks#

Lovable’s subscription plans page is unambiguous about the Free tier. It has 5 daily build credits capped at 30 per month, 20 monthly Cloud credits and 4 AI credits, and explicitly no code editing, no custom domains and no code downloads. There is no workaround inside the product. Pro starts at $25/month and adds code editing and custom domains; Business starts at $50/month and adds governance features on top of the same credit tiers.

Beyond that, sources disagree on the details and you should know where the disagreement is:

• Some third-party guides report the codebase download as Business-plan-only. Others report it as available on any paid plan, which matches Lovable’s own code-mode documentation naming no specific tier.
• On Enterprise, third-party write-ups report that workspace admins can disable code download org-wide. If you work at a company and the option is missing on a paid plan, that is the first thing to check, because it’s a policy setting.
• Lovable’s Git sync documentation lists github.com sync on all plans, with GitHub Enterprise Cloud (data residency on *.ghe.com) and self-hosted GitHub Enterprise Server on the Enterprise plan. That plan listing comes from Lovable’s own docs. Lovable does not document Git sync as a workaround for the code-download gate, but since github.com sync is listed on all plans and the ZIP is not, it is the first thing to try if the download is unavailable to you: confirm it in your own project before you plan around it.

Route 1: the ZIP download#

1. Confirm the plan. Free cannot download code. On Enterprise, confirm an admin hasn’t disabled it.
2. Open the code editor, or Project settings → Git. Those are the two locations Lovable’s FAQ names for downloading the codebase as a zip.
3. Download and extract. You now hold a point-in-time snapshot. It does not update. Anything you prompt Lovable to build tomorrow is not in it.
4. Open package.json before anything else. This tells you which stack you are on, and everything downstream depends on the answer.

That last step matters more than it sounds. On 13 May 2026 Lovable changed its default stack for new projects from React + Vite (client-rendered) to TanStack Start with SSR, running on Cloudflare Workers (here’s what that means for SEO): announced on Lovable’s blog. Existing projects were not force-migrated; per that post, projects built before the switch continue to run as before. But an older project can also be upgraded to TanStack Start from chat. It costs credits and is reversible from version history. So TanStack Start dependencies mean an SSR project (either created after 13 May 2026 or upgraded later) while a Vite plus React Router dependency set means the older client-rendered stack. Either way, check the dependencies to see which local setup, server-function model and deployment target apply.

Route 2: Git sync#

Git sync is the better option if the code has a future beyond your hard drive, but it comes with documented sharp edges.

The action in the UI is Connect, not “Export to GitHub”: Lovable’s docs describe the feature as export and two-way sync. First-time setup for github.com runs: Add account → the GitHub popup → choose an account or organization → All repositories or Only select repositories → Install & Authorize. Lovable then registers the installation as a reusable workspace connection, and you click Connect next to the connection where the new repository should be created.

Four documented facts to internalize before you click:

• Connecting always creates a brand-new repository. Lovable’s docs list importing an existing repository as unsupported: you can only export from Lovable to GitHub. One project maps to one repository on one provider. New repos are private by default.
• Sync is genuinely two-way, on one branch. Changes pushed to the active branch flow back into Lovable. But Lovable edits and syncs one branch at a time, and you can’t switch or create branches while it is actively editing.
• Transferring the repo to another owner or organization breaks sync, and re-attaching it requires contacting support. Renaming the repository is safe: Lovable detects the rename. Renaming your GitHub username or organization is not.
• Disconnecting is effectively one-way. Reconnecting to the same repository after a disconnect is on the unsupported list; Lovable creates a new repository with the current project state, orphaning the original and its history.

Commits land authored by lovable-dev[bot] on github.com and GitHub Enterprise Cloud (<your-app-name>[bot] on self-hosted Enterprise Server, where you install your own copy of the app) and co-attributed to the workspace member who triggered the sync. The GitHub App requests Contents (write), Metadata (read), Pull requests (write), Workflows (write) and Administration (write): that last one is what lets it create repositories, and it is worth flagging to whoever approves app installs at your company.

What the size limits actually are#

The numbers people repeat (a 5 GB cap and one export request per 24 hours) come from third-party write-ups about the Lovable Cloud database export. They don’t apply to the code download. Axonbuild adds that the documentation publishes no chunked-export procedure above 5 GB; separately, search results indicate Lovable directs users over the cap to email support with their project ID. Treat the figures as reported rather than official, and treat the 24-hour throttle as the real risk: a botched database export costs you a full day before you can retry, so rehearse the restore before cutover day.

For the code itself, Lovable’s docs don’t publish a ZIP size limit. Git sync has two documented file-size limits instead: GitHub rejects files over 100 MB (a limit GitHub sets), and files over 10 MB cannot be edited inside Lovable.

What is not in the download#

This is the section everyone skips and then rediscovers at 2am. Your source code is not your application. The code export covers the code and nothing else; here is what stays behind.

Database schema, but not data. Migration files defining your schema travel with the repo. Rows do not: database contents are never in the repository. The Cloud database export is a separate action, and conversely it contains no application code whatsoever. Two exports, two halves, neither complete. The full runbook for moving the data half is in Lovable Cloud to Supabase.

Secrets (nothing at all. Third-party migration write-ups consistently report that Lovable secrets are write-only) the secrets view lists a name and a creation date and never a value. Lovable’s own docs don’t publish a contrary procedure for reading a secret back, so plan on regenerating rather than copying. There is no export of them, no .env file waiting in the ZIP. You must regenerate each key at the source provider (Stripe, Resend, an OAuth client, whatever you wired in) and re-enter it at the destination. Grep the exported code for the environment-variable names your functions reference; that gives you the checklist. Silent failure is the danger mode here: the app builds, deploys and looks fine until one code path runs.

Edge function source, but not deployment. Function code comes with the repo. The deployed function, its runtime environment and its secrets stay on the platform. If you were on the React + Vite stack with separately deployed edge functions, and you are landing on a Supabase project of your own, redeploying is on you, with the Supabase CLI installed and the destination project linked, that is supabase functions deploy plus supabase secrets set, then actually invoking each function rather than trusting that a successful deploy means a working function. Two caveats. If you were on Lovable Cloud you have no Supabase account, org, project or dashboard to run those commands against; Cloud is built on Supabase’s open-source foundation, but you stand up your own Supabase first. And on TanStack Start there are no separately deployed edge functions to move at all: server logic lives in the app as TanStack Server Functions and ships with the code. The secrets those functions read do not.

Storage files: none of them. Object storage is not in the code export and not in the database export. The deceptive part is that a database restore can report complete success, with matching row counts, while every object path in those rows returns 404. Files must be downloaded and re-uploaded bucket by bucket. Any signed URL stored in your database (anything with a token= parameter) belongs to the old project and is dead on arrival.

Auth users, partially. Passwords are not exported in a form that keeps sign-in working, so a migration means a password-reset flow for every user. Plan the customer email before the cutover.

Hosting behavior, and what crawlers actually receive. If you were on Lovable hosting, you leave behind its crawler pre-rendering: on older React + Vite projects Lovable serves pre-rendered HTML to verified crawlers on deployed public URLs, that behavior belongs to Lovable’s hosting, and your ZIP on Vercel or Cloudflare Pages will not do it.

On TanStack Start the SSR does travel with the code, but that buys you less than it sounds. Lovable’s docs describe the new stack as server rendering that returns fully rendered HTML. What you will observe is narrower: the cached HTML holds your chrome, nav and static route content, while Lovable’s generated pages query Cloud or Supabase from a React hook after the component mounts, in the visitor’s browser, after hydration. That data is not in the server HTML on either host, so it is not in what a crawler receives. Test the page that matters before you re-point DNS, and test a page with dynamically loaded content (CMS posts, product pages, directory listings: anything that isn’t written into the page’s source code), never the homepage:

# Use a page with dynamically loaded content.
curl -sS https://yourdomain.com/products | grep -c 'product-card'
# Compare against what you count in the browser. A gap is the whole problem.

What changes for crawlers when you leave is worth reading before you re-point DNS.

What you actually have now#

What to do next#

1. Open package.json and write down which stack you’re on. Everything else branches from that answer.
2. Get it running locally before you touch anything, on the Vite stack that means a .env.local with the VITE_-prefixed Supabase variables, or you get a blank screen and no error. Running an exported Lovable app locally walks through the specific variables and the vite: not found fix.
3. Build the secrets inventory now, while the Lovable project is still live and you can still read the names in the secrets view.
4. If you are leaving the platform rather than just taking a backup, do not remove Lovable Cloud until everything else is verified at the destination. Removal is permanent, it moves no data for you, and it is the last step: never the first.

If all you wanted was a copy of the code for peace of mind, you’re done: take the ZIP, commit it somewhere private, and move on. If this is step one of an actual migration, treat the download as the easiest part of the job, because it is.