Publishing a Website for Free: How to Choose GitHub Pages or Cloudflare¶

For / Key Points

For: People who want to publish a personal site, blog page, portfolio page, documentation site, or small landing page for free.

Key Points:

Choose GitHub Pages when simplicity and GitHub integration matter most
Choose Cloudflare when performance, bandwidth headroom, and future extensibility matter
Cloudflare is bringing Pages and Workers closer together, so long-running sites should understand the Workers path

For static blog pages and portfolio pages, GitHub Pages and Cloudflare are the two free hosting choices most people should compare first. Both support custom domains and HTTPS, and both can run small static sites without a monthly hosting bill. The question for this article is whether free hosting should be chosen for simplicity or for performance and extensibility.

The short answer: choose by use case¶

If all you need is a static site, either option can publish it for free. The differences show up in setup friction, traffic headroom, and whether you may later add dynamic behavior.

Use this three-line decision rule.

You want the fastest path and the code already lives on GitHub → GitHub Pages
You care about global traffic and page speed → Cloudflare
You may later add forms, APIs, authentication, or edge logic → Cloudflare

If you are unsure, start with the easier publishing path. Static sites are bundles of HTML, CSS, images, and generated assets, so they are usually portable. That portability is exactly why the main limits are worth checking before you begin.

What actually happens when a site is published¶

Publishing means putting locally created HTML and CSS files somewhere the public Internet can reach them. Most static sites follow this path.

Create files locally → push with Git → service builds the site → files are placed on a delivery network → visitors receive them

The delivery network is the CDN layer. A CDN returns files from locations close to visitors. GitHub Pages and Cloudflare both serve static files, but their limits and surrounding platform features differ.

Start with the simpler option: GitHub Pages.

GitHub Pages: code and publishing stay together¶

The main strength of GitHub Pages is that the repository and the published site feel like one system. A normal push can become the publishing workflow.

For free public repositories, the main limits are as follows¹.

Published sites may be no larger than 1GB
Bandwidth has a soft limit of 100GB per month
Builds have a soft limit of 10 per hour, unless you build and publish through a custom GitHub Actions workflow

One hundred gigabytes per month is roughly 100,000 page views if each page weighs 1MB. That is enough for many personal blogs and technical documentation sites, but not for video distribution, large downloadable files, or image-heavy assets at scale. GitHub also states that Pages is not intended as free web hosting for online businesses, ecommerce sites, or sites primarily providing commercial SaaS¹.

The other hard boundary is server-side code. GitHub Pages will not run PHP, persistent APIs, or database connections for you. It is strongest when the site stays static, and it asks you to add a separate platform when the site becomes dynamic.

Cloudflare sits on the other side of that tradeoff.

Cloudflare: speed and extensibility are the draw¶

Cloudflare's strength is that static delivery and edge compute live on the same broader platform. Cloudflare Pages lists unlimited static requests and unlimited bandwidth on the free plan².

The practical differences from GitHub Pages are fourfold.

Cloudflare's globally distributed network can help with low-latency delivery for international visitors
Static asset delivery gives you more bandwidth headroom
Build commands for tools like MkDocs and Hugo are straightforward to configure
Workers can later add APIs, authentication, redirects, or other dynamic behavior

This does not mean Cloudflare has no limits. The Pages free plan has 500 builds per month, 20,000 files per site, and a 25MiB limit for each site asset³. If you run dynamic code on Workers, you also need to account for Workers limits such as 100,000 requests per day on the free plan⁴.

So Cloudflare is not "everything is unlimited." The more accurate framing is that static delivery has generous headroom and there is a clear path to add dynamic behavior later.

The 2026 caveat: Pages and Workers are converging¶

Cloudflare has publicly described a plan to bring Pages and Workers into one developer experience⁵. As of 2026, Workers is also the place where Cloudflare documents broader support for static assets, back-end APIs, SSR, and a wider feature set⁶.

That does not mean you should avoid Pages today. For a purely static site, Pages remains a convenient option. But if the site will live for a long time or may gain dynamic behavior, it is worth understanding Workers configuration and deployment from the start.

Here is the comparison in table form.

Comparison Table¶

Dimension	GitHub Pages	Cloudflare
Best fit	Small static sites, docs, public repository workflows	Speed-oriented static sites, private repository workflows, future APIs
Bandwidth	100GB/month soft limit¹	Pages lists unlimited bandwidth²
Site size	Published site up to 1GB¹	Pages free plan: 20,000 files, 25MiB per asset³
Builds	Native flow is Jekyll-oriented; Actions adds flexibility	Build commands are easy to configure
Preview deployments	Not a core built-in strength	Unlimited active preview deployments³
Serverless code	Not supported	Available through Workers, with separate Workers limits
Private repositories	Requires Pro, Team, or Enterprise plans¹	Pages management is independent of whether the Git project is public or private³
Direction of travel	Stable static hosting	Pages and Workers are converging

Cloudflare may look better on paper. In practice, simplicity is a real feature. If you want to publish a README-style project site or documentation that already lives on GitHub, GitHub Pages is still hard to beat.

Which one should you choose?¶

GitHub Pages is the better fit when you want the lowest publishing friction. If your site source already lives on GitHub, the repository can be public, and you do not expect server-side behavior, it is a practical default.

Typical examples include:

Personal blogs and portfolio pages
Open source project documentation
Small learning or experiment pages

Cloudflare is the better fit when speed, bandwidth, or future expansion matters. It is also easier to justify when you want to publish from a private repository or later add forms, APIs, authentication, or A/B testing.

Typical examples include:

Blogs or media sites with international visitors
Static sites likely to grow in page count or image volume
Landing pages that may later gain Workers-powered features

Custom domains and HTTPS do not decide the choice. Both platforms support them. The real question is what you may want to add after the site is already live.

Minimal publishing steps¶

For an MkDocs site published to GitHub Pages, the typical command is short⁷.

mkdocs gh-deploy

For Cloudflare Pages, connect the GitHub repository in the dashboard and use these build settings for MkDocs⁸.

Build command: mkdocs build
Output directory: site

Neither path is difficult for the first publish. The longer-term decision is less about the first few minutes and more about the operation you expect after launch.

Summary¶

Choosing free static hosting is not an irreversible infrastructure decision. If your HTML, CSS, images, and Markdown remain cleanly separated, moving from GitHub Pages to Cloudflare, or back again, is manageable.

The first decision rule is simple. Choose GitHub Pages when you want GitHub-hosted code live as quickly as possible. Choose Cloudflare when speed, bandwidth, private repositories, and future dynamic behavior matter.

For long-running sites, the real strategy is to avoid locking the site too tightly to the first host. Keep the build command, output directory, and custom domain configuration explicit. Then changes in free-plan limits or platform direction become operational work, not a rewrite.

Building GitHub Pages with MkDocs — The basic path for publishing an MkDocs site on GitHub Pages
GitHub Actions auto deploy — Automating the path from push to published site
MkDocs deployment targets — A short overview of GitHub Pages, Cloudflare, and other deployment targets