Need a partner to implement or migrate?
This page gives you an honest read on where Cloudflare fits as a hosting platform. If you’re rethinking the hosting layer of a whole web estate, start at Hosting & delivery — and if you want a team to plan and run the move, see Website migration.
What happened to Cloudflare Pages
If you’re evaluating Cloudflare Pages in 2026, evaluate Workers instead.
Pages was Cloudflare’s answer to Netlify and Vercel: connect a Git repository, get builds, preview deployments per branch, instant rollbacks, and delivery from Cloudflare’s global network. It still works, and Cloudflare has said existing projects stay supported and keep receiving bug fixes. What changed is where the investment goes. Once Workers gained the ability to serve static assets and render server-side, Cloudflare’s own guidance became to start new projects on Workers — and the new capabilities have followed it there: Durable Objects, Cron Triggers, Queue consumers, gradual deployments, proper observability, Tail Workers, remote development, the Vite plugin. Pages gets support and bug fixes. Workers gets the roadmap.
That matters for planning, not just for tooling choices. Any Pages-era comparison you read — including a lot of what still ranks for “Cloudflare Pages vs …” — is describing a product that is no longer the one Cloudflare wants you to build on. Treat Cloudflare hosting as Workers with static assets and the picture gets much clearer.
What Cloudflare hosting is now
A Worker is a small piece of JavaScript or WebAssembly running in a V8 isolate in Cloudflare’s network of data centres, with near-zero cold starts. With static assets, one Worker serves your built site’s files and handles the dynamic paths — server rendering, personalisation, redirect logic, API routes — in a single deployment. Requests for static assets aren’t charged.
Around that sit the storage and platform primitives you’d otherwise assemble: KV for edge-read configuration, R2 for object storage with no egress fees, D1 for SQLite, Durable Objects for coordinated state, Queues, Hyperdrive for pooling connections to an existing Postgres, plus Images, Vectorize, and Workers AI. Frameworks reach the platform through adapters — Astro, SvelteKit, Nuxt and Remix are well served, and Next.js runs via the OpenNext Cloudflare adapter rather than first-party support.
Where Cloudflare fits
- You’re already a Cloudflare customer. This is the most common and most underrated reason. If DNS, WAF, DDoS protection, bot management, or Zero Trust already sit in your contract, hosting the site on the same network means one vendor, one security review, and procurement work you’ve already done. For a large organisation that alone can outweigh a feature comparison.
- Bandwidth is a real line item. Cloudflare doesn’t meter standard delivery egress, and R2 doesn’t charge for it either. On a high-traffic content estate — or a media-heavy one — that changes the arithmetic against every usage-billed competitor.
- The site needs logic at the edge. Geo and locale routing, consent handling, A/B splits, header rewrites, and — this is the migration case — large redirect maps. A replatform typically carries thousands of legacy URLs; running that map in a Worker in front of the origin is fast, cheap, and easy to audit. We do this even for estates hosted elsewhere.
- Your team is comfortable owning the platform. Wrangler configuration, adapters, caching rules, and bindings are normal work here, not an exception.
Where it doesn’t
Next.js estates that need first-party behaviour. OpenNext is a genuine achievement and it is still an adapter. ISR, image optimisation, and middleware are where adapter and first-party support diverge, and they’re precisely the features a large marketing site leans on. If the estate is Next.js and framework fidelity is the priority, that’s Vercel.
Preview-driven stakeholder review. Preview deployments exist, but the collaboration layer around them — the commenting, the review flow marketing teams actually use to sign off on a page — is thinner than on Vercel or Netlify. If the review workflow is the reason you’re buying a platform, this isn’t the platform.
Teams without engineering ownership. Cloudflare’s price advantage is real, and part of what you’re not paying for is defaults. Someone on your side has to make the routing, caching, and adapter decisions. If nobody owns that, the saving turns into an incident.
Moving an existing Pages project
It’s usually a configuration migration rather than a rewrite: a wrangler.jsonc with an assets binding, the build output pointed at it, environment variables and bindings re-declared, and your custom domains re-attached. Budget review time for the genuine gaps rather than the mechanics — Pages Functions’ file-based routing has to be expressed in the Worker or the framework adapter, native Early Hints and Pages’ branch-deploy controls don’t carry over, and custom domains that sit outside a Cloudflare zone aren’t supported on Workers. Migrate on your own schedule; there’s no forced deadline, and doing it alongside a framework upgrade or a replatform is cheaper than doing it twice.
When teams choose it — and when they don’t
| Choose Cloudflare when | Look elsewhere when |
|---|---|
 Cloudflare is already in your contract for DNS, CDN, or security — consolidation is worth real money |  The estate is Next.js and you want framework features working as designed on release day |
| Traffic and bandwidth are high enough that no-egress-metering changes the total cost | Preview-and-comment review is how your marketing organisation signs off on pages |
| You have a team that will own adapters, wrangler config, and caching as normal work | Nobody in-house wants to own platform decisions — you're buying defaults, not a network |
| The dynamic work fits the Workers model: routing, personalisation, redirects, light rendering | You need long-running services, heavy background jobs, or a conventional server tier |
Pricing, in plain terms
Workers has a free tier, and paid usage starts at a few dollars per account per month plus metered requests and CPU time — with static-asset requests free and no egress metering on standard delivery. Storage products (KV, R2, D1, Durable Objects) are priced separately and modestly. Enterprise contracts exist for the compliance, support, and network-tier items, and typically bundle the security products alongside delivery.
The growth-cost drivers to watch: dynamic request volume and CPU time per request (static delivery barely moves the bill), storage and operations across KV/R2/D1, and any of the security or Zero Trust products you add. Compared with per-seat-plus-usage platforms, Cloudflare is the low-cost outlier in this category by some distance — the honest counterweight is that the cost moves from an invoice into your team’s time. Current details are on Cloudflare’s Workers pricing page.
The Bejamas take
Cloudflare is in front of a lot of the estates we run, whether or not it hosts them — DNS, WAF, and redirect logic at the edge with the application behind it is a perfectly good architecture, and often the right first step. We put the whole front end on Workers when two things are true: the traffic makes the economics matter, and there’s a team on the client side who wants to own the platform layer. When the deciding factor is workflow rather than network, we say so and recommend Vercel or Netlify instead. For the head-to-head, read Cloudflare vs Vercel. In an audit we price all three against your real traffic and your existing contracts — including the Cloudflare spend you may already have.