Sync Lovable To GitHub, Then Build Anywhere: A Plain-English Guide

There is a particular kind of quiet panic that arrives about six weeks into building something you actually care about. The app works. People use it. And somewhere in the back of your head a small voice says: this entire thing exists inside one company's web editor, and I do not own a copy of it.

Good news. You already do, or you can in about four minutes. Lovable has a native two-way GitHub sync. Turn it on and your code lives in your own repository, under your own account, on the world's most boring and dependable piece of infrastructure. And once it is there, other tools — Claude Code in a terminal, OpenAI's Codex reviewing your pull requests, a human developer you hire for a week — can work on the same codebase without anybody asking Lovable's permission.

This guide is for people who are not developers. I will not pretend Git is simple, because it isn't, and anybody who tells you otherwise is selling a course. But you do not need to understand it. You need to understand four ideas and avoid three mistakes. That's the whole article.

First, what GitHub actually is (thirty seconds)

GitHub is a filing cabinet with a perfect memory. It stores your project's files, and it stores every version of every file, forever, with a note about who changed what and when. That's it. That's the product.

The thing that stores versions is called Git. The website that hosts it is GitHub. A copy of your project on GitHub is called a repository, or "repo" if you want to sound like you belong. A saved change is a "commit". A proposed set of changes waiting for approval is a "pull request", or PR, which is the single worst name in computing for "here is some work, have a look before it goes live".

“You are not learning to code. You are learning to keep receipts.”

Step one: connect Lovable to GitHub

In your Lovable project, open the GitHub option in the top-right area of the editor and connect your account. Lovable installs a small GitHub app — it appears in your account as LovableBot — and creates a repository for your project. If you don't have a GitHub account yet, make one first; it's free, and the free tier is genuinely enough.

What happens next is the part people don't expect. This is not an export button. It is a live, continuous, two-way sync. Every change the Lovable agent makes gets committed and pushed to your repo automatically. And changes you push to GitHub get pulled back into Lovable. Both directions. All the time. Lovable's own documentation is unambiguous about this, and it supports github.com, GitHub Enterprise Cloud and Enterprise Server.

So after roughly one click you have: an off-platform backup, a complete audit trail of every change ever made, and a door through which other tools can walk in. Do this on day one of any project you care about, not on the day you get nervous.

Step two: understand what does NOT travel with the code

This is where people get hurt, so read this bit twice. Your repository contains your code. It does not contain your app.

• →Your secrets do not go to GitHub. API keys, credentials, tokens — these live encrypted in your app's backend on Lovable, deliberately outside the repo. That is correct and desirable behaviour. It also means a copy of the repo alone will not run.
• →Your database does not go to GitHub. Your backend — the tables, the rows, the authentication, the storage buckets — is a hosted service. The repo may describe its shape in migration files, but your actual customer data is not sitting in a folder on GitHub, and you should be glad.
• →Your uploaded files do not go to GitHub. Anything your users uploaded lives in storage, not in the code.
• →Your live deployment does not follow the code. If you clone the repo and deploy it to Vercel or Netlify or Cloudflare, that is a new, empty-headed copy that needs every environment variable and secret re-entered by hand before it works.

The mental model that keeps you safe: the repo is the blueprint, not the building. Blueprints are wonderful. You still cannot sleep in one.

Step three: pick your second tool

Now that the code is in a normal repository, it is just a normal software project, and the entire industry's tooling applies. Here are the three routes that actually make sense for a non-technical owner in 2026, in ascending order of commitment.

Route A: Codex reviewing your pull requests (lowest effort, highest value)

OpenAI's Codex — not to be confused with ChatGPT Sites, which I'll get to — connects to a GitHub repository and reviews changes. A collaborator comments @codex review on a pull request, or you switch on automatic review, and it reads the change and tells you what looks wrong. Other @codex mentions can start a cloud task: fix a failing build, implement a small change, open a PR back at you.

For someone who cannot read code, an automated reviewer is the single highest-leverage thing you can bolt on. It will not catch everything. It will catch the embarrassing things, and the embarrassing things are what get you in the newspaper.

Route B: Claude Code in a terminal (the real workhorse)

Claude Code is Anthropic's agent that runs on your own machine, in a terminal window, with your repository checked out in front of it. You install it once with npm install -g @anthropic-ai/claude-code, run it inside your project folder, and then talk to it in English about the code it can see.

