Skip to content
RefinoStart free

How to move a Lovable website to GitHub and your own hosting

Lovable can put your site’s code in a GitHub repository under your own account, which is most of the way to owning it. What’s left depends on whether the site’s database and sign-in live in Lovable Cloud or in a Supabase project you own. This guide is the sequence for both.

Published September 11, 2026 · About a 10 minute read · Last reviewed September 2026

This guide is the Lovable-specific version of leaving an AI builder. It doesn’t re-explain domains, DNS, hosting, secrets or data; it says what Lovable offers for each and links to the general guide for the how. Everything here was checked against Lovable’s documentation on the date at the top, and these features change often, so check the linked pages before acting.

Not sure yet what you own there? The companion guide, do you actually own your Lovable site?, sorts the layers before you move anything.

What Lovable lets you take with you

LayerWhat Lovable offers today
CodeGitHub sync on every plan, including Free. It creates a new private repository under your GitHub account or organization and keeps it in sync both ways, one branch at a time. A ZIP download of the whole project needs a paid plan.
HostingLovable hosts at yourproject.lovable.app free on every plan. Custom domains need a paid plan. A published site stays live after you downgrade or cancel.
BackendEither Lovable Cloud (Supabase run by Lovable, paid in credits) or a Supabase project in your own account. Cloud data can be exported; there is no one-click move from Cloud to your own Supabase.
DomainDomains bought through Lovable are registered at Name.com as the sponsoring registrar. You can transfer them out with an EPP code after the 60-day lock, or point them at your own nameservers.
SecretsBackend secrets are write-only: once saved they can’t be viewed again, only replaced. Public VITE_ values live in a .env file that Lovable deliberately commits to the repository.

Step 1: Work out which kind of project you have

Two questions decide how much of the rest applies.

Which framework? Projects created before 13 May 2026 are React + Vite: a static site that builds to a folder of files and can be hosted anywhere. Projects created from that date use TanStack Start, which renders on the server and needs a host that runs server code. Vercel, Netlify and Cloudflare all can, but Lovable’s own guide to deploying elsewhere only covers the Vite kind, so a newer project needs a developer or coding agent to set the deployment up. Open the project’s code view and look at package.json: @tanstack/react-start in the dependencies means the newer kind.

Which backend? Open More, then Cloud. If Cloud is enabled, the database, sign-in, storage and edge functions run on Lovable Cloud, billed in your workspace’s credits. If instead the project is connected to Supabase in Project settings, the backend is a Supabase project in your own Supabase account and is already yours. If neither, the site has no backend and steps 4 and 6 are short.

Step 2: Get the code

Connect GitHub if it isn’t connected. In the project, open Settings, then Git, and connect a GitHub account or organization. Lovable installs its GitHub app there and creates a new private repository containing the whole project. This works on the Free plan. Two things to know before you click:

  • It’s export-only. Lovable can’t connect to a repository that already exists; connecting always creates a new one, and so does disconnecting and reconnecting.
  • While connected, don’t transfer, rename the account of, or delete the repository. Any of those breaks the sync. Renaming the repository itself is fine.

On a paid plan you can also download the whole project as a ZIP, from the code editor or from Settings, then Git. Use that as a backup, not as the main route: the repository is what a host deploys from. The repository holds the code and the database migration files, which describe the database’s structure. It never holds the data.

Step 3: Make sure the repository is under an account you control

The repository is created in whichever GitHub account or organization was authorized when Lovable was connected. If a freelancer or agency connected their own GitHub, the repository is theirs. Check the owner in the repository’s address, as the GitHub guide describes.

If it isn’t yours, the cleanest fix is to disconnect GitHub in Lovable and reconnect it with your own account, which creates a fresh repository under you. The old one stays with its owner; you can ask for it to be transferred to you afterwards for the history, but it won’t be synced any more, so don’t rely on it.

Step 4: Inventory secrets and platform-managed services

Use the secrets guide for the method. The Lovable specifics:

  • Public values are in the committed .env file: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID for a Cloud project. These are meant to be public and travel with the code.
  • Backend secrets, such as a Stripe secret key or a third-party API key, live in Lovable’s Secrets manager (Cloud) or in your Supabase project’s edge function secrets (own Supabase). They are write-only. List their names from the Secrets panel; you will re-issue each value at the service that provided it.
  • Built-in AI features use a Lovable-managed key that won’t exist outside Lovable. Any feature that calls a model through Lovable needs its own provider key on the new host.
  • Payments. Lovable’s built-in payments create a Stripe or Paddle account in your name that you claim, so the account ends up yours. If the project uses your own Stripe account instead, the key is a backend secret. Either way, Stripe stays; only the key and webhook need re-entering.
  • Email. The Resend connector sends through your own Resend account, which is yours. Lovable’s own Emails feature runs on Cloud and is paid in credits; a site using it needs a sending service of its own after the move.
  • Forms store submissions in the database, so they move with it.

Step 5: Prepare the replacement host

Create a project on Vercel, Netlify or Cloudflare connected to the repository, following the host move guide and the deployment walkthrough for Vercel, Netlify or Cloudflare. For a React + Vite project Lovable documents the settings: build command npm run build, output directory dist, Node 22, plus a rewrite so that every path serves index.html, since the site does its own routing. Enter the VITE_ values from .env as environment variables if the host wants them explicitly. Lovable installs packages with Bun, so a bun.lock file is in the repository; hosts handle this, but a developer running it locally should use Bun to get the same versions.

