Export Your Lovable App: Own the Code, Data and Backend

You can export your Lovable app whenever you want. Git sync copies the project into a GitHub, GitLab or Bitbucket repository you own and keeps the two in step, on every plan, while a one-off .zip download is available on paid plans. Neither export carries your data: database records, uploaded files and secrets move separately.

This guide is for founders who want the code in an account they control, teams bringing a developer onto a Lovable project, and anyone planning a move to their own hosting. It covers what the export contains, the two ways to get it, what you have to move by hand, and how to decide whether moving is worth the work. If you have not launched yet, start with the launch checklist for AI-built apps and come back to this when the app is live.

Key takeaways

• Git sync is available on all plans and gives you a two-way copy of the code in a repository you own. The .zip download is a one-time snapshot and needs a paid plan.
• The repository holds your code and your database migration files. It does not hold your records, your uploaded files or your secrets.
• Lovable edits one branch at a time, so give human developers their own branches and never rewrite the history of the synced branch.
• Moving the frontend to another host is the smallest useful step, and the backend can stay where it is while you do it.
• A full backend move means a new Supabase project, applied migrations, a data restore, re-created secrets and reconfigured sign-in, all verified before you switch traffic.

What do you get when you export a Lovable app?

You get the application source, the configuration files and the database migration files that describe your schema. On a project using Lovable's built-in backend that also includes Edge Function code under supabase/functions/ and migrations under supabase/migrations/ or drizzle/migrations/.

