Top picks by use case
| Use case | Recommended | Why |
|---|---|---|
| Cheapest, traffic-safe | Cloudflare Pages | Unlimited bandwidth on free tier |
| Best general DX | Netlify | Polished build, forms, identity built-in |
| Best for Next.js / React-heavy | Vercel | First-class Next.js support |
| Simple personal docs / portfolio | GitHub Pages | Free, zero-config, lives in your repo |
| Need full S3 control | AWS S3 + CloudFront or R2 + Workers | Maximum flexibility |
The main contenders
Unlimited bandwidth on the free tier. Deploys from Git. Global anycast network. Tight integration with Cloudflare Workers (run server logic at the edge), R2 (object storage), D1 (SQLite), KV. Build minutes are generous (500/month free). For any static site that might get popular, this is the host that won't burn you with bandwidth bills.
Best for: any site where "what happens if this hits the front page" matters.
The most polished static-host UX. Build plugins ecosystem is unmatched. Built-in forms, identity (auth), edge functions, blob storage. Commercial use is allowed on the free tier within bandwidth caps. Generous overall, with predictable upgrade paths.
Best for: small business sites, marketing sites, anyone who wants "more in the box."
Vercel makes Next.js. If your site is built with Next.js (even mostly static), Vercel is the smoothest experience — every new feature lands here first. Hobby tier prohibits commercial use, which catches some users off-guard. For non-commercial Next.js sites, excellent.
Best for: Next.js sites, personal projects on Next.js. See Vercel vs Netlify.
Free static hosting for any repo. No separate account, no UI to log into — push to a branch and your site is live. Built-in Jekyll support. HTTPS via Let's Encrypt. Cap on bandwidth (~100GB/month soft limit) and 1GB site size. Perfect for personal blogs, project docs, portfolios.
Best for: personal sites, project docs, anything where "lives in the same repo as the code" is a virtue.
The cloud-native DIY path. You upload built site to S3 or R2, point a CDN at it, manage TLS yourself. Maximum flexibility, more setup time. Most appropriate when you need specific control (custom redirect rules, integration with other AWS services) that managed hosts don't expose.
Best for: enterprise sites already in AWS/Cloudflare; specific edge-routing requirements.
What actually matters
- Bandwidth caps. Most free tiers cap bandwidth — exceed it and you're either throttled or billed. Cloudflare Pages is the outlier with unlimited bandwidth.
- Build minutes. Free tiers limit total build time per month. For sites that rebuild on every commit, this can run out faster than expected. Vercel has the most generous free build minutes; GitHub Pages doesn't count them at all (uses Jekyll/Actions).
- Commercial use rules. Vercel hobby tier prohibits commercial use. Netlify allows it. Cloudflare allows it. GitHub Pages allows it. Read the ToS if your site has any revenue.
- Custom domain + HTTPS. All major hosts support custom domains with automatic HTTPS. Verify before committing.
- Build cache. Hosts with build caches (incremental builds) make life much better for large sites. All major hosts support it; quality varies.
- Edge functions. If you need any server logic (a contact form handler, an auth check, A/B testing), check the edge-function story before picking. Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions all work; capabilities differ.
The "what could go wrong" check
Before committing to a host, ask:
- What happens if my site hits 1M views in a day? On Cloudflare Pages, nothing — unlimited bandwidth absorbs it. On Netlify/Vercel free tiers, you blow through bandwidth caps and the site may go down or you may be billed.
- What happens if I get DDoSed? Cloudflare's edge is built for this. Vercel and Netlify have protections but bills can climb.
- What if the host disappears tomorrow? A truly static site is portable — your source is in Git, the build output is HTML/CSS/JS. Migration to another host is hours, not days.
Build cost vs serve cost
For most static sites, build cost is the limiting factor on free tiers, not serve cost. A site that rebuilds 50 times a day will exhaust some hosts' build-minute quotas. Solutions:
- Only rebuild on main branch commits, not PR previews.
- Use incremental builds where available.
- For massive sites, consider self-hosting the build (GitHub Actions, your own CI) and just pushing the result to the host.
What to skip
- Surge, Render Static, Firebase Hosting: all functional, all overshadowed by the big four.
- "Free WordPress hosting": WordPress is not static; different category entirely.
- Self-hosted static (nginx on a VPS): can be cheaper for very high-traffic sites but you're now in the ops business. Worth it only at scale.
Frequently Asked Questions
Is Cloudflare Pages really unlimited bandwidth?
Yes, on the free tier. Limits are on build minutes and concurrent builds, not bandwidth. This is Cloudflare's deliberate market positioning.
Can I host a commercial site on Vercel's free tier?
Technically prohibited by the Hobby plan ToS. Enforcement has been inconsistent but real cases of commercial sites being asked to upgrade have happened. If your site has any monetization, choose Netlify, Cloudflare Pages, or Vercel's paid tier.
Can I migrate between these hosts later?
Yes — a static site is its source code. Add a new build config to the new host, point DNS to the new URL, done. Plan an hour for a small site.
What about Netlify Edge Functions vs Cloudflare Workers?
Both run V8 isolates at the edge. Workers has a much larger feature set (KV, Durable Objects, R2 access) and more mature ecosystem. Netlify Edge Functions are easier for "Netlify-first" workflows. For pure edge compute breadth, Cloudflare wins.
Is GitHub Pages good for a blog?
Yes — Jekyll, Hugo, or any static-site generator pushed to a GitHub Pages branch works well. Bandwidth limits (~100GB/month) are fine for most personal blogs. For larger sites, move to Cloudflare Pages or Netlify.
Should I use a CDN with my static host?
Cloudflare Pages, Netlify, and Vercel already are CDNs — they serve from edge locations globally. You don't need a separate CDN. For S3-based deployments, you do need CloudFront (or another CDN) in front.