01The limits nobody should quote from memory
Pages publishes usage quotas, and those numbers move often enough that any page reprinting them from memory will eventually be wrong, which is worse than useless when you are making a hosting decision. Their documentation is the current source; go read the numbers there. The pillar page holds the managed side of this comparison.
What this page can do honestly is sort the limits into two kinds, because they behave differently. One kind gets adjusted and argued about in forums. The other kind is structural, comes from what the platform is for, and does not budge.
02Quotas change; categories do not
| Kind of limit | What it covers | What to do about it |
|---|---|---|
| Documented quotas | Repository and published-site size, bandwidth and build allowances, as the Pages documentation currently prints them | Check the docs when the decision is being made, not before |
| Serving model | Built for public static sites; serving a private repository requires a paid GitHub plan | Decide whether code privacy is part of your requirement |
| Operational surface | Rollback means reverting commits; DNS and certificates are yours to watch; forms need a third party | Decide who is on the hook when publishing misbehaves |
| Runtime | Static only, by design; application code is out of scope | Match the platform to the site, not to the wishlist |
Only the first row is a quota. The rest are design decisions GitHub is entitled to and honest about; treating them as bugs misreads the product.
03The structural limits worth planning around
The quota row is what forums argue about. The other rows are what actually move a project off Pages, usually in this order: the code needs to be private, a contact form needs a backend, a broken deploy needs undoing by someone who is not calm, or the owner needs a human to email. None of those are failures of Pages. They are the edges of a free public host doing exactly what it was designed to do.
If your project never touches those edges, the quota row will probably never matter either, and the alternative guide is a short read that ends with the words stay put.
04How the managed side handles the same pressure
Row by row, since that is the fair way: private repositories are the standard case here, a contact-form endpoint is included, rollback is one click across numbered releases rather than a revert commit, and support is an email to a person rather than a forum thread. Australian serving settles the location question for local audiences.
Two rows we do not solve either, and pretending otherwise would be a bad look: hosting here is static only, and quotas do not vanish, they are just priced into a plan rather than printed in a table. The static versus WordPress comparison holds both platforms to the same honesty about the runtime boundary.
05Limit questions, answered plainly
So is Pages unlimited?
No host is. Quotas exist and their documentation is the source. For most hobby and documentation sites the practical answer is that the quotas never come up.
Will a traffic spike take my LoomWeb site down?
We do not publish a quota table either, which will look evasive to some readers. The plain answer is that the $39 plan is priced for ordinary business sites, and an unusual plan deserves an email before the spike rather than after.
What actually moves people off Pages?
In practice: privacy, forms, rollback under pressure, support. The operational rows, rarely the quotas.
Is static-only a limit here too?
Yes, and it is one we keep on purpose. No PHP and no databases on either side of this comparison; the boundary is the product category, not the vendor.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.