You do not get the contents of the database or the files in storage. Lovable states this directly: Git sync and the codebase download contain source files, including the migration files that define the database structure, and the data and storage files have to be exported separately (Lovable's ownership and portability documentation).

Part of your app	In the export?	What you do with it
Application code	Yes	Clone it and run it
Database structure, including RLS policies	As migration files	Apply them to the new project in order
Edge Functions and server code	As source files	Deploy them yourself
Records and user accounts	No	Export and restore separately
Files in storage	No	Download and re-upload into matching buckets
Secrets, keys and auth settings	No	Set them again wherever the code runs

The gap matters most when someone deletes a Lovable project believing the repository is a full backup. It is a backup of the code, not of the business.

Git sync or codebase download: which export do you need?

Use Git sync if anyone will keep working on the app, and the download if you only want a snapshot on disk. Git sync is the one that supports ongoing deployment, because hosting platforms build from a repository rather than from a zip file.

What to compare	Git sync	Download codebase
Plans	All plans	Paid plans
Direction	Two-way and continuous	One-way snapshot
Best for	Developers, code review, deploying elsewhere	An archive or a one-time handover
Where to start	Project settings, Git tab	Project settings, or the code editor

Three details catch people out. Lovable creates a new private repository when you link a project, and each project connects to one repository on one provider. The integration exports only, so you cannot import an existing GitHub repository into a Lovable project. And if you disconnect and reconnect later, Lovable creates another new repository instead of reusing the old one (Lovable's GitHub sync documentation).

How to export your Lovable app to GitHub

The connection has two layers: a workspace connection that authorises Lovable to create repositories in a GitHub account or organisation, and a project link that ties one project to one repository.

1. In Workspace settings, Git, GitHub, add a connection and install the Lovable GitHub app on the account that should own the code. Pick the company organisation, not a contractor's personal account.
2. Open Project settings, Git and connect the project. Lovable creates the private repository and starts syncing both ways.
3. Copy the clone URL from the same screen and clone the repository.
4. Read the README and package.json for the install and start commands, then run the app locally before you change anything.

For most projects that last step is two commands:

npm ci
npm run dev

Commits that Lovable pushes are authored by the lovable-dev[bot] identity rather than by the person who typed the prompt, which is worth knowing before you read the history looking for who changed what.

Give Lovable and your developers separate branches

Lovable edits and syncs one branch at a time, usually main. Keep it there and have developers work on feature branches that reach the project only when they are merged.

Do not force-push, rebase or squash commits that are already on the synced branch. Lovable keeps its own copy of that branch, and rewriting its history makes Lovable save a backup and then adopt your version, which only the project owner can restore. Undo a change with a new commit that reverts it instead.

If your repository protects main, Lovable's pushes are rejected and land on a lovable-sync branch, which then has to be merged through your normal review process.

A clone gives you the code, not the services

The .env file in the repository carries the URL and publishable key of your live backend, so an app running on your laptop reads and writes production data. Use test accounts and test records until you have a separate backend; a Git branch does not give you a separate database.

Values prefixed with VITE_ are compiled into the JavaScript the browser downloads, so a service-role key or a model provider key must never be stored in one. Our guide to storing and rotating API keys covers where each kind of credential belongs.

Two more things will not work locally until you set them up: sign-in redirects, which have to list your local address at the auth provider, and anything that depends on secrets held in Lovable, which stay out of the repository by design.

Moving the database, storage and secrets

Build the destination completely before you point anything at it, and leave the live app on the built-in backend until the new one passes its checks. The supported destinations are managed Supabase or self-hosted Supabase.

1. Create the new Supabase project and note its URL, project ID and publishable key.
2. Apply the migration files in their recorded order to recreate tables, indexes, policies, functions and triggers.
3. Restore the data export, which includes the auth tables and therefore the user accounts.
4. Enable each sign-in provider again and update its redirect URLs.
5. Copy storage files into buckets with the same names.
6. Set the function secrets and deploy the Edge Functions with the Supabase CLI.
7. Point a test deployment at the new backend, verify it there, and only then switch the real one.

Two warnings about users. Migrating the auth schema brings password hashes across, so people keep their passwords, but each Supabase project is provisioned with its own JWT secret, and a different secret invalidates existing tokens and signs everyone out (Supabase's notes on migrating auth users between projects). Schedule that for a quiet hour.

The migrations also carry your row level security policies faithfully, including the ones that were wrong. A move is a good moment to test those policies properly, with a second account and a direct call to the API.

Moving only the PostgreSQL database to a different provider does not move authentication, storage, realtime or Edge Functions, and you would have to build equivalents yourself (Lovable's guide to deploying outside Lovable).

Where should the app run after you export it?

The frontend can move on its own while the backend stays on Lovable, and that is the step most teams take first. Which hosts can serve it depends on how your project was generated.

What to check	Older React and Vite apps	TanStack Start apps, created from 13 May 2026
How to tell	No @tanstack/react-start in package.json	@tanstack/react-start is a dependency
What you deploy	Static build output in dist/	Server output plus static assets
What the host must do	Serve files, with a fallback to index.html	Run server rendering, server functions and API routes

Both build with npm run build on Node.js 22. Deploy to a temporary URL first and check four things against the version running on Lovable: open a nested route and refresh it, sign in and out, run a real write and a file upload, and on a TanStack Start app trigger a server function rather than only clicking around the interface.

Your lovable.app address keeps serving the last snapshot you published there, and the Publish button still publishes to Lovable hosting only. Point the custom domain at the new host once the checks pass.

Should you move off Lovable at all?

Export the code now, and move the hosting only when you have a reason. A synced repository costs nothing, gives you a copy outside the platform and lets a developer work normally, while moving the hosting transfers a long list of jobs onto you.

Lovable's advice is to move components when you hit a real constraint rather than a hypothetical one, and the constraints it names are compliance or data residency rules, networking requirements such as VPC peering, and organisational policies on hosting. The editor and the agent are a managed service that cannot be self-hosted, so leaving the platform means leaving those too.

The other honest reason is people. Once engineers work on the product every day they want pull requests, continuous integration, a staging environment and tests, and the repository is where those live. Keeping Lovable for quick changes while production deploys from the repository is a common middle position.

What you take on when the app runs elsewhere: deployment pipelines, SSL certificates, CDN behaviour, database backups, monitoring, row level security maintenance, OAuth credentials and model provider billing. If the live site already behaves differently from the preview, that is configuration rather than a reason to move, and the nine usual causes of a Lovable app breaking in production are worth ruling out first.

Common mistakes

• Treating the repository as a full backup. It holds the code and the schema, not the rows. Export the data on its own schedule.
• Rewriting the synced branch. A rebase or a squash on main replaces Lovable's copy and needs the project owner to restore it.
• Developing against production. The .env file in the clone points at the live backend, so a local test can delete real records.
• Hiding a secret in a VITE_ variable to make a build pass. It ships to every visitor, and a key that has been in a bundle has to be rotated.
• Retiring the old project too early. Keep the Lovable backend running until the new one has handled real sign-ins, writes and uploads.
• Leaving the repository in a contractor's personal account. Install the GitHub app on an organisation the company owns before the first commit lands.

Frequently asked questions

Do I own the code Lovable generates?

Yes. Lovable's documentation says the apps, code and content you create are yours, subject to third-party rights such as open-source licences, and that you can modify them, use them commercially and host them where you choose. A Git sync connection is what makes that ownership practical rather than theoretical.

Can I import an existing GitHub repository into Lovable?

No. The integration exports from Lovable to your repository and not the other way round. You also cannot reconnect a project to the same repository after disconnecting, because Lovable creates a new one.

Will my app still run if I stop paying for Lovable?

The exported code runs wherever you deploy it, but anything that routes through Lovable stops with the subscription. Model calls made through Lovable's AI gateway and the built-in connectors need your own provider accounts and keys once the app no longer uses Lovable's backend.

Do my users have to reset their passwords after a migration?

No, as long as the auth tables move with their password hashes. They will be signed out and have to log in again unless the new project reuses the original JWT secret, which is a different thing from losing a password.

How long does a move take?

Connecting the repository and running the app locally is an afternoon. Moving the frontend to another host is usually a day, including verification. A full backend migration with Edge Functions, storage, auth providers and a rehearsed switch is the part that needs real planning, and it is worth doing with someone who has done it before.

Owning your app without breaking it

Connect Git sync today, even if you are happy on Lovable. Then treat the data as a separate job: know where the records and the uploaded files live, how to export them, and who can restore them. When you do move something, move the frontend first, verify it on a temporary URL, and keep the old backend alive until the new one has served real users.

If you would rather hand the migration to senior engineers, AlgoSmiths works on fixed-price projects with a working demo every week, and finishes with production access, runbooks and a handover call. Our SaaS product engineering work is the place to start.