GitHub Pages vs Cloudflare Pages: Where Should Your Static Site Live?

GitHub Pages vs Cloudflare Pages at a glance #

Limits above come from GitHub and Cloudflare, checked October 9, 2026. I would make this decision around review and publishing needs before comparing spare capacity.

Repository workflow: GitHub keeps public documentation close to the code #

Imagine an open-source library with a README, examples and a growing set of tutorials. Keeping its website in GitHub makes each correction part of a code review. Someone can fix a method name, reference the issue that prompted the change and propose the documentation update in the same pull request.

The branch publishing workflow lets you publish a repository's root or its docs folder. A plain site can use that route without a separate build platform. Other generators can use GitHub Actions to produce an artifact and deploy it. There's more configuration in that route, but the build remains visible beside the code.

Cloudflare's Git integration connects a GitHub or GitLab repository to a Pages project. You supply the build configuration and output location, and the platform deploys changes. For a team already working in GitLab, that support is a deciding advantage. Moving the repository to GitHub purely for website hosting would be extra work.

The extra Cloudflare dashboard isn't automatically a problem. It gives the site a deployment home separate from the repository, which can help a website owner who doesn't want to think about Actions workflows. But it is another account, permission relationship and configuration location to document.

For a small public project, I would start with whichever route leaves the fewest unexplained release steps. If everyone already reviews in GitHub and the build is straightforward, Pages is easy to justify. If a site owner needs branch controls and build settings in a deployment dashboard, Cloudflare becomes more attractive.

Winner for a public GitHub project's documentation: GitHub Pages.

Preview review: Cloudflare gives branches their own websites #

Cloudflare's clearest advantage is its preview deployment system. A branch can have a preview address, and eligible pull requests from the same repository can produce review deployments. The production domain continues showing the approved release while someone checks the proposed changes.

That solves a concrete documentation problem. A long page can look fine in Markdown and fail on a phone when a wide code example meets the site theme. A preview gives the reviewer a normal website to inspect. It also exposes navigation, search and asset problems that aren't visible in a text diff.

GitHub Pages publishes the site's selected output. It doesn't give every pull request a separate first-class website through the basic branch settings. You can arrange a preview workflow, but then you own that workflow's storage, addresses and cleanup. For a solo portfolio this may be unnecessary; for an editor approving several releases, it's real work.

Preview URLs need their own access decision. Cloudflare previews are public by default and carry a noindex header. Search exclusion doesn't stop a person who knows the address from opening it. Cloudflare Access can protect previews; the preview policy doesn't automatically protect the main pages.dev address or custom domain.

I would use previews for unfinished design and wording, then protect them if they contain non-public information. Never use a guessed-long URL as the security plan. Reviewers also need to know whether they're looking at a branch alias that changes or a particular deployment address.

Winner for reviewing changes on real pages: Cloudflare Pages.

Backend work: Cloudflare has a function path, GitHub serves files #

GitHub Pages serves generated assets. It won't execute a PHP contact script because you placed contact.php in the repository. A documentation site with browser search is still static; a server that receives form data or keeps account state is a different component.

Cloudflare Pages can add Functions in the Workers environment. That creates a route toward request handling without running a conventional server beside the static site. It also introduces a runtime, bindings, security decisions and a separate usage allowance.

I'd avoid adding functions just because they're available. A contact form can use a hosted form provider; a docs search can use a static index; a small portfolio may need neither. Each server-side feature adds behavior that someone must maintain. A function receiving email addresses needs input handling and a destination for the submissions, even though the page itself is simple.

If you already know the site needs application logic, Cloudflare gives you more room to extend the project. That doesn't make it a drop-in replacement for a PHP/MariaDB application. The runtime and data products have to fit the code you're building.

For GitHub Pages, connecting an external service can be a perfectly reasonable architecture. The question is whether you want that split. I would choose Cloudflare when a small function belongs closely to the site's deployment and choose GitHub when the site can remain an independent set of public files.

Winner for small server-side additions within the hosting platform: Cloudflare Pages.

