Last updated 7 August 2026
Static hosting is the one category in this series where the honest answer for most readers is "whichever is free". A directory of HTML, CSS, JavaScript and images does not need a process, a database or memory headroom; it needs a CDN, a certificate and somewhere to run the build. All five options below do that competently, and four of them do it at no cost for a site of ordinary size.
That makes the differences narrow but real. They are: what happens to the bill when a page is unexpectedly popular, whether you can set redirects and security headers, whether preview deployments per pull request matter to you, and how gracefully the platform handles the moment your static site stops being static — because a contact form, a search endpoint or an API proxy is where this category ends.
We should be direct about our own position. Granite is the most expensive option on this page and, for a purely static site, not the one we would recommend. It earns its place only when the static site is one piece of a project that already has applications and databases here, and you would rather have one bill and one deploy pipeline than one more account. If you are hosting a personal site, a documentation site or a marketing page and nothing else, use Cloudflare Pages or GitHub Pages and spend the money on something better.
At a glance
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| GitHub Pages | $0 | yes (public repos) | Git, GitHub Actions | ||
| Cloudflare Pages | $0 | D1, KV (separate) | Git, Wrangler CLI | ||
| Netlify | $0 | yes (300 credits) | Git, CLI, API | ||
| Vercel | $0 / $20 | yes (non-commercial) | via marketplace | Git | |
| Granite | $9 | from Advanced | Git, Docker image |
Entry prices as published by each provider on 7 August 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
Free, nearly free, or part of something bigger?
The bandwidth question is the only one with real money in it. Everything else in this category costs nothing at typical volumes, so the meaningful distinction is what happens on the day a page is linked from somewhere large. Cloudflare does not meter static asset requests at all. Netlify meters bandwidth in credits, Vercel bills it above an allowance, and GitHub publishes a soft 100 GB monthly limit that it enforces by asking you to move rather than by charging you. Pick with that day in mind, not with an average month in mind.
Headers and redirects separate the toys from the tools. A static site still needs a permanent redirect when a URL moves, a rewrite so a client-side router does not 404 on a deep link, and a Content-Security-Policy if it handles anything sensitive. Three of the five options here let you declare all of that in the repository. GitHub Pages lets you declare none of it, which is the single most important limitation to know before choosing it.
The moment it stops being static is worth planning for, because it usually arrives. A contact form, a newsletter signup, a search box, a call to an API that needs a secret key — each one needs somewhere to run code. Netlify and Cloudflare answer that within the same product; with GitHub Pages you will be adding a second provider. Knowing which of those futures you are in is more useful than comparing free tiers.
A note on what "static" now means. A site built by Astro, Hugo, Eleventy, Jekyll or a framework's static export is static in the sense that matters here: the output is files, and any option on this page will serve them. A framework using server-side rendering, incremental regeneration or server actions is not, however it started life — that belongs on the Next.js or Remix comparison instead.
Public repository, documentation or a personal page, no redirects or custom headers needed
GitHub Pages
Free, already in your workflow, and nothing new to learn.
GitHub Pages
Anything else that is genuinely static, including commercial sites
Edge platform
Free unmetered assets, real redirect and header control, functions when you need them.
Cloudflare Pages · Netlify
The site is one piece of a project whose apps and databases live somewhere already
Beside the rest of the stack
One bill and one pipeline, at the price of paying for something others give away.
Granite · Vercel
The options
GitHub Pages
- Best for
- A project site, documentation or a personal page that already lives in a public GitHub repository.
- Pricing
- Free for public repositories on any GitHub plan; publishing from a private repository needs a paid plan. Soft limits of 1 GB per published site, 100 GB of bandwidth a month and 10 builds an hour, the last of which does not apply to a custom Actions workflow.
- Genuinely free for public repositories, with no account to create beyond the one you already have.
- Publishing from a GitHub Actions workflow means any static generator works, not just Jekyll.
- Custom domains with automatic certificates, and the shortest possible distance between a commit and a published page.
- No control over response headers at all — no custom cache-control, no security headers, no Content-Security-Policy.
- No redirect rules, so a client-side router needs the 404-page workaround and moved URLs cannot be redirected properly.
- Publishing from a private repository requires a paid GitHub plan, and the soft limits — 1 GB per site, 100 GB of bandwidth a month — are not designed for a busy commercial site.
Cloudflare Pages
- Best for
- Almost any static site, and the default recommendation for most people reading this page.
- Pricing
- Requests to static assets are free and unlimited on both plans. The free Workers plan allows 100,000 function requests a day; Workers Paid is a $5/month minimum per account and includes 10 million requests and 30 million CPU-milliseconds a month.
- Static asset requests are free and unlimited on both plans, which removes the one genuine risk in this category — a bandwidth bill after an unexpected front page.
- Full control over redirects, rewrites and custom headers through files that live in the repository.
- One of the largest edge networks in the world serving your files, included rather than sold separately.
- When the site stops being static, Workers, D1 and KV are already there — and functions run on the same free plan up to 100,000 requests a day.
- The Workers platform has a genuine learning curve, and the surrounding product names change faster than the documentation for them settles.
- Once you need functions in earnest, the $5/month minimum and per-request billing put you back in usage-based territory.
- Deep integration with one vendor's edge platform is a portability decision as much as a hosting one.
Netlify
- Best for
- Teams that want previews per pull request, form handling and a polished workflow around the build.
- Pricing
- Free is $0 forever with a monthly allowance of 300 credits; Personal is $9/month and Pro $20/month with unlimited members. Usage is metered in credits — production deploys cost 15 each and bandwidth 20 per GB — so the plan fee is a floor rather than a forecast.
- The most mature build-and-deploy experience in this category, with deploy previews on every pull request and instant rollbacks.
- Redirects, rewrites, proxying and headers are all configured declaratively in the repository.
- Built-in forms, identity and functions cover the usual reasons a static site needs a back end, without adding a second provider.
- Billing moved to a credit system, and bandwidth consumes credits — so a traffic spike is the thing to watch, and spending limits are worth setting on day one.
- The free allowance is generous for a personal site and modest for a commercial one.
- Paid plans start at $9/month for Personal, which is real money against two free options that serve the same files.
Vercel
- Best for
- A static site that shares a repository, a workflow or a team with a Next.js application.
- Pricing
- Hobby is free forever but intended for personal, non-commercial projects. Pro is $20 per team member per month, including $20 of usage credit, with pay-as-you-go beyond it.
- The same build and preview pipeline as their framework hosting, so a static marketing site sits beside the app without a second workflow to maintain.
- Excellent preview deployments per pull request, with comments and sharing built around them.
- Edge network and automatic certificates included.
- The free Hobby plan is for personal, non-commercial projects, so a company site starts at $20 per team member per month.
- Bandwidth is usage-billed above the included allowance, which for purely static files is a cost the two free options simply do not have.
- It is the most expensive way to serve files that never change unless you are already using the platform for something else.
Granite
- Best for
- A static site that belongs to a project already running applications and databases on the same platform.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- S3-compatible storage with a CDN in front serves a static site perfectly well, with a custom domain and a certificate.
- One project, one bill and one set of credentials for the site, the API behind it and the database behind that.
- Nothing about the setup is specific to a generator or a framework — you publish files and they are served.
- The most expensive option here, and the only one with no free tier: $9/month against four options that will serve the same files for nothing.
- No build pipeline for static generators and no preview deployments per pull request — you build in CI and publish the output.
- For a site with no application behind it, this is the wrong recommendation and we would rather say so than sell it.
What a static site actually needs from a host
- Redirects that are actually redirects
- When a URL moves, search engines need a 301 and users need to land in the right place. A meta refresh or a JavaScript hop is not the same thing and is treated differently. Check that the platform supports redirect rules declared in the repository before you commit to it — retrofitting this is unpleasant.
- A fallback rewrite for client-side routing
- A single-page app serves one HTML file for every path, so the host must rewrite unknown paths to index.html with a 200 rather than serving a 404. Platforms with rewrite rules do this in one line. On GitHub Pages the workaround is a copy of the app at 404.html, which works but returns the wrong status code to anything that reads it.
- Two different cache policies
- Build output is fingerprinted — main.a1b2c3.js never changes — so it should be cached immutably for a year. The HTML that references it must not be cached that way, or visitors keep loading an old page that asks for files which no longer exist. Getting these the wrong way round is the classic static-site bug, and it needs a host that lets you set headers per path.
- Security headers
- A static site still benefits from Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options, and any site handling logins or payments through embedded widgets needs them. This is where GitHub Pages runs out: it serves your files with its headers, not yours, and there is no configuration to change that.
- Apex domain and automatic TLS
- Every option here issues and renews certificates for free. What differs is the apex: some platforms provide flattening or ALIAS records so example.com works as smoothly as www, and others expect you to point A records at fixed addresses. Check this if the bare domain is the canonical one.
- Build minutes and where the build runs
- The site is generated by something, and the platform either runs that build or expects finished files. Platform builds are convenient and metered; building in CI and publishing the output is more work and gives you a build you fully control. Both are reasonable — but know which one you are choosing, and what happens when a dependency install takes four minutes.
- Bandwidth on the worst day
- The only way a static site produces a surprising bill is traffic. Read the metering model rather than the free tier: unmetered static requests, a credit allowance, a byte allowance with overage, or a soft limit enforced by email are four genuinely different exposures on the day something goes viral.
- Preview deployments
- A URL per pull request is the single most useful workflow feature in this category, and the main thing the paid options are selling. If several people review content changes before they ship, it is worth more than any of the technical differences above; if you are the only author, it is worth nothing.
So which should you pick?
Almost everyone. Cloudflare Pages. Static requests are free and unmetered, redirects and headers are configurable, the edge network is among the largest available, and functions are there the day the site needs one. There is no scenario in this comparison where it is a bad answer.
A documentation or project site in a public repository. GitHub Pages, provided you will never need a redirect rule or a custom header. That caveat is doing real work — read it twice before choosing.
A team that reviews content before it ships. Netlify. Deploy previews, rollbacks and forms are what you are paying for, and they are genuinely good. Set a spending limit when you set up the account, because bandwidth consumes credits.
A static site that is part of something larger. Here — and only here — would we suggest Granite: publish the built files to an S3-compatible bucket with a CDN in front, in the same project as the API and the database the rest of the product runs on. One bill, one set of credentials, one place to look. For a site with nothing behind it, take one of the free options above; we would rather you did that than pay us $9/month to serve HTML.
If the site is not as static as it looks, the Next.js and Remix comparisons cover server rendering, and the S3 storage page covers buckets and the CDN in front of them.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.
Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.
Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.
Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.
Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.
Seven platforms for a framework that renders on every request — weighed on streaming, adapters, and how far the loaders sit from the database.
Six platforms weighed on what the JVM actually asks for: memory it is allowed to use, a container that knows its own limits, and a start-up you can afford to repeat.
Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.