For a TanStack Start project there’s no official Lovable recipe. Ask a developer or your coding agent to configure the host for a TanStack Start app; it’s a supported framework on the major hosts.

Step 6: Move or keep the backend

This is where the two kinds of project diverge.

Own Supabase

Nothing to move. The database, users, storage and edge functions are in your Supabase account and stay there. The new host talks to the same project. Note the Supabase project’s owner and billing, per the data guide.

Lovable Cloud

You have two options, and the first is legitimate:

  • Keep the backend on Cloud and move only the frontend. Lovable supports this explicitly. The site on your new host keeps using the Cloud backend through the VITE_ values. The cost is continued dependence: Cloud is paid in credits and pauses when the workspace runs out.
  • Migrate to a Supabase project you own. There is no one-click migration. The documented route: export the database from More, then Cloud, then Advanced settings (databases up to 15 GB, an export file of at most 5 GB, one export per 24 hours, saved into Cloud storage, so download it); download storage files separately from the Cloud storage view; create your own Supabase project and apply the migration files from the repository’s supabase/migrations folder to rebuild the structure; import the data; re-enter every secret. User accounts export without passwords, so every user will need to reset theirs. Add the new domain to any sign-in provider’s allowed redirect URLs.

The migration route has its own guide, moving a Lovable Cloud site toward your own Supabase, with a table of what moves and what you recreate.

Step 7: Deploy and test before changing DNS

Use the new host’s own address to test the whole site: pages, sign-in, forms, anything that reads the database, payments in test mode. This is the test list in the host move guide. Anything that depends on the real domain, such as OAuth callbacks, gets checked again after step 8.

Step 8: Change the website DNS records

Follow the DNS guide. The Lovable-specific records:

  • A domain you connected to Lovable has an A record pointing at 185.158.133.1, or a CNAME in proxy mode, plus a TXT record at _lovable. Replace the A or CNAME with the new host’s values. The TXT record can stay until you’ve disconnected the domain in Lovable.
  • A domain bought through Lovable is registered at Name.com on Lovable’s behalf and managed from Workspace settings, under Workspace domains. You can either point it at your own nameservers, after which Lovable stops managing its DNS, or transfer it out: Configure, then the menu, then Transfer out, turn off the transfer lock and reveal the authorization code. The transfer is irreversible, the domain can’t be moved within 60 days of registration, and Lovable stops serving the domain the moment the transfer completes, so do this only after the new host is live. The builder-domain guide and the transfer guide cover the rest.

Step 9: Verify the site, forms, auth, email and payments

  • The site loads at the domain and at www, over https.
  • Forms submit and the rows appear in the database.
  • Sign-in works, including any “sign in with” provider, from the real domain.
  • Email the site sends arrives, from a service in your own account.
  • Payments complete and the webhook on the new host records them.
  • If the backend stayed on Cloud, the workspace has credits and the site still reaches it.

Step 10: Only then decide what to do with Lovable

Nothing forces you to leave. Lovable keeps working on the synced repository, and pushing commits from elsewhere updates the Lovable preview, though publishing from Lovable no longer matters once your host serves the domain. If you want a clean break:

  • Disconnect the custom domain in Lovable. For an externally registered domain this only disconnects; clear the old records yourself.
  • Unpublish the project. The lovable.app address can’t be removed, but unpublishing makes it inaccessible.
  • Remove Cloud only if the backend has been migrated and verified. See the warning above.
  • Downgrading keeps published sites and connected domains working, but the “Edit with Lovable” badge returns on the next publish from a Free workspace.
  • Disconnecting GitHub leaves the repository intact. It simply stops syncing.

Traps: when “connected to GitHub” isn’t the whole site

  • The repository never contains the data. Migrations describe the tables; the rows are in Cloud or Supabase.
  • Secrets can’t be read out. Every backend secret has to be re-issued at its source.
  • Cloud pauses without credits. A frontend hosted elsewhere goes dark with it.
  • Sync is webhook-driven. Commits made outside Lovable can be missed; Lovable documents an empty commit as the nudge. If Lovable and GitHub diverge, GitHub wins and Lovable’s edits go to a lovable-sync branch.
  • Newer projects are server-rendered. The static-hosting recipe doesn’t apply to a TanStack Start project.

Once the repository and host are yours, editing the words on the site no longer has to go through Lovable or any other builder. That is the situation Refino is built for, and it works on a site in exactly this state.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

Keep going

Or go back to the overview of what owning your site means, which ties all of these together.

  • Do you actually own your Lovable site?

    What you own when you build with Lovable, and what still depends on Lovable: the code and GitHub sync, hosting, domains bought through Lovable, Lovable Cloud versus your own Supabase, secrets, and what the documentation says happens when you stop paying. With an ownership checklist.

    About a 8 minute read

  • How to take your website with you when you leave an AI builder

    Leaving an AI website builder means more than downloading the code. An inventory of everything a site depends on, from the domain to the database to the secrets, and a structured checklist for moving it all.

    About a 10 minute read

  • How to put your website’s code in GitHub

    How to get the actual source code of your website into a GitHub repository you control, whether it’s already on GitHub under someone else’s account, only on a developer’s computer, or inside an AI or site-building platform. With a verification checklist.

    About a 11 minute read

Get started

Your first site is free.

Sign in with GitHub, connect the site you built with AI, and change its words yourself. Free covers one site, with no card and no end date. Pro covers up to five.

Questions first? Email hello@refino.dev. We read every message and reply ourselves.