How to Move a Lovable Project to GitHub
Getting a project into GitHub is the one move that changes your position rather than your workflow. Until the code sits in a repository you own, everything you built lives at someone else's address. After, it does not.
Here is the sequence, what genuinely transfers, and the parts people hit on the way.
Connect the repository
The path is the same on every builder that offers it. Open the project, find the GitHub control, authorize the app, pick or create a repository. Per Lovable's documentation, the code view is where you browse files, edit them by hand, and hand the model an exact file and line.
Two decisions are worth thinking about before you click.
Private, not public. A generated project routinely carries configuration you did not write and have not read. Make the repository private first; you can always flip it later, and you cannot unpublish something a crawler already indexed.
One repository per project. It is tempting to keep a monorepo of everything you have ever generated. Do not. When one of these becomes real, you will want its own history, its own issues, and its own deploy hooks.
What actually syncs, and what does not
This is where expectations and reality separate.
Source files sync. Markup, styles, scripts, components, configuration. That is the whole point and it works.
Secrets do not sync, by design. API keys and tokens are held by the platform and deliberately kept out of the repository. That is correct behaviour. It also means a fresh clone will not run until you supply your own values, and it means any key the platform held should be rotated once you leave.
Stored data does not sync. If your app has a database, the repository holds the schema and the code, not the rows. Exporting the data is a separate task, usually a CSV per table.
Deployment configuration usually does not travel. Domains, environment variables, and build settings live in the platform's project settings, not in the repository. Write them down before you disconnect.
| What | Travels to the repo | Where it actually lives | What to do about it |
|---|---|---|---|
| Source files | Yes | The repository | Nothing, this is the point |
| API keys and tokens | No, deliberately | Platform settings | Rotate them once you leave |
| Database rows | No | The database | Export separately, usually CSV per table |
| Environment variables | Names sometimes, values never | Platform settings | Write them down before disconnecting |
| Domains and DNS | No | Platform project settings | Note them; you will re-enter them elsewhere |
| Build and deploy settings | Sometimes, as a config file | Platform project settings | Check the file exists before assuming |
The rows that say "platform settings" are the ones that catch people. They are invisible in the repository, so a clone looks complete and fails to run for reasons that are not in front of you.
Moving a project you built before connecting
Order matters, and the intuitive order is the wrong one.
- Connect GitHub from inside the project. In most builders this pushes the existing code rather than starting empty.
- If it does start empty, download the codebase and commit it by hand. That is a one-time inconvenience, not a blocker.
- Clone the repository somewhere else and make sure it runs there. A repository you have never checked out is a backup you have never tested.
- Only now change anything on the platform side.
Step three is the one people skip, and it is the one that catches missing files, private dependencies, and configuration that only ever existed on the platform's machine.
The first three things to do in the new repository
Before you touch the code, spend five minutes on the repository itself. These are cheap now and expensive later.
Write a README that says how to run it. Two commands and the list of environment variables the project needs. Future you, on a different machine, at a worse moment, will need exactly this and nothing else.
Commit an example environment file with empty values. Not the real values. A file that lists which variables exist is the difference between a clone that runs in two minutes and a clone that fails with an error nobody can interpret.
Turn on branch protection on the default branch. One checkbox. It stops the specific accident where a sync from the platform overwrites work you did locally.
Four things that break on the way
The build does not run on a clean checkout. Almost always a missing environment variable or a dependency that was installed on the platform and never written into the manifest. Cloning to a second machine surfaces this in minutes.
Two-way editing gets confusing. Once the repository exists, you can edit in two places. Most builders sync both directions, but a change made in both at once produces a conflict at the worst moment. Pick one side as the source of truth per session.
Large files are rejected. GitHub refuses files over 100 MB. Generated projects rarely hit that, but bundled video and image sets do.
The default branch is not what you assumed. Deploy hooks and Pages settings point at a specific branch. Check which one the platform pushed to before wondering why nothing deploys.
What changes once the code is yours
Not much on day one, and quite a lot afterwards.
You get history, so a bad change is one revert away rather than one apology away. You get a place to deploy from that is not tied to a subscription. You get the ability to hand the project to a developer without handing over your account. And you get the option to leave without an argument, which quietly changes the tone of every renewal decision.
How this works on our side
Writing about our own product, so specifics rather than adjectives.
GitHub sync exists and pushes project sources to a repository you own.
Export is not tied to a plan. Downloading your own work does not require a paid tier. There is no charge for the ability to leave.
The archive explains itself. Inside there is a README in your language: how to open it immediately, which hosting options are verified, what to do with the sources. It is written for the moment somebody is walking out and annoyed, so it is short.
One honest caveat. An exported site is fully self-contained. An exported game fetches its rendering engine, and an exported app fetches React, both from zugo.dev. Your code does not depend on us; that one library arrives over the network. The README says which files to download next to index.html and what to change so the folder depends on nothing at all. Staying quiet about that would be the exact behaviour this article warns about.
Related reading: downloading code from Lovable and putting an exported project on your own hosting.
In short
Connect the repository private, one per project. Expect source to travel and secrets, data, and deploy configuration not to. Clone somewhere else and confirm it runs before you change anything on the platform. And treat the repository as the real deliverable: it is the part that stays yours regardless of what happens to any account.