Zero Infrastructure Cost: Hosting Static Sites on Cloudflare Pages

The monthly invoice for running a content site used to be a fact of life: hosting, a CDN, an SSL certificate, maybe a security plugin subscription. For a static site in 2026, that entire stack collapses to $0 — not through free-trial gimmicks, but because serving pre-built files is so computationally cheap that Cloudflare treats it as a loss-leader for its paid products.

Cloudflare Pages is the strongest of the free static hosts for one blunt reason: it is the only major one that does not meter bandwidth on its free plan. A post that goes viral on a metered plan is a billing incident; on Pages it is just a good day.

This guide covers the shape of the free tier, how it compares to Netlify, Vercel, and GitHub Pages, and the exact setup for a Hugo site — plus the limits you will eventually hit.

What the Free Tier Actually Includes

A caveat before the list, and it is the important part: every provider in this space revises its plan limits, and any specific threshold quoted in a blog post has a shelf life. Treat the shape below as a map, and confirm the current numbers against Cloudflare’s own Pages documentation before you architect around them.

• Unmetered static requests and bandwidth. No cap, no overage, commercial use permitted. This is the structural differentiator.
• A monthly build allowance on the built-in build system, with one concurrent build and a build timeout.
• A cap on files per deployment and on maximum individual file size — worth checking if you host large media or a very large image set.
• Multiple custom domains per project, with free automatic TLS certificates.
• Preview deployments — every branch and pull request gets its own URL.
• Pages Functions (serverless code for forms, redirects, APIs), metered by invocation on the free plan.

For a Hugo blog, the binding constraint is almost always builds, not traffic. The build allowance sounds enormous until a five-person team pushes commits that each trigger a deploy; heavy publishing months can brush the ceiling. The escape hatch — building in your own CI and direct-uploading — is covered below.

How the Free Tiers Compare

The distinctions that actually drive the decision are structural rather than numeric, because the numeric caps move:

Vercel’s hobby tier prohibiting commercial projects disqualifies it for any business site regardless of its technical merits. GitHub Pages remains fine for documentation and personal projects but offers no headers control, no redirects file, and no serverless layer. For a business content site, the practical choice is Pages vs Netlify, and unmetered bandwidth usually settles it.

Setting Up a Hugo Site, Step by Step

1. Push your Hugo project to GitHub or GitLab. Include the theme as a submodule or vendored directory — the build container clones recursively.
2. Create the Pages project: Cloudflare dashboard → Workers & Pages → Create → Pages → Connect to Git, and select the repository.
3. Configure the build:
   • Build command: hugo --gc --minify
   • Build output directory: public
   • Environment variable: HUGO_VERSION = 0.148.2 (match your local version exactly)
4. Deploy. The first build runs immediately; production tracks your default branch and every other branch gets a preview URL like abc123.your-project.pages.dev.
5. Attach the custom domain under Custom domains, and enable Always Use HTTPS. If your DNS is already on Cloudflare, this is a one-click CNAME.

Pinning HUGO_VERSION is the step people skip and regret. The default Hugo in the build image changes over time, and a silent minor-version jump can alter template behavior or break a deprecated function on a random Tuesday. Pin it, and upgrade deliberately.

If you are arriving from WordPress rather than starting fresh, sequence the hosting cutover after your redirect map is ready — the full order of operations is in our WordPress-to-Hugo migration guide.

Direct Upload: Skipping the Built-In Builds Entirely

The built-in build system is convenient but not mandatory. Wrangler, Cloudflare’s CLI, pushes any locally built folder straight to the edge:

npm install -g wrangler
wrangler login

hugo --gc --minify
wrangler pages deploy ./public --project-name=my-site --branch=main

Direct Upload is metered separately and does not consume your build allowance, because no build ran on Cloudflare’s side. This is the standard pattern once you graduate to building in GitHub Actions — where you control the toolchain, run link checkers before deploying, and keep Pages purely as a delivery network. We walk through that full pipeline, secrets and all, in automating Hugo deployments with GitHub Actions CI/CD.

Where $0 Ends

Honesty section. You will pay Cloudflare money if:

• Functions traffic grows. Once dynamic Function invocations pass the free allowance you move onto a paid Workers plan. Static assets never trigger this.
• You need more than one concurrent build, or your monorepo build runs past the free build timeout.
• You want advanced security controls. The free plan includes basic DDoS protection and lets you write a handful of custom firewall rules, but larger rule budgets, rate-limiting flexibility, and managed WAF rulesets sit on paid zone plans — we map what the free tier’s security actually covers in edge caching and Cloudflare WAF rules for static sites.

For a typical business content site — even one doing hundreds of thousands of page views monthly — none of these triggers fire, and the realistic annual infrastructure cost is the price of a domain name.

The Bottom Line

Serving pre-rendered files from an unmetered global edge for free removes an entire budget line and an entire class of scaling anxiety. Create the project, pin your Hugo version, attach the domain — the whole exercise fits inside an hour. If you would like an infrastructure review before you migrate production traffic, the MarketLens Standard Audit includes a hosting and latency assessment with specific, verifiable numbers for your current stack versus the edge.