How to Move a Lovable Project to Your Own GitHub Repo and Hosting

You can, and the code side is straightforward. Lovable's GitHub integration turns a project into a normal Git repository with two-way sync, which you can then connect to Vercel, Netlify, or another Git-based host the same way you would any other frontend project. The harder questions are what happens to your backend, your secrets, and your domain — and those depend on which pieces of Lovable you were actually using.

How do I get the code into my own GitHub repo?

From Project settings → Git → GitHub (or the chat actions menu), connect a GitHub account or organization. Lovable then "creates a new GitHub repository and starts two-way sync automatically," and the resulting repo is "private by default, so nobody can see your code unless you change its visibility on GitHub" (Lovable Documentation, "Sync your Lovable project with GitHub"). From that point, "changes made in Lovable sync to GitHub" and "changes pushed to the active GitHub branch sync back into Lovable" — though Lovable "only edits and syncs one branch at a time" (same source). Lovable also gives you clone URLs for HTTPS, SSH, and GitHub CLI, so you can clone the repo and keep working in your own editor.

Does it build outside Lovable?

Once cloned, it's a standard Vite project, or, for apps created from May 13, 2026 onward, a TanStack Start project with server-side rendering (Lovable Documentation, "SEO and AI search"). Install dependencies and run the project's normal build command to confirm it builds outside Lovable before you touch hosting. If the build fails locally, fix that first — a failure here will fail the same way on any host.

What happens to my backend?

If you're using Lovable's built-in backend (Cloud): Lovable's documentation is explicit that this is "a production-ready environment from day one, without needing to set up Supabase separately" — but leaving Lovable doesn't require leaving Cloud. You can keep using Lovable Cloud as your backend while your frontend deploys elsewhere; only your own frontend hosting changes. If you do want to move off Cloud entirely, "there is no one-click migration from the built-in backend (Cloud) to your own Supabase project" (Lovable Documentation, "Lovable Cloud") — you export your database and storage files first, since removing Cloud "permanently deletes your Cloud instance and cannot be undone" (same source).

If you're using the Supabase integration: nothing needs to move at all. "The Supabase integration connects a Supabase project you own to your Lovable project," and "your backend lives in Supabase" already — "day-to-day management of data, users, and files happens in the Supabase dashboard," independent of Lovable (Lovable Documentation, "Connect to Supabase"). Disconnecting from Lovable "does not change your code and does not delete anything in your Supabase project" (same source). Your Supabase subscription and its usage costs were already billed by Supabase, not Lovable, so this doesn't change either.

How do I deploy the frontend to my own host?

Lovable documents Git-based hosts — Netlify, Cloudflare Pages, Vercel, AWS Amplify Hosting, Azure Static Web Apps, and Google Firebase Hosting — as platforms that deploy "automatically from GitHub" once your project is connected there (Lovable Documentation, "Deploying and hosting outside Lovable").

On Vercel: click New Project, pick your GitHub repository, and Vercel walks you through the framework preset, build settings, and environment variables before you click Deploy (Vercel Documentation, "Deploying Git Repositories with Vercel"). Vercel treats your default branch (usually main) as the production branch: "a production deployment will be created each time you merge to the production branch," while every other branch gets its own preview deployment and URL (same source).

On Netlify: from your team dashboard, choose Add new project → Import an existing project, pick your Git provider, authorize access, and Netlify will "auto-detect your project's framework" from the default build settings before you confirm with Publish (Netlify Documentation, "Deploy from your repository").

Either way, once your frontend runs outside Lovable, Lovable's own documentation lists what you take on: build and deployment automation, SSL/TLS, CDN and reverse-proxy configuration, monitoring, logging and uptime, infrastructure updates and security, and preview environments (Lovable Documentation, "Deploying and hosting outside Lovable"). You can still keep using Lovable for development and previews — moving the production frontend doesn't require abandoning the Lovable editor.

How do I move environment variables and secrets?

Lovable stores secrets — API keys, tokens — under More → Cloud → Secrets (Lovable Documentation, "Lovable Cloud"). Frontend variables use a VITE_ prefix so Vite exposes them to client code at build time. None of that transfers automatically to a new host: re-enter each secret in your new host's own environment variable settings (Vercel's Project Settings, Netlify's Site configuration), and update any CORS rules, OAuth redirect URIs, or webhook endpoints that reference your old preview domain before you cut over.

How do I move my custom domain?

If you connected a domain in Lovable via Project → Settings → Domains, you pointed it using Lovable's DNS records: an A record to Lovable's IP and a _lovable TXT record for verification (Lovable Documentation, "Custom domain"). Moving it means changing those DNS records at your registrar to point to your new host instead (Vercel and Netlify each document their own required records). Expect a propagation window; Lovable's own domain documentation notes DNS changes there can take up to 72 hours, and the same is true in reverse. Keep the domain pointed at Lovable until your new deployment is verified working on a temporary URL, then switch DNS, so you're never without a working site during the cut-over.

What do you lose by leaving?

• The chat-based editing loop. Once you're building locally or through CI, changes go through your own commit-and-deploy process, not a prompt.
• Lovable's on-request pre-rendering for crawlers, if your app predates the May 13, 2026 TanStack Start change. Lovable documents it for verified crawlers on its deployed public URLs (Lovable Documentation); on your own host, what crawlers see depends on your own rendering setup. Our guide to a Lovable site that isn't showing on Google covers the options.
• One-click preview links tied to Lovable's own project view, unless your new host's preview deployments replace that workflow (Vercel and Netlify both generate their own preview URLs per branch, so this is a like-for-like swap, not a total loss).
• Nothing about your Supabase data or your domain, if you followed the steps above — those are yours regardless of where the frontend runs.

What should I check before I switch over?

• Repository clones and builds locally with no Lovable-specific step required.
• New host's preview deployment loads with no missing environment variables or broken API calls.
• Every secret from Lovable's Secrets panel exists in the new host's environment variables, and none were left hardcoded in the repo.
• Supabase (or Lovable Cloud, if kept) still authenticates and serves data from the new frontend's URL.
• CORS, OAuth redirect URIs, and webhooks updated to the new production domain before DNS switches.
• Custom domain resolves to the new host and serves a valid certificate after DNS propagates.
• Old Lovable preview URL and DNS records are only removed after the new deployment is confirmed live.

If you're weighing whether to keep iterating in Lovable at all versus owning the whole codebase from day one, How to Have ChatGPT, Claude, Codex or Cursor Edit an Existing Website covers what a coding agent can do once your project is a plain Git repository. And if the reason you're moving is that AI-built output never quite matched your design, Can AI Build My Website? is a plain look at what AI handles well and what still needs a human pass — including when a Figma-first workflow like Figment's fits better than another prompt-based rebuild.

Bottom line: GitHub sync gives you a repository you can deploy elsewhere. Check whether the exported project needs a server runtime or produces browser files only. Keep the existing services active while you test the new deployment.

Figment hosting note: Built browser files can be hosted on Figment. Source repositories that require package installation, a build, or server-side rendering need additional preparation or a suitable server host. Existing Supabase or Lovable Cloud services may remain separate, with their own charges. Login callbacks and data access need testing on the new URL; a one-click Lovable migration to Figment is not yet verified.