How to Choose Hosting for a Static Site in 2026

Static hosting has been solved for a decade. Any of the major platforms will take a repository, build it, and serve the output from an edge network faster than your customers can notice. Feature comparisons are close to meaningless because the features converged years ago.

The decision is financial, and it turns on three metered lines that pricing pages present in three different units. Get those wrong and you find out in month four, when a marketing push and a hiring round land in the same billing period.

The three lines that decide the bill

Build minutes, bandwidth, and seats. Every platform meters at least two of them, and each one is defined differently enough that the numbers cannot be compared directly.

Build minutes are the least discussed and the most likely to surprise a content team, because they scale with editing activity rather than traffic. Bandwidth is the one everybody worries about and the one that is usually free for a purely static site. Seats are the one nobody checks, and the one that can quietly cost more than the other two combined.

The order of risk is roughly the reverse of the order of attention. Teams shop on bandwidth, get burned by seats, and never look at build minutes until the build queue starts rejecting them.

The three platforms most often shortlisted meter these lines in ways that do not line up, which is why "free tier" comparisons mislead.

Read down the columns, not across the rows. Each platform is cheap on a different axis, so the right choice depends on which line your site will stress.

Build minutes: the axis that scales with your editors

A build is a unit of compute, and you pay for the minutes it runs. A small site built with a modern framework takes somewhere between forty seconds and four minutes depending on image processing, page count, and how much the build re-fetches.

The trap is not the per-minute rate. It is the multiplier between what you think you build and what you actually build.

Every push to a branch can trigger a preview build. Every merge to main triggers a production build. If your CI also builds on a schedule for content updates from a CMS, that is a third stream. A repository with twelve active contributors and branch protection can easily produce ten times the builds that the person who set up the account expected.

Three things drive the number up faster than headcount:

• Image optimization at build time, which turns a two-minute build into a six-minute build once the marketing team uploads full-resolution photography.
• Monorepos, where a change to an unrelated package rebuilds the site unless you configure path filters.
• Rebuild-on-publish from a CMS, which fires a full build for a typo fix in a single paragraph.

Incremental builds and build caching are the fixes, and they are not equally available. Check whether the platform caches dependencies between builds by default, and whether a cache miss counts as a full-price build. On some platforms it does.

Bandwidth: usually free, occasionally catastrophic

For a genuinely static site, bandwidth should be close to free. The bytes are cached at the edge, and edge egress is cheap in a way that compute is not. Several platforms include unlimited bandwidth on static assets, which is not marketing generosity so much as an accurate reflection of what it costs them.

The trouble starts when the site is not purely static. A contact form that posts to a serverless function, a search index fetched at runtime, an image resizer that runs per request: each of those turns a cached page view into billable work. A site can look static and bill like an application.

The second trouble is page weight. Static sites are image-heavy by nature, and a marketing team uploading unoptimized photography can push a page from 400KB to 4MB without anyone noticing. At that point bandwidth is ten times what the traffic numbers suggest, and the invoice follows.

The practical check is not "how much bandwidth is included." It is "what happens to the bill when one page goes from a thousand views to three hundred thousand in a day." If the answer is a number you cannot predict, you are on the wrong plan for a site that might get attention.

Seats: where preview deploys become a billing event

This is the axis that deserves the most suspicion, because the definition of a "user" varies wildly and the pricing page rarely spells it out.

Preview deployments are the best thing to happen to web review. Every pull request gets a URL, so the client comments on the real page rather than a screenshot. The question is who is allowed to open that URL, and whether opening it makes them a billable user.

Some platforms treat preview URLs as public by default, in which case reviewers cost nothing and the feature is genuinely free. Others put previews behind team authentication, which is better for confidentiality and worse for the bill, because every stakeholder who needs to look at a draft now needs an account on the platform.

That is how a twelve-person content team ends up paying for twelve seats on a hosting platform, purely to look at pages they will never deploy. Add the client, the freelance copy editor, and the agency, and the seat count exceeds the number of people who can actually merge code.

The distinction to look for is between members and viewers. If the platform separates "people who can deploy" from "people who can look," the seat cost tracks your engineering team. If it does not, the seat cost tracks everyone who has ever been sent a link.

The arithmetic on a realistic site

Suppose a 400-page marketing site with twelve editors, three developers, and a client who reviews copy. The build takes four minutes and includes image processing. The team merges about fifteen times a week, and each merge produces a production build plus an average of two preview builds.

That is 45 builds a week, or roughly 195 a month, at four minutes each: 780 build minutes. A plan that includes 300 minutes is exceeded by 480, and at an illustrative 0.4 units per minute the overage is 192 units a month.

Bandwidth is not the problem. At 80,000 visits and a 3.5MB average page, the site transfers about 280GB. A plan including 250GB overages by 30GB, which at an illustrative 1.5 units per gigabyte is 45 units. Annoying, and smaller than the build overage.

Now the seats. If preview access requires an account, sixteen people need one. At an illustrative 7 units per seat, that is 112 units a month — more than half the build overage, for people who will never deploy anything.

The seat line is the one that grows with your organization rather than your traffic, and it is the only one you can often eliminate entirely by choosing a platform that makes previews public.

What matters less than the pricing pages imply

Framework support is close to a solved problem. Every major host builds the major frameworks, and the differences show up only when you need a specific rendering mode that one platform supports first. If your site is fully static output, this axis is irrelevant.

Edge locations matter less than page weight. A 4MB page served from the nearest city is still slow on a phone with two bars. Fixing the images will do more for perceived speed than any network topology decision.

SSL, custom domains, and rollbacks are table stakes. If a platform charges separately for any of them, that is a signal about how the rest of the bill is constructed.

The checklist before you commit

Price the site at the traffic you expect in your best month, not your average month, and count every human who will ever click a preview link.

Write down the exact number where each metered line becomes billable, and check whether the platform lets you set a hard cap. A spending limit is not a feature you configure later; it is the difference between a bad afternoon and a bad quarter.

Confirm how previews are authenticated, and whether a reviewer needs a paid account. This single question usually changes the ranking of the platforms more than any benchmark.