The key distinction
There are two separate things people mean by "private", and they have different requirements:
- Private repository: the source code is hidden, but the published site is still public.
- Private site: the published pages themselves are gated behind login.
These are not the same, and only the second one truly hides your content from the public.
1. Can the repository be private?
Only on a paid plan.
| Plan | Pages from a public repo | Pages from a private repo |
|---|---|---|
| GitHub Free (personal) | Yes | No |
| GitHub Pro (~$4/mo) | Yes | Yes |
| GitHub Team | Yes | Yes |
| GitHub Enterprise Cloud / Server | Yes | Yes |
On a free personal account, the repo must be public to use Pages. GitHub Pro is the cheapest tier that lets you publish from a private repo.
2. Does a private repo make the site private?
No. A GitHub Pages site is publicly available on the internet even when its repository is private.
So with Pro:
- Your source code / repo stays hidden.
- The published pages are still reachable by anyone who has the URL.
- Because the site is static, anyone can use "View Source" to read your HTML, CSS, and JS.
Caveat: Never put anything sensitive in the files: API keys, tokens, credentials, internal data. A private repo does not protect anything you ship to the published site.
3. What if the site itself must be private?
A genuinely access-controlled site (visitors must authenticate) requires an organization account on GitHub Enterprise Cloud.
If you need that and Enterprise Cloud is overkill, other static hosts handle gated access more cheaply:
- Cloudflare Pages + Cloudflare Access
- Netlify with password protection / role-based access
Quick decision guide
| What you need | What to use |
|---|---|
| Repo public, site public | GitHub Free |
| Repo private, site public | GitHub Pro |
| Repo private, site private (login-gated) | GitHub Enterprise Cloud, or Cloudflare Pages / Netlify |
Setup recap (any of the above)
- Put
index.htmlat the repo root; add sub-pages (guide.html, etc.) alongside it and link with relative links. - Settings โ Pages โ Source โ Deploy from a branch โ
mainโ/ (root), then Save. - Site goes live at
https://<username>.github.io/<repo-name>/within a minute or so.
Check your current plan first. The setup steps are identical regardless of plan: the only thing that changes is whether you're allowed to flip the repo to private.
One-shot prompt to recreate this guide
Paste the following into an AI assistant that can search the web and write files. It will research the topic from current sources and reproduce a guide in this format.
Copy this prompt
Research how GitHub Pages handles private repositories and write the findings
into a self-contained Markdown guide (.md file).
Research requirements:
- Verify every factual claim against official GitHub documentation
(docs.github.com), not training data. Plan availability and Pages
behavior change over time. Cite the GitHub docs pages you rely on.
- Specifically confirm: (a) which GitHub plans allow Pages from a private
repo, (b) whether a private repo makes the published site private, and
(c) what is required for a genuinely access-controlled/login-gated site.
The guide must:
- Lead with the core distinction between a PRIVATE REPOSITORY (source hidden,
site still public) and a PRIVATE SITE (pages gated behind login). These are
different and have different requirements.
- Include a plan-comparison table showing Pages support from public vs private
repos across Free, Pro, Team, and Enterprise.
- State the cheapest paid tier that unlocks Pages from a private repo, with
approximate cost.
- Warn that anything shipped to a static site is publicly readable via View
Source, so no secrets/keys/tokens belong in the files.
- Cover alternatives for a truly private site (GitHub Enterprise Cloud, and
cheaper options like Cloudflare Pages + Access or Netlify password
protection).
- End with a quick decision table (need to what to use) and a short setup recap
(index.html at root, Settings to Pages to Deploy from a branch to main to /root,
final URL pattern https://<username>.github.io/<repo-name>/).
Style:
- Concise. No filler or promotional framing; give honest trade-offs.
- Self-contained Markdown, no external image or asset dependencies.
- Use tables where they aid comparison.