Do You Need GitHub or Separate Hosting for an AI-Built App?

Four jobs, often one tool

An AI app builder usually does four jobs at once. Before you add another service, name these jobs:

1. Generation means writing and changing the code.
2. Version control means keeping a history of changes that you can review and roll back.
3. Hosting means running the app at a public URL.
4. Access control means deciding who can open the app.

Lovable is the example in this guide, and it covers all four jobs. You edit the app in its chat, and Lovable can sync the code to GitHub. The Publish button deploys to a lovable.app address, and the publish settings control who can visit. Add GitHub or another host only if it solves a problem that you actually have.

When the builder alone is enough

If the limits of the builder’s hosting do not get in your way, stay on it. This applies most when the app uses the builder’s own backend (the server part) for the database, login, or file storage. In Lovable, the hosting works like this (publishing docs):

• Publish deploys a snapshot of the current version. Later edits go live only after you publish again.
• The visitor settings are Public, Invite only, Workspace, and Custom. Public lets in anyone with the URL. On Free and Pro, Invite only lets in only the people that you add, after they log in. Workspace and Custom are for Business and Enterprise.
• On paid plans, you can add a custom domain after you publish.
• Apps that use the built-in backend or AI features need available credits to serve requests.

For a prototype that a few people review, Invite only is usually all the protection that you need.

When to add GitHub

Connect GitHub if you want one of these:

• A history outside the builder
• Code review
• The option to keep working in Claude Code, Cursor, or another editor

Then follow these steps:

1. In Lovable, open Workspace settings > Git > GitHub (or Project settings > Git). Install the Lovable GitHub app (GitHub sync docs).
2. Link the project. Lovable creates a new private repository and starts two-way sync (changes go in both directions).
3. Clone the repository. Run npm install. Open the folder in Claude Code or your editor.
4. Commit and push to the synced branch. This is the default branch (usually main), unless you change it. The changes go back into Lovable.

These points often cause problems:

• Git sync always creates a new repository. To bring in an existing repository, download it as a ZIP. Import the ZIP with Upload code. Then connect sync to the new project.
• Lovable syncs one branch at a time. Work on other branches reaches Lovable only after you merge it into the synced branch.
• If Lovable shows “Lovable and GitHub have diverged”, a push can replace edits that exist only in Lovable. Lovable keeps a backup that the project owner can restore.
• Lovable cannot edit files over 10 MB that you pushed from outside Lovable. GitHub rejects files over 100 MB.

GitHub alone does not run the app or provide a database. It holds the code. A different service must still serve the app.

When to deploy somewhere else

There are three typical reasons to move the front end:

• Your company already runs everything on one host.
• You want preview deployments for branches.
• You need the access controls and analytics of that host.

The steps below follow the Lovable guide to hosting outside Lovable.

1. Connect GitHub first. The host deploys from the synced repository.
2. Identify the stack (the frameworks that the app uses). Lovable projects created from May 13, 2026 use TanStack Start. Older projects use React and Vite. If package.json lists @tanstack/react-start, you have TanStack Start.
3. Create the project on the host from the GitHub repository. Use Node 22 and the build command npm run build.
   • TanStack Start builds server output, so the host must run server code. Vercel, Netlify, and Cloudflare Pages detect it automatically.
   • React and Vite build static files to dist/. On Netlify and Cloudflare Pages, set the publish or output directory to dist. Vercel needs no setting.
4. Add the environment variables (named values that the host gives the app). If the app uses the Lovable built-in backend, copy the values from the .env file in the repository. The browser needs VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID. TanStack Start server code also needs SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and SUPABASE_PROJECT_ID. It also needs the secrets that your server functions read, and these secrets are not in the repository. The build fixes the VITE_ values, so redeploy after you change them.
5. For React and Vite, add a route fallback. Unmatched routes must serve /index.html. On Netlify or Cloudflare, use a _redirects file. On Vercel, use vercel.json. If you do not add a fallback, a nested URL that a visitor opens directly can return a 404.
6. Update the sign-in settings. Add the new production domain to the allowed redirect URLs of your auth provider (the service that signs users in). If you do not, sign-in fails on the new address.

These parts stay with Lovable after the move:

• The backend and the data can stay on the built-in backend while the front end runs on a different host. App connectors and AI features keep running through Lovable.
• Managed OAuth setup and automatic token refresh work only while the backend stays on the built-in backend.
• The Publish button still publishes only to Lovable hosting. The lovable.app address keeps serving the last version that you published there. Decide whether to unpublish it, so that testers do not end up on an old copy.

Moving the backend too

The Lovable built-in backend can move to managed or self-hosted Supabase (ownership options). These are the supported destinations if you want the database and login under your own account. This move is a data migration, not a switch:

• Export the database with Export data in More > Database > Manage > Settings. Download the storage files from More > Storage. Download both before you remove the built-in backend.
• The schema (the structure of the tables), the row-level security policies, and the storage bucket policies move through SQL migrations. User accounts come with their password hashes, so people keep their passwords. But everyone must sign in again.
• You must set up sign-in providers, secrets, environment variables, scheduled jobs, and app connectors again. AI features that ran through Lovable need your own model provider account.

Treat the move as a separate project. Restore everything into a test Supabase project. Test the sign-in and the data there. Only then, point the live app at the new backend.

Protect a private demo at the right layer

Put access control on the host, not in the code of the app. A password screen that an AI added to the page runs in the browser of the visitor. The content that it hides is often already in the files that the browser downloaded. Use one of these options:

• The Lovable Invite only or Workspace setting
• Vercel Deployment Protection
• Netlify private projects or password protection
• Cloudflare Access in front of Cloudflare Pages

Quick decision

Situation	What to use
A prototype that a few people review	Lovable hosting with Invite only
More engineering in Claude Code or Cursor	Add GitHub sync, keep Lovable hosting
Company host, branch previews or host analytics	GitHub plus Vercel, Netlify or Cloudflare Pages, with the backend still on Lovable
Full ownership of code and data	Move the backend to Supabase as a separate project

Before you commit to a full migration, move a small working copy. For the static-versus-server question in general, read how to choose hosting for an AI-built app.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.