GitHub Pages vs Cloudflare Pages for Internal Docs: Which Should You Use in 2026?
Display is our product. This page says where it does not fit. We checked GitHub's and Cloudflare's documentation and pricing pages on 20 October 2026. Plans change. Open the linked page before you decide.
Display is our product. This page says where it does not fit. We checked GitHub's and Cloudflare's documentation and pricing pages on 20 October 2026. Plans change. Open the linked page before you decide.
Decision table
| Your situation | Pick |
|---|---|
| All readers are on GitHub and you have Enterprise Cloud | GitHub Pages, private |
| Some readers have no GitHub account, and an engineer can set up Cloudflare | Cloudflare Pages + Access |
| Fewer than 50 readers and a budget of $0 | Cloudflare Pages + Access |
| The docs are public | Either. Both host static sites for free |
| A few HTML or Markdown files from agents, company only, no build step | Display |
Side by side
| GitHub Pages | Cloudflare Pages | |
|---|---|---|
| Private access | Needs GitHub Enterprise Cloud. Only for project sites that publish from a private or internal repository that an organization owns | Cloudflare Access: email PIN or an identity provider, with an Allow policy |
| Who can read a private site | People with read access to the repository. Sites on Enterprise Managed Users open only to enterprise members | People that your Access policy allows, with or without a Cloudflare account |
| Price for private access | GitHub Enterprise: $21 per user a month for the first 12 months, per the GitHub pricing page. Read the asterisk terms | Access: $0 up to 50 users. Pay-as-you-go is $7 per user a month, billed annually |
| Without the paid plan | GitHub's pricing page lists Pages for public repositories on Free | Pages is free. Preview and production URLs are public until you add Access |
| Deploy without Git | No. You publish from a repository, by branch or by a GitHub Actions workflow | Yes. Direct Upload with the Wrangler CLI or a dashboard upload. You cannot switch a Direct Upload project to Git later |
| Site size and file limits | Published site: 1 GB maximum. Source repository: 1 GB recommended. Bandwidth: 100 GB a month soft limit | Free plan: 20,000 files and 25 MiB for each file. A dashboard upload takes 1,000 files |
| Build limit | 10 builds an hour (soft). No limit with a custom Actions workflow | 500 builds a month on Free |
| Terms of use | Not for an online business, e-commerce or commercial SaaS | Read Cloudflare's terms |
| Protects previews | Not a separate concept | The Pages setting covers previews only. The production pages.dev address and custom domains need their own Access setup |
Setup for each
GitHub Pages, private
- Your organization must use GitHub Enterprise Cloud.
- Publish the site from a private or internal repository that the organization owns. It must be a project site, not an organization site.
- In the repository, open Settings, then Pages. Under GitHub Pages, choose the visibility.
- Give readers read access to the repository.
Read GitHub's page on changing the visibility of your Pages site.
Cloudflare Pages with Access
- Create the Pages project from Git, or use Direct Upload.
- In Zero Trust, add a login method: One-time PIN, Google or Microsoft Entra ID. New Zero Trust organizations do not get One-time PIN automatically.
- In the Pages project, open Settings, General and select Enable access policy. This step covers preview deployments only.
- To protect the production
pages.devaddress, edit the Access application. Under Public hostname, delete the wildcard (*) in the Subdomain field. Then select Enable access policy again to protect previews. - For a custom domain, create a separate self-hosted Access application for that hostname. Without it, the login page shows but does not let visitors in.
- Add an Allow policy with emails or an email domain.
- Open each URL in a private window and make sure that it asks for a login.
Read the Pages preview guide, the Pages known issues and the Access policy guide.
Display, for company-only docs
- Connect your agent to Display and sign in. Cursor, Codex, Claude Code or any other agent can do it. The docs have a setup guide for each agent.
- Tell the agent: "Publish runbook.html to Display and share it with the company."
- For a docs build in CI, an organization API key lets the pipeline publish the output file. Read Publish from CI/CD.
Organization members sign in to open a Company page. On Free and Solo, they use an email one-time password (OTP). Pro (€49 a month) adds Google and Microsoft sign-in. Outside readers get an invitation by email and enter an OTP. Display serves one HTML or Markdown file for each artifact. Publishing a directory or a ZIP file is planned. Display does not run builds.
When another option is better
- Your docs are public. Use GitHub Pages or Cloudflare Pages. Both are free, and both are good.
- Your docs live in the repository and engineers review changes by pull request. GitHub Pages keeps the docs next to the code.
- You need edge logic, redirects or Workers. Cloudflare Pages connects to the rest of Cloudflare.
- You need many files in one site with a navigation tree. Use a static host. Display serves one file for each link.
Display adds agent publishing, comments on the page and the same URL for every version. If you do not need them, a static host is enough.
FAQ
Related:
- GitHub Pages compared with Display - Display compared with Cloudflare Access - Vercel Deployment Protection, Cloudflare Access or a Netlify password
Free tier. No credit card. One-time password auth for viewers on free, Google + Microsoft SSO on Pro (€49/month flat).