Cloudflare Pages is Cloudflare’s frontend hosting platform that deploys static sites and modern frontend applications to Cloudflare’s global edge network. Launched in 2020 as Cloudflare’s answer to Netlify and Vercel, Pages provides Git-based continuous deployment, automatic preview environments for every pull request, global delivery from Cloudflare’s 337 cities worldwide, automatic HTTPS, and integration with Cloudflare’s broader services. As of 2026, Pages is in the middle of a strategic transition that’s worth understanding before adopting the platform: Cloudflare is folding Pages into its Workers serverless platform, and since April 2025 its published guidance has been that new projects should start with Workers, with all investment and feature work going there. Pages remains operational and supported for existing projects, but the strategic direction for Cloudflare’s developer platform is clearly Workers rather than Pages, and teams choosing a frontend platform in 2026 should weigh that direction in their decision.
This post covers what Cloudflare Pages actually is, the 2026 transition story (why Cloudflare is consolidating Pages into Workers and what that means for users), the relationship between Pages and the broader Workers serverless platform, the framework support, the pricing model that’s now shared between Pages and Workers, the strengths and constraints of the Cloudflare frontend platform, and the practical considerations for teams evaluating Pages or thinking about the eventual Workers migration. For context on the broader frontend cloud landscape, our What Is Vercel? and What Is Netlify? pillars cover the adjacent platforms.
What Cloudflare Pages actually is
Cloudflare Pages is the deployment platform for static sites and modern frontend applications running on Cloudflare’s edge network. The basic flow: connect a Git repository, configure the build command and output directory, and every push triggers an automatic build and deployment. Built sites serve from Cloudflare’s 337 cities worldwide with sub-second response times worldwide. Custom domains attach with automatic SSL. Preview environments deploy automatically for every pull request.
The pieces Cloudflare Pages provides as of mid-2026:
Git-based continuous deployment. GitHub, GitLab, and direct Git push integration. Every push to main triggers a production deployment; every push to a branch triggers a preview deployment with its own URL.
Global edge delivery. Cloudflare’s 337 cities worldwide serve every Pages site from the location closest to each user. Performance is consistently excellent worldwide because the edge footprint is genuinely global.
Preview deployments. Pull request previews with their own URLs that mirror the production build. Reviewers see the actual rendered site rather than approving code blindly.
Automatic HTTPS. SSL certificates are managed automatically for both pages.dev subdomains and custom domains.
Build configuration. The Pages dashboard handles build commands, output directories, environment variables, framework presets, and the various configuration knobs that frontend projects need.
Functions (the Pages-specific serverless layer). Pages Functions run server-side code alongside the frontend, written in JavaScript, TypeScript, Python or any language that compiles to WebAssembly and deployed via the same Git workflow. The Functions integration is one of the features that’s been actively unified with the broader Workers platform.
Cloudflare integration. Pages sites can use the broader Cloudflare service catalog: Workers KV for key-value storage, R2 for object storage, D1 for SQL database, Workers AI for AI inference, and the rest of Cloudflare’s developer platform.
For broader frontend architectural context, our Vercel pillar covers Next.js-aligned frontend cloud patterns and our Netlify pillar covers the original Jamstack platform.
The Pages-to-Workers transition
The most consequential thing to understand about Cloudflare Pages in 2026 is that Cloudflare is in the process of consolidating Pages into Workers, with Workers as the strategic direction.
The reasons behind the consolidation:
Workers was already a serverless platform; Pages was hosting plus some Workers-style serverless features. The overlap was substantial and getting larger as Pages Functions matured. Maintaining two distinct platforms with overlapping capabilities was operationally inefficient for Cloudflare.
Workers has been the more capable platform. Pages was built for static hosting first with serverless added later; Workers was built for serverless compute first with static hosting added more recently. The Workers feature surface has consistently been broader.
New developer-platform features have been shipping to Workers. Workflows, Containers, Dynamic Workers, the Secrets Store and advanced Observability are Workers features rather than Pages features. Durable Objects are a partial exception worth stating precisely: Pages Functions can bind to an existing Durable Object, but you cannot create and deploy one inside a Pages project. The new-feature gap has widened over time.
Migration paths are clear and increasingly automated. Cloudflare has documented migration patterns from Pages to Workers and provides tooling to assist the transition. The migration is generally not difficult for typical projects.
The current state as of August 2026:
Workers now covers static assets and server-side rendering, and Cloudflare says to start there. Its guidance since April 2025 is explicit: "Now that Workers supports both serving static assets and server-side rendering, you should start with Workers," and "all of our investment, optimizations, and feature work will be dedicated to improving Workers." Parity is not complete, though, and one gap matters: per Cloudflare’s own migration guide, "Unlike Pages, Workers does not support any domain whose nameservers are not managed by Cloudflare." Early Hints, file-based routing and Pages Plugins are also partial or absent, and Workers does not natively separate production from non-production bindings.
New features ship to Workers first or only. Secrets Store, Workflows, Containers and Dynamic Workers are Workers-only. Cloudflare’s product roadmap going forward is Workers-shaped.
Pages is still operational and supported. Existing Pages projects continue working without changes. Cloudflare hasn’t announced an EOL date for Pages and continues to support the platform for current users.
Migration is encouraged but not forced. New projects should generally choose Workers. Existing Pages projects can migrate when convenient but aren’t required to migrate immediately.
The practical takeaway for teams considering Cloudflare’s frontend platform: in 2026, you’re choosing Workers as your platform, even if you start on Pages. The Pages branding is a present-day deployment surface; the Workers platform is the strategic destination. Teams that adopt Pages in 2026 should plan for an eventual Workers migration, even if that migration doesn’t happen for months or years.
The Workers serverless platform
Since Workers is the strategic destination, understanding the broader Workers platform matters for the Pages decision:
Cloudflare Workers is a serverless execution platform that runs JavaScript and TypeScript at Cloudflare’s edge network. Functions deploy to all 337 cities worldwide and execute in V8 isolates (not containers or VMs), which Cloudflare says start "around a hundred times faster than a Node process on a container or virtual machine".
Workers KV is a globally-replicated key-value store for low-latency reads at the edge. Good for configuration, session data, and read-heavy patterns where eventual consistency is acceptable.
R2 is S3-compatible object storage without egress fees. The no-egress pricing is a substantial differentiation from AWS S3 for bandwidth-heavy workloads (media delivery, file downloads, dataset hosting).
D1 is Cloudflare’s SQLite-based serverless SQL database. Strong for applications that need relational queries with edge-deployment patterns.
Durable Objects are stateful serverless primitives that maintain state across requests. Good for coordination, websocket connections, and stateful patterns that traditional stateless serverless can’t easily handle.
Workers AI runs AI inference on Cloudflare’s edge, with various open-source models available alongside paid premium models. The inference happens at the edge, which means low latency and good cost characteristics for AI-enhanced applications.
Queues provides message queuing for asynchronous workflows.
Workflows orchestrates long-running serverless tasks with durable execution patterns.
Containers runs container-based workloads alongside V8 isolates for workloads that need more than the isolate model provides.
The composition: Workers becomes a comprehensive developer platform that goes substantially beyond what Pages alone provided. For teams that adopted Pages for static hosting and then needed serverless compute, KV storage, object storage, or any of the other adjacent capabilities, the Workers platform consolidation is good news. The story becomes "deploy to one platform with one configuration model" rather than "deploy to Pages and integrate with Workers, KV, R2, and others."
Framework support
Cloudflare Pages (and Workers) support the major modern frontend frameworks. The first-class integrations include Next.js, Astro, SvelteKit, Nuxt, Remix, Gatsby, Eleventy, Hugo, and Vite-based projects, plus any static-site generator that produces a build output Cloudflare can serve.
Next.js specifically has had some friction historically because Next.js features (ISR, streaming, certain App Router patterns) were originally built around Vercel’s specific runtime. Cloudflare’s Next.js support has matured substantially through 2024-2026, and OpenNext (an open-source adapter) provides a path for deploying Next.js to Cloudflare with reasonable feature coverage. For Next.js projects, the integration depth still trails Vercel’s, but it’s now reasonable for most use cases.
Astro, SvelteKit, Nuxt, Remix all have good Cloudflare support. The frameworks generally treat Cloudflare as a first-class deployment target with documented adapters and patterns.
Static-site generators without complex SSR requirements (Hugo, Eleventy, Jekyll, Gatsby in static mode) deploy cleanly with minimal configuration.
For most modern frontend projects, Cloudflare Pages (or Workers) is a reasonable deployment target. The framework support is broad and the integration patterns are well-documented.
Pricing in 2026
Cloudflare’s Pages and Workers pricing is now shared between the two products as part of the consolidation:
Free. Workers Free provides 100,000 requests per day with 10ms CPU time per request. Pages Free provides unlimited static requests and unlimited bandwidth with 500 builds per month. Most static sites and many serverless workloads fit within free tier allowances.
Paid ($5/month for Workers). The Workers paid plan covers 10 million requests and 30 million CPU-milliseconds of compute per month, then charges $0.30 per additional million requests and $0.02 per additional million CPU-milliseconds. Build quota is a separate axis: it tracks your Cloudflare zone plan, not your Workers plan. Free gives 500 builds a month with one concurrent build, Pro gives 5,000 with five, and Business gives 20,000 with twenty. Cloudflare Pro is $20 a month billed annually or $25 monthly, so "$5 a month" does not buy 5,000 builds.
Usage-based overages. Beyond the paid tier allowances, usage bills per-unit. Workers requests beyond the included allowance bill at small per-million rates. KV reads, R2 storage and reads, D1 queries, Workers AI inference all bill separately at per-unit rates.
Enterprise. Custom pricing with dedicated support, compliance certifications, custom contracts, and the procurement processes enterprise customers expect.
The honest pricing reality: Cloudflare’s developer platform pricing is among the most affordable in the industry, particularly for projects that fit within the substantial free tier or the $5/month paid base. R2’s no-egress pricing is genuinely differentiated for bandwidth-heavy workloads. The total cost depends on usage patterns but is typically lower than equivalent Vercel or AWS Amplify deployments for the same workloads.
Strengths and constraints
The Cloudflare frontend platform strengths in 2026:
Edge footprint. Cloudflare’s network reaches 337 cities across more than 100 countries, among the largest in the category. Performance is consistently excellent worldwide.
Pricing. Affordable across the tier range. R2’s no-egress model is a meaningful cost advantage for bandwidth-heavy workloads.
Workers platform breadth. Workers AI, R2, D1, KV, Durable Objects, Workflows, Containers, Queues compose into an integrated developer platform that’s substantial. Teams that pair frontend hosting with serverless backend services get a coherent platform rather than a multi-vendor integration.
Strong fast cold starts. V8 isolates avoid the container and virtual-machine startup cost entirely. For applications that prioritize consistent fast response times, this matters substantially.
No egress fees on R2. Genuinely differentiated against AWS S3 for media, downloads, and bandwidth-heavy workloads.
The constraints worth knowing:
Next.js integration depth. Still trails Vercel for the most Next.js-specific features. For projects deeply invested in Next.js patterns, Vercel often provides a more polished experience.
Pages-to-Workers transition timing. The current transition state introduces some friction. Teams adopting Cloudflare’s platform in 2026 should plan for an eventual Workers migration even if they start on Pages.
Documentation can lag the consolidation. Some documentation references the Pages-Workers boundary in ways that don’t fully reflect the consolidated platform direction. Verifying current capabilities against the latest documentation is worth doing.
Smaller framework ecosystem outside Workers. Workers-specific patterns (Durable Objects, KV) require framework integrations that are less mature than the broader Node.js ecosystem provides on other platforms.
What teams considering Cloudflare’s frontend platform should think about
Six concrete considerations:
- Treat the choice as “Workers” rather than “Pages.” Even if you start on Pages, plan for Workers as the destination. New projects should generally start on Workers directly given the strategic direction Cloudflare has committed to.
- Validate the framework integration depth for your specific stack. Most modern frameworks deploy cleanly, but Next.js specifically may need OpenNext or similar adapters depending on which Next.js features you use. Run a small project to verify the integration meets your needs.
- Evaluate the broader developer platform. The strongest argument for Cloudflare in 2026 isn’t Pages-versus-Vercel or Pages-versus-Netlify on hosting alone; it’s the integrated platform spanning Workers AI, R2, D1, KV, Durable Objects, and the rest. If you would otherwise integrate multiple vendors for these capabilities, Cloudflare’s unified platform has real value.
- Model the cost honestly. Cloudflare’s pricing is genuinely affordable for most workloads, but the per-feature billing across Workers requests, KV reads, R2 storage, D1 queries, and AI inference can require some modeling for complex applications. Verify cost expectations before committing to scale.
- Plan for the Pages-to-Workers transition timeline. If you adopt Pages now, document the eventual Workers migration plan. The migration isn’t urgent, but it’s worth thinking through before it becomes operationally pressing.
- Consider Cloudflare’s broader edge story. Beyond the frontend platform, Cloudflare’s services (CDN, DDoS protection, DNS, Zero Trust, etc.) are widely used. If you’re already on Cloudflare for some services, adding the developer platform consolidates vendor relationships.
The deeper takeaway is that Cloudflare’s frontend platform in 2026 is in the middle of an important strategic consolidation. Pages remains operational, but Workers is the destination. For teams choosing a frontend platform today, the relevant decision is whether to adopt Workers (including its hosting capability) as the platform, with Pages as a present-day deployment surface that will likely consolidate fully into Workers over the coming years. For teams already on Pages, the migration to Workers is a future task to plan for rather than an immediate emergency.
Frequently Asked Questions
What is Cloudflare Pages?
Cloudflare Pages is Cloudflare’s frontend hosting platform that deploys static sites and modern frontend applications to Cloudflare’s global edge network of 337 cities worldwide. Launched in 2020, Pages provides Git-based continuous deployment, automatic preview environments for pull requests, custom domains with automatic HTTPS, and integration with Cloudflare’s broader services (Workers, KV, R2, D1, Workers AI). As of 2026, Cloudflare is consolidating Pages into the Workers serverless platform, with Workers as the strategic direction for new features.
Why is Cloudflare folding Pages into Workers?
The two platforms have substantial overlap. Workers was originally a serverless compute platform; Pages was static hosting plus some Workers-style serverless features. The overlap grew as Pages Functions matured, and Workers’ broader capability surface (Durable Objects, KV, R2, D1, Workers AI, Workflows, Containers) made it the more strategically positioned platform. Cloudflare announced the consolidation direction in April 2025, saying that now Workers supports both static assets and server-side rendering you should start with Workers, and that all investment and feature work would go to Workers. Parity is not complete: Workers does not support domains whose nameservers Cloudflare does not manage, and Early Hints, file-based routing and Pages Plugins are partial or absent. Pages is not deprecated and still ships changes, but new platform features go to Workers first or only.
Should I use Pages or Workers in 2026?
For new projects, Cloudflare’s recommended path is Workers directly. For existing Pages projects, migration is encouraged but not required immediately. Pages remains operational and supported. The strategic direction is Workers, so teams adopting Cloudflare’s frontend platform in 2026 should plan for Workers as the destination even if they temporarily start on Pages. Cloudflare provides migration tooling and documentation for the Pages-to-Workers transition.
What does Cloudflare’s developer platform cost?
Free tier provides 100,000 Workers requests per day with 10ms CPU each on Workers Free, and unlimited static requests and bandwidth with 500 builds per month on Pages Free. The Workers paid tier is $5 a month, including 10 million requests and 30 million CPU-milliseconds. Build quota is separate and follows your Cloudflare zone plan: 5,000 builds a month requires Cloudflare Pro at $20 annually or $25 monthly. Usage-based overages apply for Workers requests, KV reads, R2 storage, D1 queries, and Workers AI inference beyond the included allowances. R2’s no-egress pricing model is differentiated against AWS S3 and similar object stores for bandwidth-heavy workloads. Enterprise tier has custom pricing.
How does Cloudflare’s edge network compare to Vercel and Netlify?
Cloudflare’s edge footprint of 337 cities worldwide globally is the largest in the category. Vercel’s edge runs on a smaller but still global network; Netlify’s CDN is also global but smaller still. For most applications, the difference in edge footprint doesn’t produce noticeable performance differences because all three platforms have meaningful global presence. For workloads where the largest possible edge presence matters specifically (very latency-sensitive applications, applications in regions where Vercel or Netlify have less coverage), Cloudflare’s footprint can be a real advantage.
What frameworks does Cloudflare support?
The major modern frontend frameworks all have Cloudflare support: Next.js, Astro, SvelteKit, Nuxt, Remix, Gatsby, Eleventy, Hugo, Vite-based projects, and most static-site generators. Next.js specifically has had some historical friction because Next.js features were originally built around Vercel’s runtime; the open-source OpenNext adapter and Cloudflare’s matured Next.js support have improved this, but Next.js integration depth still trails Vercel’s. For Astro, SvelteKit, Nuxt, and Remix, Cloudflare integration is generally polished and well-documented.
What is Cloudflare Workers AI?
Workers AI is Cloudflare’s AI inference platform that runs AI models on Cloudflare’s edge network. Available models include open-source LLMs (Llama, Mistral, Gemma, and others), open-source image models, embedding models, and speech models, plus paid premium models. Inference happens at the edge close to users, which produces low latency and reasonable cost characteristics for AI-enhanced applications. For frontend applications integrating AI features (semantic search, content generation, image processing), Workers AI provides a competitive option without requiring teams to operate AI infrastructure themselves.
Is Cloudflare Pages suitable for enterprise projects?
Yes, with the caveat that the platform direction is Workers and enterprise customers should plan for that. Cloudflare Enterprise customers include substantial brands across various industries, and the compliance certifications, custom contracts, and dedicated support that enterprise procurement expects are available. The combination of Cloudflare’s broader service portfolio (CDN, DDoS protection, DNS, Zero Trust security) plus the developer platform makes Cloudflare an interesting consolidation play for enterprises that would otherwise integrate multiple vendors for these capabilities.
