GitHub & Repo

How to Export Your Lovable Code to GitHub (and What It Does Not Include)

Exporting your Lovable code to GitHub takes one click: open Settings, connect your GitHub account, and Lovable creates a repo and pushes your full frontend and backend source. But the export only contains code. Your Supabase database, auth users, storage files, and secrets stay in Lovable-managed infrastructure — the repo alone will not run. Here is exactly how to export, and what you still own outside it.

Book a free audit call See the fix-it service

By Founder Name · Last verified: 2026-06-25

How do I export my Lovable code to GitHub?

Open your project, click the GitHub button in the top-right of the editor (or Settings then GitHub), and authorize the Lovable GitHub app. Choose an account or organization, name the repository, and Lovable creates it and pushes your code. From that point on, every prompt you run commits to the connected repo automatically — the sync is two-way and continuous, not a one-time download.

In the Lovable editor, click the GitHub icon in the top-right toolbar.
Click Connect to GitHub and authorize the Lovable GitHub app for your account or organization.
Choose the target account or org, then name the new repository.
Click Create Repository — Lovable initializes it and pushes the current codebase.
Open the repo on GitHub and confirm the latest commit matches your editor state.
Optional: run git clone on the repo URL to pull the full source to your machine.

There is no separate download-zip button for the full project. The GitHub connection is the supported export path. Once connected, the repo is the source of truth and Lovable commits to it on every change.

What exactly does the export include?

The export is your application source code: the React and TypeScript frontend, components, routing, styles, your Supabase edge function code, SQL migration files, and config like package.json and vite.config. It is a complete, buildable repository of everything Lovable generated. What it does not include is the running data and infrastructure behind that code — and that gap is where most self-migrations stall.

Think of it as the recipe, not the cooked meal. You get every line of code needed to rebuild the app, but not the live Supabase project the code points at. The frontend will compile, but on first run it will try to reach a backend it does not have credentials for.

