How to Export Your Code Out of Lovable

Good news first: Lovable is one of the easier AI builders to leave. It writes an ordinary React project and syncs it to a GitHub repository you own. There is no proprietary runtime holding your app, no export request to file, no vendor to negotiate with.

The part people underestimate is everything that is not in that repository. The code comes out cleanly; the app does not run from code alone. Your database, your auth configuration, your storage buckets, your secrets, and your deployed functions all live in services the repo merely points at.

Here is the sequence that actually gets you from "connected to Lovable" to "running on infrastructure I control."

Step 1: Connect GitHub and get the repo

In your Lovable project settings, connect a GitHub account and create the repository. The sync is two-way — changes you make in Lovable land in the repo, and in the other direction pushes to the repo show up in the project. That bidirectional link is genuinely useful during the transition, because you can move development into a real editor while non-technical teammates keep using the builder.

Clone it and look at what you have: a Vite-based React application with Tailwind, a components directory, and a client configuration pointing at your Supabase project. If there is a supabase directory with functions or migrations in it, note that — it matters in step three.

Confirm the repo is under your account or organization, not a personal account of whoever set it up. Ownership of the repo is ownership of the export.

Step 2: Inventory what lives outside the repo

Before touching anything, write down every external dependency. This list is short and every item on it will otherwise bite you at deploy time.

Step 3: Get it running locally

Install dependencies, create a local environment file with your Supabase URL and anon key, and start the dev server. If the app fails to load, it is almost always environment configuration rather than code — the two recurring causes are variables missing the framework's required prefix so the build strips them, and a Supabase URL copied from the wrong project.

If you hit something more stubborn, environment variables not working covers the specific ways this breaks in Vite-based projects.

Step 4: Rotate every key before you deploy anywhere

Do this even if you are confident nothing leaked. Anything that has been in a builder session, a chat log, a screenshot, or a public repository should be considered compromised, and rotation is cheap compared to the alternative. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, with AI-assisted commits leaking at roughly 3.2% against a 1.5% baseline — this is the single most common way a small app gets hurt.

Specifically: rotate the Supabase service role key if it exists anywhere in your project, rotate any third-party API keys, and grep the repo for anything that looks like a credential before your first push to a public remote. Then add a pre-commit scanning hook so it cannot happen again — it takes ten minutes and it catches the exact mistake you are most likely to repeat.

Step 5: Verify row-level security before you launch

This is the step people skip and the one we most often get called about afterward.

Supabase serves your tables over an API using the anon key that ships in your frontend bundle. That key is public by design. The only thing standing between a stranger and your data is row-level security policies — and Lovable will build a perfectly functional app whether those policies are correct, permissive, or absent, because your own session reads your own rows either way.

Test it properly: create two accounts, sign in as one, and attempt to read the other's records directly through the API rather than through your UI. If anything comes back, you have a problem to fix before launch, not after. The full pattern set, including the policies that look right and are not, is in Supabase RLS mistakes in AI apps.

Step 6: Deploy somewhere you control

A Vite React app deploys cleanly to any static host with a build step. Connect the GitHub repo, set the build command and output directory, add your environment variables in the host's settings rather than in a committed file, and ship. Deploying to Vercel walks the specifics, and any comparable host works the same way.

Then re-point auth redirect URLs to the new domain, redeploy your edge functions, move DNS, and keep the Lovable project alive for a week as a fallback before you cancel anything.

Step 7: Decide what happens next

Exporting is not hardening. You now own a working app whose code you control, which is genuinely the hard part of leaving — but the missing engineering underneath it did not change during the migration. Validation, error handling, database indexes, a test around login and payment, and monitoring are all still to do. The full list is in the production readiness checklist, and the broader path is in migrating off Lovable.

Frequently asked questions

Do I lose the ability to keep using Lovable after exporting? No. The GitHub sync stays two-way, so you can keep prompting in Lovable while working in a real editor. Most teams eventually stop, because once a developer starts reshaping the code the builder's regenerations become more disruptive than helpful — but there is no forced cutoff, and you can run both for as long as it is useful.

Does my Supabase database come with me? It was never Lovable's. The Supabase project is yours already; you take over ownership of the account and nothing has to be moved. That is the fundamental reason leaving Lovable is a migration rather than a rebuild, unlike platforms whose backend is their own proprietary runtime.

Can I export without GitHub? The GitHub route is the supported path and the one worth using, because it gives you history rather than a snapshot. If you only have a snapshot, you have code but no record of how it got there — which makes the next engineer's job noticeably harder.

---

If you have exported the repo and are now looking at a codebase you are not sure is safe to open to real users, that is exactly the point where a second pair of eyes pays for itself. SprintX audits exported Lovable apps and hardens them at fixed scope. Send us the repo.