You Exported Your Lovable Code to GitHub. Now What?

Exporting a Lovable project to GitHub gives you a two-way sync on one branch, not a separate copy. Next: prove it builds outside Lovable, give Lovable its own branch, protect main, audit the history for secrets, add CI and a first test, and put every account in company hands. Then a developer can change the code without breaking what Lovable is still editing.

This guide is for founders who clicked the GitHub button in Lovable, often because an investor, a developer or a customer asked "where is the code?", and now have a repository they are not sure what to do with. The ten steps below take a day or two for a small app. None of them requires leaving Lovable.

What does connecting Lovable to GitHub actually do?

It links one Lovable project to one GitHub repository and keeps them in step. Lovable's GitHub integration docs describe the rules:

• "Changes made in Lovable sync to GitHub; Changes pushed to the active GitHub branch sync back into Lovable; Lovable only edits and syncs one branch at a time."
• By default that branch is the repository's default branch, usually main. You can switch it with the branch picker in project settings.
• Renaming the repository is safe: "Lovable detects the rename and updates the connection automatically." Deleting it breaks the connection and the project stops syncing.
• It only goes one way at the start: "You can only export from Lovable to GitHub, not the other way around." Lovable cannot import an existing repository.

Two practical consequences follow. Anything a developer pushes to the synced branch shows up in Lovable, and anything Lovable writes lands on that branch immediately. And because you cannot re-import, the repository Lovable created is the one to keep. Do not delete it and start a fresh one.

You also own the code. Lovable's self-hosting guide says: "Your apps, code, and content you create with Lovable are yours", and that you can host them wherever you choose.

What are the ten steps after exporting?

Step	What to do	Done when
1. Ownership	Move the repository and every service account into company-owned accounts	Two company admins on GitHub, Supabase, hosting, domain and Lovable
2. Local build	Clone, install from the lockfile, run and build outside Lovable	A clean clone builds with one documented command
3. Know the stack	Identify TanStack Start or React and Vite, and every external service	A one-page README lists stack, services and environment variable names
4. Branches	Give Lovable its own branch; developers work on feature branches	Nobody and nothing pushes straight to the branch you deploy
5. Secrets	Search the code and history for secret keys	No secret in the repository, current or past
6. CI	Run install, lint, type-check and build on every pull request	A red check blocks a broken change
7. First tests	One smoke test for the journey that matters most	CI fails if sign-in or the main page breaks
8. Database	Confirm the migration files match production	An empty database can be rebuilt from the repository
9. Hosting	Decide: stay on Lovable, split front end and backend, or self-host	A written decision, with what moves and what does not
10. Handover	Give a developer the minimum access they need, safely	They can open a pull request on day one

Step 1: who should own the repository and accounts?

The company, not a person. If Lovable created the repository under a personal GitHub account, transfer it to a company organisation with at least two admins. Lovable's docs say sync continues after a transfer when the workspace has a GitHub connection for the new owner, and disconnects otherwise, so connect the organisation in Lovable first. Do the same for Supabase, the hosting account, the domain registrar and any paid API. Losing access to one of these is the most common way founders end up locked out of their own product; the guide to a developer disappearing with your code covers what that looks like.

Step 2: how do I run a Lovable project outside Lovable?

Clone it, install exactly what the lockfile says, and run the same build a host would run.

git clone https://github.com/your-company/your-app.git
cd your-app
npm ci
npm run dev
npm run build

npm ci installs from package-lock.json and fails if it disagrees with package.json, which is what you want: it surfaces drift now rather than on a deploy. Some repositories carry both a package-lock.json and a Bun lockfile. Pick one package manager and remove the other lockfile, so your laptop, CI and the host all install the same versions.

If the build fails outside Lovable, stop here and fix that first. An app that only builds inside the tool that generated it is the first thing a developer or buyer will find. The ERESOLVE write-up shows the kind of install failure that passes locally and breaks on a host.

Step 3: what stack is a Lovable project?

