For years the answer to “where do I deploy this on Cloudflare” was simple: static sites and frontends went on Pages, and serverless logic went on Workers. In 2026 that line has blurred, because Workers can now serve static assets directly, which means a single Worker can host your whole site, frontend and backend together. This has changed Cloudflare’s own recommendation for new projects, and it is worth understanding why before you pick a side.
This guide explains what each product is, how the static-assets shift changed the Cloudflare Pages vs Workers decision, and gives a clear recommendation for new builds and for anyone wondering whether to migrate.
TL;DR
- Pages is git-connected hosting for static sites and frontend frameworks, with built-in CI/CD and preview deployments
- Workers is Cloudflare’s serverless compute platform, and it now serves static assets too, so it can host full sites
- For new projects in 2026, Cloudflare recommends Workers with static assets, because it unifies frontend and backend in one deployment
- Pages remains fully supported; there is no need to rush an existing Pages project off it
- Choose based on workflow: Pages for a pure git-push static deploy, Workers for anything that mixes static content with dynamic logic
What Cloudflare Pages Is
Cloudflare Pages is a platform for deploying websites straight from a git repository. You connect a GitHub or GitLab repo, Cloudflare runs your build command, and the output is deployed to the global edge. Every push gets a preview deployment with its own URL, and merging to your production branch updates the live site. It is the classic Jamstack workflow: push code, get a deployed site.
Pages also supports dynamic behaviour through Pages Functions, which are Workers under the hood, so you can add API routes and server-side logic to an otherwise static site. I used exactly this approach to build a complete user registration and login system on Cloudflare Pages , which shows how far a “static” host can stretch.
What Cloudflare Workers Is
Cloudflare Workers is the serverless compute and serverless hosting platform: code that runs on Cloudflare’s network, close to your users, with no servers to manage. Workers started as pure functions for APIs, middleware and edge logic, and they bind to the rest of the platform, R2 , D1 , KV, Queues and Workers AI . If you build on those storage bindings, my free desktop apps make them easy to manage: Easy Cloudflare R2 , Easy Cloudflare D1 and Easy Cloudflare KV .
The key 2026 development is Static Assets. A Worker can now serve a directory of static files (HTML, CSS, JS, images) directly, with the Worker handling any dynamic routes. That means a single Worker can host your built frontend and your API in one deployment, something that previously required splitting work across Pages and Workers.
What Changed for Pages vs Workers: Static Assets
The reason this comparison even matters now is the static-assets capability. Historically, if you had a React or Astro frontend plus a backend API, the natural split was Pages for the frontend and a separate Worker for the API. Two projects, two deployments, two things to wire together.
With static assets on Workers, you deploy once. The Worker serves your static build for normal requests and runs your code for API routes or server-rendered pages. For full-stack frameworks and apps that mix static and dynamic content, this is simpler to build, deploy and reason about. It is why Cloudflare now points new full-stack projects toward Workers rather than Pages.
Pages vs Workers: Side by Side
| Criterion | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| Primary purpose | Git-connected site hosting | Serverless compute + static assets |
| Static hosting | Yes (core feature) | Yes (via static assets) |
| Dynamic/server logic | Pages Functions | Native |
| Git CI/CD + previews | Built in | Via CI integration / Wrangler |
| Bindings (R2, D1, KV, AI) | Yes | Yes, first-class |
| Best for | Pure static/Jamstack sites | Full-stack apps and APIs |
| 2026 recommendation for new builds | Still supported | Preferred |
When to Choose Pages
In the Pages vs Workers decision, Pages is still a great choice when:
- You have a pure static site or a frontend framework build and want the simplest possible git-push deploy workflow
- You value the built-in CI/CD and preview deployments without configuring anything
- Your dynamic needs are light and well served by Pages Functions
- You are already on Pages and it works; there is no penalty for staying
When to Choose Workers
In the Pages vs Workers decision, Workers is the better pick when:
- You are building a full-stack application that mixes static content with significant server-side logic
- You want frontend and backend in a single deployment rather than two coordinated projects
- You lean heavily on bindings such as D1, R2, KV, Queues or Workers AI
- You are starting a new project in 2026 and want to follow Cloudflare’s current recommended path
- You need fine-grained control over routing, caching and request handling
Cloudflare Pages vs Workers: Should You Migrate?
No, not reflexively. If you have a working Pages project, it remains fully supported and there is no deadline forcing a move. Migrate when you have a concrete reason: you are adding substantial backend logic, you want to consolidate a split frontend/backend into one deployment, or you are hitting a Pages-specific limitation that Workers solves.
For greenfield projects in the Pages vs Workers choice, start on Workers with static assets. For an existing, happy Pages deployment, leave it until a real need appears. The worst reason to migrate is novelty; the best reason is unifying a full-stack app you would otherwise have to split.
Key Takeaways
- Pages is git-connected hosting for static and Jamstack sites with built-in CI/CD and previews
- Workers is serverless compute that now also serves static assets, so it can host full sites
- Static Assets is the change that lets a single Worker host frontend and backend together
- For new full-stack projects in 2026, Workers is Cloudflare’s recommended path
- Pages remains fully supported; migrate only when you have a concrete reason
- In the Cloudflare Pages vs Workers decision, pick Pages for pure static simplicity and Workers for anything mixing static content with real logic
Frequently Asked Questions
What is the difference between Cloudflare Pages and Workers? Pages is git-connected hosting for static sites and frontends with built-in CI/CD and preview deployments. Workers is Cloudflare’s serverless compute platform. The line blurred in 2026 because Workers can now serve static assets, letting one Worker host both a frontend and a backend.
Should I use Pages or Workers for a new project in 2026? For most new full-stack projects, Workers with static assets is now Cloudflare’s recommended choice because it unifies frontend and backend in one deployment. For a purely static site where you want the simplest git-push workflow, Pages is still an excellent option.
Is Cloudflare Pages being discontinued? No. Pages remains fully supported. Cloudflare now steers new full-stack projects toward Workers, but existing Pages projects continue to work and there is no forced migration.
Can Workers host a static website? Yes. With the static assets feature, a Worker can serve static files such as HTML, CSS, JS and images directly, while also handling dynamic routes in code. This is what allows a single Worker to host an entire site.
Do Pages and Workers use the same bindings? Both can use Cloudflare bindings such as R2, D1, KV and Workers AI. Pages exposes them through Pages Functions, while Workers treats them as first-class. Functionally you can reach the same platform services from either.
Should I migrate my existing Pages site to Workers? Only if you have a concrete reason, such as adding significant backend logic or consolidating a split frontend and backend into one deployment. A working Pages project is fully supported and does not need to be moved.
Comments