Cloudflare Pages had one of the best pitches in static hosting: push to Git, get your site on Cloudflare's global network, and don't think about bandwidth. That pitch still holds. But the ground under Pages has shifted — Cloudflare's own documentation now points new projects toward [Workers with static assets](https://developers.cloudflare.com/workers/static-assets/) instead, and Pages sits in a strange in-between state: fully supported, but clearly not where the investment is going. If you're picking a platform in 2026, or reconsidering one, it's worth knowing what else is out there.
What Cloudflare Pages genuinely does well
Credit where due, because a lot of it is real:
- The network. Your static assets are served from Cloudflare's edge, which is about as globally distributed as it gets. Latency for static content is excellent almost everywhere on Earth.
- Bandwidth economics. Static asset delivery on Pages isn't metered the way most platforms meter it. For a high-traffic content site, this alone can be the deciding factor.
- Git integration and preview deployments. Every branch gets a preview URL. The workflow is clean and it's been stable for years.
- The Cloudflare ecosystem. If you're already using Cloudflare DNS, WAF, and R2, Pages slots in with zero friction.
Why people look elsewhere
The reasons are structural, not bugs:
The Workers convergence. Cloudflare has publicly consolidated on Workers as the platform for new full-stack projects — the [migration guide from Pages to Workers](https://developers.cloudflare.com/pages/migrations/migrating-to-workers/) is written by Cloudflare, about Cloudflare. Pages isn't deprecated, but when a vendor writes you an exit guide to their other product, you should read the room.
Server-side code means the Workers runtime. Pages Functions run on workerd, not Node.js. There's a [Node compatibility layer](https://developers.cloudflare.com/workers/runtime-apis/nodejs/), and it has improved a lot, but it is not Node — some npm packages, native modules, and long-running patterns simply don't fit. If your "static site" grows an API that needs real Node or Python, you're rebuilding, not extending.
The data story is Cloudflare-shaped. D1 is SQLite at the edge, KV is eventual-consistency key-value, R2 is object storage. All good tools — none of them is a managed PostgreSQL with connection pooling, backups, and an ORM-friendly connection string. Hyperdrive can front an external Postgres, but now you're running a database somewhere else anyway.
Builds are capped. The free plan limits how many builds you can run per month (see [Pages limits](https://developers.cloudflare.com/pages/platform/limits/)). Teams that deploy on every commit across several projects do hit this.
The alternatives
Netlify
The platform that made "Jamstack" a word, and still one of the most polished Git-based workflows around. Deploy previews, instant rollbacks, redirects and headers as config files, form handling, and serverless functions that run on real AWS Lambda under the hood. The [docs](https://docs.netlify.com/) are mature and the ecosystem of build plugins is the deepest in the category. Has a free tier; costs scale with usage and seats beyond it. The honest limitation is the same one Pages has: it's fundamentally a frontend platform, and a real backend (a database, a worker, a container) means adding another vendor.
Best for: marketing sites, documentation, and frontend teams who want the most battle-tested static workflow available.
Vercel
If you deploy Next.js, Vercel is the path of least resistance — they build the framework, and features land there first. Preview deployments are excellent, the edge network is fast, and the DX is genuinely best-in-class for React-centric teams. See [vercel.com/docs](https://vercel.com/docs). Has a free hobby tier; pricing is usage-based and can climb with traffic and function invocations. Like Netlify, databases and heavier backends are integrations rather than first-party primitives, and the platform's center of gravity is unmistakably Next.js.
Best for: Next.js applications and teams already committed to the Vercel-flavored React stack.
Render
Render started from the opposite end: real backend services first, static hosting alongside. You get static sites, containers, managed Postgres and Redis, cron jobs, and background workers under one roof — [static sites](https://render.com/docs/static-sites) are free to host. The tradeoff people cite most is that free-tier services spin down when idle, and the static CDN, while solid, isn't the scale of Cloudflare's network.
Best for: projects that are already more app than site — where the static frontend is one piece of a larger backend.
PandaStack
Full disclosure: this is us, so calibrate accordingly. PandaStack is an all-in-one developer cloud — static sites, container apps, managed PostgreSQL/MySQL/MongoDB/Redis, cronjobs, and edge functions from a single dashboard. Connect a Git repo and it auto-detects the framework and build commands (Astro, Gatsby, Eleventy, VitePress, plain Vite — we build these daily), streams live build logs, and handles custom domains with automatic SSL. The part that differentiates it from pure static hosts: when your site grows an API, you deploy it as a container next door, attach a managed database, and the DATABASE_URL is injected automatically — no second vendor, no credential copying. The free tier includes 5 static sites, 5 container apps, a database, and 100 GB bandwidth a month; paid plans are $15 and $25/mo flat rather than usage-metered. Honest limitations: we're newer, the ecosystem is smaller than Netlify's or Cloudflare's, and free-tier containers scale to zero when idle (static sites don't have this problem — they're just files).
Best for: sites you expect to become applications — where you'd rather add a backend and a Postgres than add a vendor.
GitHub Pages
The simplest option on this list. Your repo, a branch or an Actions workflow, and a free public site — [docs here](https://docs.github.com/en/pages). No server-side anything, no preview deployments in the platform itself, and it's designed for public projects. But for a docs site, a project page, or a personal blog, it's hard to argue with infrastructure you already have.
Best for: open-source project sites and documentation that lives next to the code.
Firebase Hosting
Google's static and SPA hosting, served from their CDN with one-command deploys via the Firebase CLI — [docs](https://firebase.google.com/docs/hosting). Its real strength is the rest of Firebase: Auth, Firestore, Cloud Functions integrate natively, and rewrites can route paths straight into functions. If you're not using the Firebase ecosystem, though, the hosting alone isn't the draw, and the mental model (Google Cloud billing included) is heavier than a pure static host.
Best for: apps already built on Firebase Auth/Firestore.
Quick comparison
| Platform | Static hosting | Server-side code | Managed relational DB | Best for |
|---|---|---|---|---|
| Cloudflare Pages | Excellent, edge-served | Workers runtime only | No (D1 is SQLite) | Content sites on CF's network |
| Netlify | Excellent | Lambda-backed functions | No (integrations) | Jamstack, frontend teams |
| Vercel | Excellent | Functions, Next-optimized | No (integrations) | Next.js apps |
| Render | Good | Full containers | Yes | Backend-heavy apps |
| PandaStack | Good | Full containers + edge fns | Yes (auto-wired) | Sites growing into apps |
| GitHub Pages | Basic, reliable | None | No | OSS docs and project pages |
| Firebase Hosting | Good | Cloud Functions | Firestore (NoSQL) | Firebase-based apps |
How to choose
If your site is content and will stay content, Cloudflare Pages is still a fine answer in 2026 — the network and the bandwidth story remain unmatched, and "not where the investment is going" is not the same as "going away." Netlify and Vercel win on workflow polish, especially for teams. GitHub Pages wins on simplicity for anything living in a public repo.
The fork in the road is what happens when the site stops being static. If that future involves a real backend and a real database, pick a platform where those are first-class — Render or PandaStack — instead of planning a migration you'll do under deadline pressure later.
If the "site that becomes an app" path sounds like yours, you can see how it feels on https://pandastack.io.