It depends on when it was created. Lovable's self-hosting guide says: "New apps created from May 13, 2026 use TanStack Start, which runs server code. Older apps use React + Vite and build to static files." Check package.json for @tanstack/react-start or vite to see which you have.

Then write a short README that a stranger could follow: the stack, the build command, each external service (Supabase, Stripe, an AI provider, email), and the names, never the values, of the environment variables. Ten minutes on this saves hours in every handover that follows.

Step 4: how do Lovable and developers share one repository?

By not sharing a branch. Lovable writes to its synced branch as you prompt, so a developer working on the same branch will collide with it. There are two workable set-ups.

Set-up	How it works	Good for	Watch out for
Lovable keeps main	Lovable syncs main; developers branch from it and open pull requests back into it	Mostly Lovable, occasional developer fixes	Lovable's edits reach main without review; deploys follow them
Lovable gets its own branch	Switch Lovable to a lovable branch with the branch picker; protect main; merge both Lovable's and developers' work by pull request	Any app with real users, or a developer working regularly	Someone has to review and merge Lovable's branch; conflicts are resolved in the pull request

Once there are real users, the second set-up is safer: every change, generated or hand-written, passes the same checks before it reaches the branch you deploy. After switching, confirm that Lovable still syncs by making a small change in Lovable and seeing it arrive on the new branch.

Step 5: what should I look for in a secrets audit?

Secret keys in code or history. A public key is expected: Lovable projects that use Supabase need the project URL and the publishable or anon key in the browser, and that is safe when row-level security is correct. A service_role or secret key, a Stripe secret key or an AI provider key is not.

git grep -nE "sb_secret_|service_role|sk_live_|rk_live_|sk-proj-|sk-ant-" $(git rev-list --all)
git log --all --oneline -- .env .env.local

The first command searches every commit; the second shows whether an environment file was ever committed. If either finds a live secret, rotate it at the provider before anything else, then move the code that uses it into an Edge Function. Deleting the line does not help, because the value is still in history.

Step 6: what CI should a Lovable repository have?

A workflow that installs, checks and builds every pull request, so a broken change shows a red cross before anyone merges it. A minimal GitHub Actions file:

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint --if-present
      # Vite projects usually keep app settings in tsconfig.app.json.
      - run: npx tsc --noEmit -p tsconfig.app.json
      - run: npm run build
      - run: npm test --if-present

Expect the type-check to fail the first time; generated code often has type errors that the build ignores. Fix them, or record them and fix them in a week, but do not delete the step. Then make the check required on the branch you deploy, in the repository's branch protection settings.

Step 7: which test should I write first?

The one for the journey that makes money or holds data. For most apps that is sign-in, then the main action. One end-to-end test with Playwright is enough to start:

// tests/smoke.spec.ts
import { test, expect } from '@playwright/test'

// Assumes the built app is served locally, for example with "npm run preview".
test('home page loads and sign-in is reachable', async ({ page }) => {
  await page.goto('http://localhost:4173/')
  await expect(page).toHaveTitle(/.+/)
  await page.getByRole('link', { name: /sign in|log in/i }).click()
  await expect(page.getByLabel(/email/i)).toBeVisible()
})

It proves little on its own, and that is fine. It proves the app starts, the page renders and sign-in exists, and it gives the next test a place to live. RAITHub's approach to growing from there, test pyramid and CI gates included, is in how RAITHub tests software.

Step 8: is my database in the repository too?

Partly. Lovable's Supabase integration docs say that after you approve a schema change, Lovable runs it on your Supabase project and "saves the migration file in your project's code (under supabase/migrations/)". So the repository holds the changes Lovable made. It does not hold changes anyone made by hand in the Supabase dashboard, and it never holds your data.

The test is simple: can an empty database be rebuilt from those files and match production? If not, the schema has drifted, and fixing that comes before any developer changes the database. Also check that every table has row-level security on, because a policy added by hand in the dashboard is missing from the files.

Step 9: should I keep hosting on Lovable?

Often yes, for now. Lovable's self-hosting guide describes three paths.

