How to Export Lovable Code to GitHub

This guide is for anyone who built an app in Lovable and wants their own copy of the code on GitHub: as a backup, to work on it in an editor, or to deploy it somewhere else. You don't need to know Git. Lovable does the Git work for you.

Before you start

• A GitHub account. It's free at github.com.
• If nobody has connected GitHub to your Lovable workspace yet, you need to be a workspace owner or admin to add that connection. After that, project owners and admins can link projects to it.

Export your Lovable project to GitHub

Want the code on your own machine too? The same settings page shows clone URLs (HTTPS, SSH and GitHub CLI), so you can clone the repo and open it in Cursor, VS Code or any editor. If you only need a one-off copy, paid plans can use Download codebase in Project settings → Git without involving GitHub at all.

What changes after you export

Sync runs both ways, on one branch. Changes you make in Lovable are pushed to GitHub, and commits pushed to the synced branch on GitHub flow back into Lovable. Lovable edits and syncs one branch at a time: by default the repository's default branch, usually main. Work on other branches stays out of Lovable until you merge it into the synced branch.

Leave the repo where it is. Renaming the repository keeps sync running. Deleting it stops sync. If you disconnect and reconnect later, Lovable creates a brand new repository instead of reusing the old one. Lovable also can't import an existing GitHub repo: export only goes from Lovable to GitHub.

Don't rewrite the synced branch's history. Lovable's docs warn against force-pushing, rebasing or squashing commits that are already on the synced branch, because edits made only in Lovable can be lost. To undo something, add a commit that reverts it.

Pushing doesn't publish. A push updates the code and the preview in Lovable, but your live site only changes when you publish from Lovable.

What's in the repo, and what isn't. If your project uses Lovable Cloud, the repo includes a .env file with your backend's URL and publishable key (for example VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY), your Edge Functions under supabase/functions/ and your migration files under supabase/migrations/. It never contains the data inside your database. Secrets you stored in Lovable stay out of the repository, so any server code that reads them needs those values wherever it runs. And Lovable doesn't deploy a changed Edge Function or run a new migration just because a commit synced.

Seeing that publishable key in the repo is expected. Supabase describes publishable keys as safe to expose, with row level security deciding what they can reach. That's exactly why the first check below matters.

Before you ship: what to check in the exported repo

Now that the code is somewhere you can read it, these are the checks worth doing before real users arrive:

1. Row level security is on, with real policies. Every table your app uses needs RLS enabled and policies that tie rows to the signed-in user, not a policy that lets everyone through. See Missing row level security and the Supabase RLS guide.
2. No secret keys in VITE_ variables or client code. Lovable's docs put it plainly: variables prefixed with VITE_ are included in the code your app sends to the browser. A Supabase service role key, a Stripe secret key or an AI provider key should only ever live on the server. See Secret API key exposed in client bundle.
3. Auth is checked on the server, not just in the UI. Hiding a page or a button doesn't protect the data behind it. See Auth check only in client code.
4. Server code validates input and handles errors. Look at every place that accepts user input on the server, including the functions in supabase/functions/. Each one should reject bad input and return a clear error instead of crashing. See Missing input validation and Error handling in AI-built apps.
5. Sign-in and AI endpoints are rate limited. Without limits, one script can hammer your login or run up your AI bill overnight. See No rate limiting on sensitive endpoints.

For a longer list, the Lovable security checklist walks through ten common gaps and how to fix each one.

Get the repo reviewed before launch

Lovable made your repo private, so the route that fits is the FinishKit GitHub App. Install it and choose which repositories it can access, including this one. FinishKit then reviews the code across eight production readiness dimensions and hands you a Finish Plan: the blockers to fix first, with the evidence for each. If you've switched the repo to public and only want a first look, the free quick readiness check takes the GitHub URL and runs a short set of checks.

Sources: Lovable: Sync your Lovable project with GitHub, Lovable: Git sync overview, Supabase: API keys.