URLs and release recovery: choose a predictable publishing routine #

GitHub user sites use <owner>.github.io; project sites normally add the repository name. Cloudflare assigns a pages.dev address. Both offer custom-domain routes. Those default URL shapes affect generated links: a project site under /handbook/ needs assets and navigation that respect that base path.

A June 2025 GitHub discussion shows how quickly this becomes confusing. A new publisher expected a user-site address while replies explained the special repository name and the difference between user and project sites. I'd decide on the final URL shape before configuring the generator, even if the custom domain comes later.

Keep a record of the source branch, output directory and deployment method. The website owner should be able to answer which commit produced the current site. In GitHub that answer lives in the repository's Pages workflow. In Cloudflare it lives in the deployment details and connected source.

Cloudflare provides a rollback workflow for returning production to an earlier successful deployment. With GitHub, changing the source back and deploying again can be a straightforward route for a small site. Either way, reversing the webpage doesn't reverse changes in a separate database or service.

I would rehearse a harmless text change and its reversal before a major navigation rewrite. The goal is having a release method you can explain to the next editor, including what happens when the build fails and how visitors keep seeing the approved version.

Winner for a separate deployment dashboard and rollback controls: Cloudflare Pages.

What public support discussions reveal #

GitHub Pages' appeal is its close connection to repository work, but its initial publishing setup can trip people up. The June 2025 thread above is mostly a URL and source-setting conversation. It reinforces my recommendation to settle repository naming and publishing source early.

Cloudflare's documentation makes another practical friction clear: choosing Git integration or Direct Upload is a project-level workflow choice. A Direct Upload project can't later become Git-integrated in place; you create a new project. I'd use Git integration for a site expected to receive regular content edits, then reserve Direct Upload for a build pipeline you control elsewhere (official workflow).

Neither observation gives a reason to switch a working site without a specific need. If your current publishing routine is reliable, the benefit should be something concrete, such as previews or GitLab support.

Choose GitHub Pages if... #

• Your site documents a public GitHub project.
• You want reviews, source and deployment history in one repository.
• The website can remain static and public.
• You can configure the generator for a project subpath when needed.

Choose Cloudflare Pages if... #

• Branch previews help editors approve releases.
• The repository is in GitLab or you want a separate deployment dashboard.
• Small Functions are part of the intended architecture.
• You're happy to maintain both repository and Cloudflare project settings.

Alternatives worth comparing #

Netlify is a candidate when deploy reviews and team workflows take priority. Render makes sense when the frontend sits beside services hosted there. Vercel is worth comparing for a framework-driven frontend, with the Hobby commercial-use restriction checked first. Use GitHub Pages alternatives to explore other catalogue options, and free code editors for the source-writing side.

Frequently asked questions #

Is Cloudflare Pages free?

Yes, it has a free static hosting tier. Build, file-count and asset-size limits apply, and Functions use Workers quotas. A custom domain still needs to be registered. Check the Pages limit page alongside any function or storage product you add so the complete project has a clear usage plan.

Can GitHub Pages publish a private repository for free?

GitHub Free Pages publishing uses public repositories. Paid GitHub plans support private repository sources. The resulting website is normally public even when the source is private; reader access control is a separate feature and plan decision. Don't place internal material there solely because the repository has a private badge.

Which service is faster?

I wouldn't name a speed winner without measurements for your site and audience. Both distribute static content. Image weight, JavaScript, font loading and caching can dominate the visitor's wait. I'd first fix the page's assets and check real loading behavior before moving hosts for an assumed speed benefit.

Can either host run my PHP website?

GitHub Pages cannot run PHP. Cloudflare Pages Functions also aren't a PHP webserver; they use the Workers runtime. A PHP application needs a compatible backend host or a deliberate rewrite of its server behavior. Exporting a static copy works only for features that can be represented as files.

Sources #

• GitHub Pages overview
• GitHub publishing sources
• Cloudflare Git integration
• Cloudflare previews
• Cloudflare rollback