Path	What moves	When it fits
Stay on Lovable	Nothing	You still build mainly by prompting and hosting is not a problem
Hybrid	Front end to a host such as Netlify, Cloudflare Pages or Vercel; backend stays	You need your own domain set-up, headers, previews or CI-driven deploys
Self-hosted	Front end and backend, to containers, virtual machines or Kubernetes	A contract, a data-residency need or cost at scale requires it

One line in that guide deserves attention before any move: "Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge Functions." A backend move is a project, not a setting. When you do move the front end, you will need to set the new host's environment variables, server secrets and sign-in redirect URLs, as the guide says.

Step 10: how do I hand the code to a developer safely?

Give the least access that lets them open a pull request, and keep secrets out of chat.

• Repository: read access, or write access to branches with main protected. A fix can arrive as a pull request; nobody needs to push to production.
• Supabase: invite them as a project member, preferably to a staging project first. Never share the database password or the secret key in a message.
• Services: the README from step 3, with variable names and where each value lives.
• The brief: what is broken or wanted, how to reproduce it, and what must not change.
• The exit: access removed when the work ends, and anything they created left in company accounts.

This is how RAITHub itself takes on work: the fix one issue page asks only for read access, steps to reproduce and the environment, and returns the fix as a reviewable pull request with a regression test. Larger engagements end the same way RAITHub's delivery process describes, with runbooks and alerting handed over so your team is not dependent on RAITHub afterwards.

Why RAITHub for this

• Steps 2 to 8 as one piece of work. A clean build, a branch set-up that keeps Lovable usable, CI, first tests and a database that can be rebuilt from the repository, delivered as pull requests you review.
• You keep Lovable if you want it. The goal is a repository a developer can work in safely, not moving you off a tool that still suits you.
• Your code stays yours. An NDA before access, IP assigned to you, and a fixed written quote after a free 15-minute technical audit.

RAITHub has not published a case study of taking over a Lovable project, so this post describes the process, not a past result.

When you don't need us

• The app is still an experiment. Keep prompting; do steps 1 and 5 now, because they are cheap and protect you, and leave the rest until users arrive.
• The clean clone builds and you have a developer. Hand them this list; it is a few days of work for someone who knows the stack.
• You need someone embedded in your team full time under your management. RAITHub works fixed-scope or as a dedicated team, not as staff augmentation.

If the clean clone does not build, or the database no longer matches the repository, see Code Rescue; the wider production gaps are in making a vibe-coded app production-ready.

Last reviewed: 29 September 2026. Lovable documentation checked on 29 September 2026.

To have the repository made safe to work in, pick Code Rescue on the contact form and share the repository URL; read access is enough for the free 15-minute audit.

Frequently asked questions

Can I keep using Lovable after exporting to GitHub?

Yes. The connection is a two-way sync: changes in Lovable are pushed to GitHub, and changes pushed to the synced branch come back into Lovable. Lovable edits one branch at a time.

Can I import an existing GitHub repository into Lovable?

No. Lovable's documentation says you can only export from Lovable to GitHub, not the other way around. Keep the repository Lovable created rather than deleting it and starting again.

Do I own the code Lovable generated?

Lovable's documentation says the apps, code and content you create with it are yours, and that you can host them wherever you choose. For contract questions, this is general information; confirm with your adviser.

Why does my Lovable project fail to build on my laptop?

Usually a lockfile or package manager mismatch, a missing environment variable, or type errors that the Lovable preview tolerated. Install with npm ci, compare environment variable names with the ones the app reads, and fix errors one at a time.

Is it safe that my Supabase key is in the GitHub repository?

The publishable or anon key is designed to be public, and is safe when row-level security is correct on every table. A service_role or secret key is not; if one is in the repository or its history, rotate it immediately.

Can I move a Lovable app to Vercel or Netlify?

Yes. Lovable's self-hosting guide describes a hybrid path where the front end moves to a host such as Vercel or Netlify and the backend stays. Moving the database alone does not move authentication, storage, realtime or Edge Functions.