You built a one-page site someone paid you for, and you are about to put it on a free plan. The question is not whether the free plan can handle it — it is whether the host's own terms permit it. Two different walls, and only one of them shows up as a bill.
You built a one-page site. Someone paid you for it. You are about to drag it onto a free plan and send them the link.
The question you probably asked yourself was will the free tier handle this — the traffic, the file size, the uptime. That is a reasonable question and it is not the risky one.
The risky one is am I allowed to.
Every free tier has a limit you can see. Storage, bandwidth, build minutes, a page count, an expiry date. You approach it gradually, you can usually watch it happening, and when you cross it the host tells you and offers to sell you more. That is the capacity wall, and we wrote the whole map of it in when does free HTML hosting stop being free.
The other wall is in the terms of service, and it has none of those properties. It does not fill up. There is no meter. You can sit behind it for a year at 40 visitors a month and be no closer to it than on day one — and you can also be on the wrong side of it from the very first upload, without anything at all happening for months.
That asymmetry is the whole problem. A policy breach has no early warning system, because there is nothing accumulating. The first signal is somebody deciding.
This is where the intuition is usually wrong, and it is wrong in a specific direction.
Most people read "non-commercial" as a statement about the page: no shop, no checkout, no ads, nothing being sold. Under that reading, a brochure site for a dentist is obviously fine — nothing is being sold on it.
A policy can reach further than that: not only to the money on the site, but to the money around it. Being paid to build it. Being paid to update it. Hosting it on behalf of someone who is paying you. Under that reading, the dentist's brochure site is commercial not because of anything on the page, but because there is an invoice with your name on it.
Which reading applies is not a matter of interpretation you get to make. It is written down, in the host's own words, and the whole point of this article is that you should go and read those words rather than reason about them from first principles.
Vercel is the clearest example, because it writes the second reading down explicitly:
Hobby teams are restricted to non-commercial personal use only. All commercial usage of the platform requires either a Pro or Enterprise plan.
Commercial usage is defined as any Deployment that is used for the purpose of financial gain of anyone involved in any part of the production of the project, including a paid employee or consultant writing the code.
Its list of examples includes "Receiving payment to create, update, or host the site" — the invoice, not the page.
Quoted from Vercel's own fair-use guidelines, read 2026-09-10. That page carries its own "Last updated" date; check it rather than this one.
Two of the four say something; two do not. The difference between the two that do is the interesting part — one asks what the site does, the other asks who paid you.
| Host | Does the free plan mention commercial or client work? | In its own words | Where it says so |
|---|---|---|---|
| Vercel (Hobby) | Yes — and it is about the invoice | "Hobby teams are restricted to non-commercial personal use only." Commercial usage covers "any Deployment that is used for the purpose of financial gain of anyone involved in any part of the production of the project, including a paid employee or consultant writing the code" | Fair Use Guidelines → Commercial usage |
| GitHub Pages | Yes — but it is about the site | "GitHub Pages is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)." | GitHub Pages limits → Usage limits |
| Netlify | No such clause found in its Acceptable Use Policy | The restrictions there are behavioural rather than commercial — the closest is "Any user deemed to be using Netlify Services solely as a remote storage server will have their account immediately terminated" | Acceptable Use Policy |
| Cloudflare Pages | No such clause found in the Developer Platform service-specific terms | Those terms are about content and abuse, not about who pays: "Unlike most Cloudflare products, the Developer Platform can be used to host content." | Service-Specific Terms → Cloudflare Developer Platform |
Checked against each vendor's own pages on 2026-09-10. Everyone sets their own terms — check the vendor's site for what's current. For Netlify and Cloudflare, "no such clause found" means exactly that: we read the pages linked above and did not find one. It is not a promise on their behalf, and it is not the same as a page that says client work is welcome.
Read the two "yes" rows next to each other and the practical rule falls out. On GitHub Pages, a client's brochure site is fine and a client's checkout is not. On Vercel Hobby, the brochure site is already commercial — because you were paid to build it. Same project, same page, opposite answers, and neither policy is being unreasonable. They are simply drawing the line around different things.
Our own row is short enough to write out here, because it is the one we can quote without going anywhere.
miinideck. The acceptable-use section restricts what a page contains: nothing unlawful, fraudulent or deceptive, no phishing or credential-harvesting forms, no malware, nothing infringing someone else's rights, nothing defamatory or harassing, and no attempts to disrupt or circumvent the service's limits. There is no clause about who is paying you. The free tier's constraints are the ones on the plan page — its size ceiling, the 7-day default expiry, the single always-on link, and the footer on shared links — and the terms describe those as part of the free offering rather than defects. Client work is a use we designed for, which is a statement about our own posture and not a comparison with anyone else's.
Not what people picture. The mental image is usually degradation — the site gets slow, or throttled, or a banner appears. That is what running out of capacity looks like.
Running out of permission looks like an account action instead. Ours is the one we can quote: content can be removed, a link can be disabled, an account can be suspended or terminated, and where the risk is judged immediate that can happen without prior notice. We mean that about abuse rather than about invoices — but it is worth reading as a shape, because a hosting policy has very few instruments and they all act on the account rather than on the page's speed.
The four policies above bear that out — every instrument they name acts on the account or the content, not on the page's speed. GitHub's phrasing is the gentlest: exceed its limits and "we may not be able to serve your site, or you may receive a polite email from GitHub Support" suggesting a CDN or "moving to a different hosting service that might better fit your needs." Vercel's is a plan requirement rather than a removal — commercial usage "requires either a Pro or Enterprise plan" — and it says that "where possible, we'll reach out before taking action." Netlify's one hard-edged clause promises immediate termination and permanent file removal. Cloudflare's says content "may be blocked or removed," accounts may be suspended or terminated, and while it generally tries to give notice it "reserve[s] the right to take action without notice as appropriate." (All four read on 2026-09-10.)
The practical consequence is the one that matters to you: the failure lands on your client's site, and your client finds out at the same time you do. A capacity problem is an upgrade you can do at 2am. A policy problem is a conversation.
If the answer for your situation is "a paid plan, and a cheap one", the ladder here is short and the free tier's limits are written down rather than discovered.
Three situations. They are genuinely different and they have different answers.
1. A one-off delivery. You finished the work, the client needs to open it, and the site's real home will be somewhere else — their hosting, their IT department, a platform they already pay for. The link is a delivery mechanism, not a deployment. This is the lowest-risk case by a distance, and it is worth being deliberate about keeping it that way: a link that expires on its own cannot quietly turn into six months of you hosting a production site for free.
2. A site you keep running. The client has no hosting, you said you would "just put it somewhere", and eighteen months later you are the host. This is the case the policies are written about, and it is also the case where the risk compounds — the longer it runs, the more it looks exactly like the thing being described. Either move it onto something the client pays for in their own name, or move it onto a paid plan in yours and put it on the invoice. Both are cheap. Discovering the problem when the site goes down is not.
3. There is money or advertising on the page. A checkout, a payment link, ad units, an affiliate arrangement. This is the reading of "commercial" that everyone agrees on, so there is nothing to interpret. Assume a free tier is not for it unless the host explicitly says otherwise.
For the wider question of which host suits which job in the first place — before terms enter the picture at all — the twelve-way comparison covers the field, and GitHub Pages vs a private link covers the specific fork between publishing a site and delivering one.
This is not legal advice, and it is not a substitute for reading the terms of the host you actually use. Terms change, they change without announcement, and a policy summary written by somebody else — including this one — is a snapshot of a document that has a newer version.
What it is meant to do is move the question from the wrong place to the right one. Not will the free tier cope, which you will find out gently. But what does this host's own policy say about being paid for this, which you will find out all at once.
Every list of free HTML hosts assumes you'll sign up. If you won't, the field narrows to a handful — and each one charges you for it in a different currency. Which hosts genuinely need no account, what you give up, and when signing up is the cheaper trade.
When the page is a folder rather than one file, the hosting question changes and so do the ways it breaks. Which free hosts take a ZIP, what happens to your folder structure once they unpack it, and the four failure modes that account for almost every broken zipped site.
Claude Code wrote the file. Now a teammate or a client has to see it working — and the obvious options each solve a different half of that. An honest split across GitHub Pages, Notion, paste-style hosts, an internal server, plain email, and a private link, judged against the five things people actually ask for.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.