Lovable Export Inventory — In Repo vs. Stays Behind
Asset	In the GitHub export?	Where it actually lives
Frontend code (React/TS, components, routes)	Yes — full source	Repo
Edge function source code	Yes — function .ts files	Repo (supabase/functions)
Database schema / SQL migrations	Usually — migration files only	Repo (supabase/migrations)
Live database rows (your users' data)	No	Supabase Postgres — not in repo
Auth users and password hashes	No	Supabase Auth (auth.users) — not in repo
Storage files (uploads, images)	No	Supabase Storage buckets — not in repo
Secrets and API keys (.env values)	No	Lovable/Supabase secret store — not in repo
Supabase project URL + anon key wiring	Partially — referenced, not provisioned	Managed Supabase instance

Why won't my exported repo run after I clone it?

Because the code is only half the app. The repo references a Supabase URL, anon key, and edge-function secrets that are not committed — by design, since secrets do not belong in git. Clone it, run npm install and npm run dev, and the build succeeds, but the app cannot connect to a database. This is the most common surprise for builders exporting for the first time.

We call this the What-Breaks-on-Export gap: a buildable frontend pointed at a backend that does not exist in the repo. The code compiles cleanly and then fails at runtime the moment it tries to authenticate or query data, because the environment it expects was never part of the export.

A second trap is The Vanishing Env-Var — environment variables that exist inside the Lovable runtime but are absent from your local .env and from any new host you deploy to. The build passes, the deploy succeeds, and the app throws supabaseUrl is required or a 401 from every API call because the values silently never made it across.

What NOT to assume: cloning the repo does not give you a portable, runnable app. Without the Supabase project, env vars, and data, you have a compiling frontend and an empty backend. Plan the data and secrets migration as a separate step before you call the export complete.

What happens to my Supabase database and users on export?

Nothing — they stay exactly where they are, in the Supabase project Lovable provisioned for you. Exporting code does not copy a single row, user, or uploaded file. Your live data and auth users remain in the managed Supabase instance. To truly own your app, you migrate the database and auth separately: dump the schema and data, then move to a Supabase project you control.

This separation is the whole reason export-only is not migration. You can have your code in your own GitHub org and still be fully dependent on Lovable-managed infrastructure for the database, authentication, storage, and secrets that make the app actually function.

Moving the backend means provisioning your own Supabase project, applying the migration files from the repo, running a pg_dump and pg_restore of your real data, and re-creating auth users (password hashes can be migrated, but it requires care so existing logins keep working). This is the step where a botched export turns into lost users.

Create a new Supabase project in an account you own.
Apply the SQL migration files from the repo to recreate the schema.
Run pg_dump on the Lovable-managed database and pg_restore into your own.
Migrate auth.users including password hashes so existing logins keep working.
Copy storage bucket contents and re-create bucket policies.
Update the frontend env vars to point at your new Supabase URL and keys.

Will exporting expose my API keys and secrets?

Not if the export behaves correctly — secrets are deliberately kept out of git, and your repo should contain a .env.example, never real values. The risk runs the other way: builders who hardcoded keys into client-side code during prompting. Anything in a VITE_-prefixed variable or pasted into a component ships to the browser and lands in your public-readable repo on every commit.

Before you make a repo public, grep the committed code for live keys: search for sk_, service_role, secret, and any provider key prefixes. A leaked Stripe secret key or Supabase service_role key in client code is a misconfiguration that grants full backend access to anyone who reads the bundle — rotate any exposed key immediately and move it server-side.

The correct pattern is that public-safe values (the Supabase anon key, the project URL) can live in client env vars because Row Level Security protects the data, while privileged keys (service_role, Stripe secret, any third-party server key) live only in edge-function secrets that never reach the browser or the repo.

If you find a service_role key, Stripe secret key, or any private token committed to your repo, treat it as compromised: rotate the key at the provider, remove it from the code, and move it into an edge-function secret. Deleting the commit is not enough — git history retains it.

Is exporting to GitHub the same as migrating off Lovable?

No. Exporting gets your code into a repo you own; migrating means the app runs entirely on infrastructure you control, with no dependency on Lovable to function. Export is step one of maybe five. Many builders connect GitHub, see their code, assume they are free — then discover the app dies the moment Lovable-managed Supabase, secrets, or hosting are out of the picture.

Full migration off Lovable means: code in your GitHub, database and auth in your own Supabase, secrets in your own secret manager, the app deployed to your own host (Vercel, Netlify, Cloudflare), and a working CI build that does not touch Lovable at all. Export checks one box. The other four are the migration.

Export vs. Full Migration — The Ownership Checklist
Layer	Just exported?	Fully migrated?
Source code in your GitHub	Yes	Yes
Database in a Supabase you own	No	Yes
Auth users under your control	No	Yes
Secrets in your own secret store	No	Yes
Deployed on your own host	No	Yes
Builds with zero Lovable dependency	No	Yes

Should I export and migrate myself, or get help?

If you are comfortable with git, pg_dump, Supabase auth migration, and re-wiring env vars on a new host, a clean export-and-migrate is a weekend project. If your app has live users you cannot afford to log out, real payment data, or storage you cannot lose, the safe move is to have an engineer do the cutover with a backup and a rollback plan so nothing drops.

The expensive failures we see are not the export itself — it is the data step: auth users migrated without working password hashes, RLS policies that did not come across, a storage bucket left behind, or a half-migrated app that points at two backends at once. We migrate the full stack, verify every row and user landed, and leave you with a repo and infrastructure you fully own — with a documented rollback path the whole way.

We do this as a fixed-scope migration: export, backend cutover to your own Supabase, secret hardening, host deploy, and a verification pass that proves your users and data survived. You keep full ownership of code and data throughout.

Frequently asked questions

How do I export my Lovable project to GitHub?

Click the GitHub icon in the top-right of the Lovable editor, authorize the Lovable GitHub app, choose an account or organization, name the repository, and click Create Repository. Lovable pushes your full codebase immediately. After that, the connection is two-way: every prompt you run commits to the repo automatically, so it stays in sync with your editor.

Does exporting to GitHub include my Supabase database?

No. The export contains your application code and SQL migration files, but not your live database rows, auth users, storage files, or secrets — those stay in the Supabase project Lovable provisioned. To get a fully runnable app you own, you migrate the database and auth to your own Supabase project as a separate step after exporting the code.

Why doesn't my exported Lovable app run when I clone it?

Because the repo has no backend to connect to. The code references a Supabase URL, anon key, and edge-function secrets that are intentionally not committed to git. The frontend builds fine but cannot reach a database, so you see errors like supabaseUrl is required or 401s on every API call. You need your own Supabase project and env vars to make it run.

Is there a way to download my Lovable code without GitHub?

The supported export path is the GitHub connection — there is no separate full-project zip download in the editor. Once you connect GitHub, you can git clone the repository to get the complete source on your machine. If GitHub is not an option for you, an engineer can help you extract and package the full codebase another way.

Will my API keys or secrets be exposed in the exported repo?

They should not be — Lovable keeps secrets out of git and your repo should hold a .env.example with placeholders, not real values. The real risk is keys you hardcoded into client-side code during prompting. Before making a repo public, search the code for sk_, service_role, and secret. If you find a live private key, rotate it immediately and move it server-side.

Does exporting to GitHub disconnect me from Lovable?

No. Exporting connects a repo and keeps a continuous two-way sync — you can still edit in Lovable, and changes flow to GitHub. The app also still depends on Lovable-managed Supabase and secrets to actually run. Disconnecting completely is migration, not export: you move the database, auth, secrets, and hosting to infrastructure you control before cutting Lovable out.

Can I edit my code in GitHub and push changes back to Lovable?

Yes — the sync is two-way. Commits you push to the connected repo flow back into the Lovable editor, and Lovable's prompt-generated changes commit to the repo. This lets you work in your own IDE. Be careful with large refactors: conflicting edits from both sides at once can cause sync issues that are easier to prevent than to untangle later.

What's the difference between exporting and migrating off Lovable?

Exporting puts your code in a GitHub repo you own. Migrating means the entire app — database, auth, secrets, and hosting — runs on infrastructure you control with no dependency on Lovable. Export is one step of about five. After exporting, you still need to move the backend, re-home secrets, deploy to your own host, and verify a clean build before you are truly independent.

How do I move my Lovable database and users to my own Supabase?

Create a Supabase project you own, apply the migration files from the repo to rebuild the schema, run pg_dump and pg_restore to copy your real data, and migrate auth.users including password hashes so existing logins still work. Copy storage buckets and policies too, then point your env vars at the new project. The auth and data step is where botched migrations lose users, so back up first.

Should I do the export and migration myself or hire someone?

If you know git, pg_dump, and Supabase auth migration and your app has no critical live data, doing it yourself is reasonable. If you have real users you cannot log out, payment data, or storage you cannot lose, have an engineer run the cutover with a backup and rollback plan. We migrate the full stack, verify every user and row landed, and hand you infrastructure you fully own.

Keep reading

Talk to a senior engineer — not a salesperson.

Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.

Book a free audit call