GitHub is not your web host

GitHub and web hosting are two different jobs

GitHub and web hosting are different things. GitHub stores the source code for your website, with a history of every change. A host such as Cloudflare, Vercel or Netlify takes that code, builds it into a working website, and serves it to visitors. Connecting your AI builder to GitHub puts your files somewhere safe. It does not, by itself, put a website online.

The confusion is understandable. Hosts connect to GitHub so closely that the two can feel like one system: you save a change, and a minute later it’s live. But they are separate accounts at separate companies, and you can replace either one without touching the other. That separation is a feature. It’s most of what makes a site portable.

The chain from your domain to a page on a screen

When someone types your address into a browser, four separate things cooperate to show them a page.

Read from the top: the domain is looked up in DNS, DNS points to the host, and the host serves a website it built from the code in GitHub. The rest of this guide is about the three joints in that chain.

What a deployment is

A deployment is the moment a host takes a particular version of your code and turns it into the live website. When you hear “it’s deployed”, it means “this version is now the one visitors see”.

With a GitHub-connected host, deployments happen automatically. The host watches your repository. When a new change is saved to it, the host fetches the code, builds it, and swaps the new version in. Vercel, Netlify and Cloudflare all work this way, and all of them keep the previous deployments so a bad one can be rolled back.

That’s the healthy shape. The unhealthy shape is a host that gets its files some other way: uploaded by hand from one person’s laptop, or generated inside a builder that never writes them to a repository you can see. Both work until that person or that builder goes away.

What DNS does

DNS is the internet’s address book. Your domain’s DNS records say “for this name, go to that server”. When you connect a domain to a host, what you’re actually doing is adding one or two records that point at the host.

Two things about DNS matter for ownership. First, the records live in an account, usually at your registrar or at Cloudflare, and whoever controls that account controls where your domain points. Second, DNS is what lets you change hosts without changing your address: you move the site to a new host, update one record, and visitors never notice. The domain guide covers what nameservers are and the transfer guide covers how to change DNS without breaking anything.

Why the pieces can be moved independently

Because each layer only knows about the one below it, each can be replaced on its own:

• Move the domain to a different registrar, and the DNS records, host and code are untouched. The address keeps pointing where it did.
• Move DNS management from the registrar to Cloudflare, or back, and the host and code don’t change. You recreate the same records in the new place.
• Move to a different host, connect it to the same GitHub repository, and update one DNS record. The domain and the code are untouched.
• Move the code to a different GitHub account, or off GitHub entirely, and reconnect the host to the new location. The domain and DNS are untouched.

This is why the separation is useful rather than annoying. A site that’s all in one place, with the domain, the files and the hosting inside one builder, is convenient to set up and hard to leave. A site spread across these layers can be taken apart and reassembled without being rebuilt.

Who should control what

For a site you depend on, each of these accounts should be yours, or your business’s, with you as an owner rather than a guest.

“Control” means: it’s your login, your recovery email, your payment method, and you could remove anyone else’s access. Having a link to the dashboard is not control.

But can GitHub host a site?

Yes, in one specific case. GitHub has a feature called GitHub Pages that serves simple static websites straight from a repository. If your site is a handful of plain pages with no login, no database and no server-side code, it can live entirely on GitHub.

Most sites built with AI tools are not that simple. They’re React or Next.js applications with forms, sign-in, or a database, and those need a host that can build and run them. So the usual answer to “is GitHub hosting my site?” is no, and the way to find out for certain is below.

How to check your own setup

You can trace the chain for your own site in a few minutes, without any technical tools.

1. The domain. Search for “whois” plus your domain name. The result names the registrar. Can you log in there?
2. DNS. In the registrar account, find “DNS” or “nameservers”. If the nameservers belong to the registrar, DNS is managed there. If they name another company, DNS is managed there.
3. The host. Look at the DNS records. A record pointing at something ending in vercel-dns.com, netlify.app or a Cloudflare address tells you the host. If you can’t tell, the tool or person who set the site up can. Can you log in to the host?
4. The code. In the host’s dashboard, find the project and look for a “Git” or “Repository” setting. It names the GitHub repository the site is built from. Can you open it?

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.

• Deploying Git repositories with Vercel · Vercel
• Git overview · Netlify
• Workers Builds: Git integration · Cloudflare
• What is GitHub Pages? · GitHub
• What is DNS? · Cloudflare