GitHub Pages is where most developers host their first site, and for good reason: it's free for public repos, it lives next to your code, and it hasn't meaningfully changed in over a decade — which, for a static host, is a feature. If you're publishing docs or a personal site from a public repository, you probably don't need this article.
But Pages has a well-defined ceiling. It serves static files only — no server-side code, no databases. GitHub documents soft limits on site size, bandwidth, and builds per hour, and its terms explicitly say Pages isn't meant for commercial transactional sites ([usage limits](https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits)). Builds beyond Jekyll mean writing your own Actions workflow, and Pages for private repos requires a paid GitHub plan.
So here's the field in 2026, tested with the bias of someone who deploys things for a living. Each entry gets what it's genuinely good at, what to watch for, and a one-line verdict.
1. Cloudflare Pages / Workers
What it is: Static hosting on Cloudflare's edge network, with Workers for anything dynamic. Cloudflare has been steadily consolidating Pages into the Workers platform — their docs now steer new projects toward Workers with static assets ([Cloudflare Pages docs](https://developers.cloudflare.com/pages/)).
What it does well: The network. Your files sit on one of the largest edge networks in the world, and Cloudflare famously doesn't meter bandwidth for static assets on its free tier. If you expect a traffic spike — a launch, a Hacker News front page — this is the calmest place to be standing. Workers, KV, R2, and D1 give you a real (if idiosyncratic) path to dynamic functionality.
Watch for: The dynamic path means learning the Workers runtime, which is not Node.js — some npm packages won't run. The Pages-to-Workers transition also means the docs and product surface have been shifting; check what's current before wiring up CI.
Best for: High-traffic static sites where bandwidth is the main worry, and teams already in the Cloudflare ecosystem.
2. Netlify
What it is: The platform that invented the modern git-push static workflow, now a broader frontend cloud. ([Netlify docs](https://docs.netlify.com/))
What it does well: Developer experience around *previews*. Every pull request gets its own deploy URL, and the redirect/headers/forms primitives (_redirects, netlify.toml) are mature and well-documented. Serverless functions are a first-class add-on when a site needs a bit of backend. It's the most polished pure-frontend workflow of the bunch.
Watch for: The free tier has bandwidth and build-minute allowances, and overages on paid plans are usage-based ([pricing](https://www.netlify.com/pricing/)) — a traffic spike on a media-heavy site is worth modeling before it happens. Anything database-shaped still lives on another platform.
Best for: Frontend teams whose review process runs on deploy previews.
3. Vercel
What it is: The company behind Next.js, hosting Next.js (and other frameworks) the way its authors intended. ([Vercel docs](https://vercel.com/docs))
What it does well: If you use Next.js, nothing else matches the integration — ISR, image optimization, edge middleware, and server components all work exactly as the framework docs describe, because it's the same company. Preview deployments are excellent. The free Hobby tier is genuinely useful for personal projects.
Watch for: The Hobby tier is licensed for personal, non-commercial use ([pricing](https://vercel.com/pricing)) — a commercial site means a paid seat from day one. And the further you drift from Next.js, the more ordinary the platform becomes; you're paying a premium for framework alignment you may not be using.
Best for: Next.js apps, full stop.
4. GitLab Pages
What it is: GitHub Pages' closest sibling — static hosting attached to your GitLab repos, built via GitLab CI. ([GitLab Pages docs](https://docs.gitlab.com/ee/user/project/pages/))
What it does well: It fixes two specific GitHub Pages complaints. Any static site generator works out of the box — the build is just a CI job you define, no Jekyll assumption — and access control is available, so you can restrict a site to project members. If your code is on GitLab (especially self-hosted), it's the obvious default.
Watch for: It inherits the same architectural ceiling as GitHub Pages: static only, no databases, no server-side execution. You're choosing it for repo proximity, not capability.
Best for: Teams already on GitLab, especially self-managed instances with internal docs.
5. Render
What it is: A general-purpose PaaS — web services, background workers, managed Postgres — that also does free static sites with a global CDN. ([Render static sites](https://render.com/docs/static-sites))
What it does well: The static offering is a clean on-ramp to a full platform: when your site needs an API, the backend deploys next to it instead of on a second provider. Render's docs are consistently good, and the Heroku-refugee migration path is well trodden. Free static sites include a bandwidth allowance with usage-based overage.
Watch for: Free web services (the dynamic kind) spin down after inactivity, so the "add a backend" step comes with cold starts until you pay. Databases on the free tier have expiration constraints worth reading before you rely on one.
Best for: Static-plus-API projects that want a mainstream, well-documented PaaS.
6. PandaStack
Our own entry — judge accordingly, but the facts are checkable.
What it is: An all-in-one developer cloud: static sites, container apps, managed databases (PostgreSQL, MySQL, MongoDB, Redis), cronjobs, and edge functions behind one git-push workflow.
What it does well: The static story is framework-agnostic — React/Vite, Astro, Gatsby, Eleventy, VitePress, Hugo, Next.js static export all auto-detect and build, with live build logs. The differentiating part is what happens when the site stops being static: you add a container app in the same project and attach a managed database, and DATABASE_URL is injected automatically — no copying credentials between a host, a database vendor, and a secrets manager. The free tier covers 5 static sites, 5 container services, 1 database, 100 GB bandwidth, and 300 build minutes a month; paid plans are flat ($15/mo Pro, $25/mo Premium) rather than usage-metered surprise bills.
Watch for: We're newer than everyone else on this list, and the ecosystem shows it — fewer third-party tutorials, smaller community. Free-tier container apps scale to zero when idle, so the first request after a quiet period eats a cold start, and free databases get a small storage volume suited to dev and hobby work, not heavy production.
Best for: Projects that will outgrow "static" — where a database and backend are a matter of when, not if.
The short version
| Platform | Best for |
|---|---|
| GitHub Pages | Open-source docs in public repos |
| Cloudflare | Traffic spikes; bandwidth-heavy static sites |
| Netlify | PR-preview-driven frontend teams |
| Vercel | Next.js |
| GitLab Pages | GitLab shops, internal docs |
| Render | Static + API on a mainstream PaaS |
| PandaStack | Static now, full app soon |
Don't overthink a pure docs site — Pages, GitLab Pages, or Cloudflare will all serve it well and free. The decision only gets interesting when there's a backend on the roadmap, because that's when "static host plus function provider plus database vendor" turns into three dashboards and three bills. If you'd rather see the one-platform version of that, push a repo to https://pandastack.io and watch what it does.