The reason it matters is scope. It reads the whole project, runs the build, sees the errors, fixes them, and shows you the difference. It is very good at exactly the work Lovable is worst at — the long, boring, unglamorous 30% at the end: renaming things consistently, tidying duplication, chasing one bug through eleven files, writing tests.

It also installs a GitHub app of its own. Inside Claude Code you run /install-github-app, and afterwards you can mention @claude in an issue or pull request on GitHub and it will do the work there instead — no terminal required. That is the version to show a collaborator.

Cost, so nobody is surprised: Claude Code comes with the paid Claude subscriptions — roughly $20/month on Pro, $100 and $200/month on the Max tiers, per-seat pricing on Team — or you pay per token through the API. There is no Claude Code on the free plan.

Route C: a human, for one week, with a repo in hand

The unglamorous option nobody blogs about. Having a GitHub repository means you can hire a competent developer for five days without handing over the keys to your platform account, without them needing a Lovable seat, and without any conversation about "can you export it". They fork, they work, they open a pull request, you merge it, Lovable pulls it in. This is a completely ordinary way to work and it costs a fraction of what a rebuild does.

A necessary aside: ChatGPT Sites is not this

Because the question always comes up, and because the naming is genuinely confusing: ChatGPT Sites lets you ask ChatGPT to build, preview and publish a simple interactive website or lightweight app, hosted by OpenAI, straight out of a conversation. It is a pleasant tool for a landing page or a small internal gadget.

It is not a way to maintain your Lovable app. There is no GitHub repository behind it in the sense you need, no place to plug in your existing backend, and no path from "published site" to "the codebase my product actually runs on". If somebody tells you to move your product to Sites, they have confused a sketchpad with a workshop. The OpenAI product that maintains a real GitHub-hosted app is Codex. Use the right one and the confusion evaporates.

“Sites is a sketchpad. Codex is a workshop. Claude Code is a workshop with a very tired, very fast assistant in it.”

The three mistakes that will break your sync

Two-way sync is a lovely idea right up until two people rewrite the same paragraph at the same time. Here is how to never have that day.

• →Do not edit the same file in Lovable and outside Lovable at the same time. Pick one place to be working right now. Finish. Let the sync settle. Then switch. This single habit prevents almost every conflict you will ever hear about.
• →Do not rename the repository or force-push over history. Renaming breaks the connection between Lovable and the repo. Force-pushing deletes the shared history the sync depends on, which is the software equivalent of shredding the filing cabinet to save space.
• →Do not merge a pull request you do not understand while your app is live. Merging is instant and syncs back. Read the review, ask Codex or Claude to explain the change in plain English, then merge. "It said it was fine" is not a change-control process.

A fourth, softer rule: treat Lovable as the default place changes originate, and outside tools as the place changes are reviewed, cleaned up and hardened. Not because Lovable is precious about it, but because a single obvious source of truth is worth more than any tooling.

What this actually gets you

Strip out the tooling names and the benefit is boringly structural. You stop being a tenant. Your code sits in an account you control, in a format every developer and every AI agent on earth already understands, with a complete history you can roll back to. You can keep building in Lovable because it is fast and pleasant. You can send the hard, tedious, careful work to a tool that is better at hard, tedious and careful. And if you ever need to leave, leaving is a deployment task, not an archaeology project.

One caveat on the practical side, and it is the only genuinely technical thing in this article. New Lovable projects are server-rendered apps built on TanStack Start, not the older single-page Vite setup, which means running the project on your own laptop needs Node installed and the project's own build commands rather than any generic recipe you found in a 2024 tutorial. Ask Claude Code to get it running; that is precisely the kind of errand it exists for. If you never intend to run it locally, you can skip this entirely — the GitHub-based routes work without it.

The ten-minute version

• →Create a free GitHub account. Connect it in your Lovable project. Confirm the repo appears and shows commits.
• →Look at the repository once, in a browser, so it stops being abstract. Notice the history. That is your undo button of last resort.
• →Connect Codex to the repo and switch on pull request review. This is your safety net and it costs you no skill.
• →Install Claude Code when you next hit something Lovable keeps failing at. Run /install-github-app so collaborators can use it too.
• →Write down where your secrets and backend live, because they are not in the repo, and future-you will need to know that at the worst possible moment.

That is the whole discipline. It is less work than the average Monday, it takes one afternoon, and it converts your project from something you rent into something you own. Do it before you need it. Nobody has ever regretted having a backup and a second opinion.