Should you still start a new project on Cloudflare Pages? No. Cloudflare's own documentation now tells you to build on Workers instead. Pages still runs, but new features and optimizations are going to Workers only, and the command-line tool defaults to Workers unless you force it otherwise.
The short version
- Cloudflare's docs now say it plainly: start new projects on Workers, not Pages. Pages keeps working, but new features and optimizations are focused on Workers.
- The create-cloudflare command-line interface (CLI) defaults to Workers. You have to pass --platform=pages to get a Pages project at all.
- Workers Static Assets serves static sites for free, the same as Pages, and adds Durable Objects, Cron Triggers, and deeper observability on top.
- Two gotchas will bite you: Workers only supports custom domains whose nameservers are managed by Cloudflare, and server-rendered apps generally need the paid plan.
- If you already run on Pages, there is no fire drill. Migrate on your own schedule. For most framework apps the path is short.
What Cloudflare actually changed
Cloudflare did not deprecate Pages, but it stopped recommending it. Every Pages documentation page now opens with the line "Are you sure you want to use Pages?" followed by a pointer to the Workers migration guide, and Cloudflare's Workers best practices page states it directly: "If you are starting a new project, use Workers instead of Pages. Pages continues to work, but new features and optimizations are focused on Workers."
The tooling moved with the guidance. Cloudflare's C3 CLI, the npm create cloudflare command most people use to scaffold a project, now creates a Workers project by default. As the docs put it, "To create a Pages project you must now specify the --platform=pages arg, otherwise C3 will always create a Workers project." The Pages-to-Workers migration guide was last updated on October 12, 2026, and it reads less like a side note and more like a recommended destination.
So this is not a rumor or a community reading of the tea leaves. It is Cloudflare telling you, in its own primary documentation, where to point new work.
Why this matters if you are picking a stack for next year
This is Q4. If you run a B2B software-as-a-service (SaaS) web team or an agency, this is the quarter you lock the platform decisions you will live with through next year. I have spent part of this year evaluating Cloudflare as a primary alternative to Vercel for client builds, and this change settles a question that used to require a judgment call.
Six months ago, "Pages or Workers" was a real fork. Pages was the simpler on-ramp for a static or framework site, and Workers was where you went when you needed compute. That fork is closing. Workers Static Assets now covers the static and framework cases that used to be Pages' whole reason to exist, which means the default answer for a new 2027 build is Workers, full stop. Choosing Pages now means choosing the platform that will not get the next round of features.
For agencies this has a practical edge. Pages caps you at 100 projects per account, a limit Cloudflare says is "not routinely increased." Workers allows up to 500 on paid plans. If you host a stable of client sites, the platform Cloudflare is steering you toward is also the one that scales to your client list.
What you get on Workers that Pages never had
The headline is that nothing gets worse on the basics. Per Cloudflare's migration guide, requests for static assets on Workers are free, the same as Pages, and Pages Functions invocations are billed at the same rate as Workers, "so you can expect a similar cost structure." You are not trading cost for capability.
What you gain is the rest of the Workers platform. The migration guide calls out "a distinctly broader set of features," including Durable Objects for stateful coordination, Cron Triggers for scheduled jobs, and more comprehensive observability. In practice that means the thing you would have bolted on later, a scheduled revalidation job, a rate limiter with shared state, real request logs, is already native to the platform you started on. You stop architecting around the gap.
When I stand up a new marketing site for a professional-services client, the work that used to live in a second system, a cron job on some other host, a queue for form handling, now sits next to the site itself. Fewer moving parts is not a slogan. It is one less vendor invoice and one less thing to explain in a handoff document.
The two gotchas that will bite you
This is the part most "just use Workers" posts skip, so here is the honest version.
First, custom domains. Cloudflare's migration guide is explicit: "Unlike Pages, Workers does not support any domain whose nameservers are not managed by Cloudflare." Pages tolerated domains with external DNS. Workers does not. If your enterprise keeps DNS on a corporate provider or a registrar you do not control, you need to sort that out before you commit, because it is a hard stop, not a warning.
Second, server-side rendering. Per Cloudflare's Vercel-to-Workers guide, "SSR applications usually need the Workers Paid plan, because the Free plan allows 10 ms of CPU time per request." Server-side rendering (SSR) is the model behind most modern framework apps, so if you were planning to run a dynamic site on the free tier, budget for the paid plan instead. In the same note, Cloudflare warns that native Node.js modules such as sharp and canvas do not run on Workers, and runtime writes to the file system fail. If your build leans on image processing at runtime or writes temp files, test that path early rather than discovering it in production.
Neither of these is a dealbreaker. Both are the kind of thing that turns a one-day migration into a one-week migration if you find them late.
If you already run on Pages
Do not panic-migrate. Pages continues to work, and Cloudflare has not announced an end-of-life date. The right posture is to migrate deliberately, not reactively.
The mechanics are straightforward for most framework apps. Per the guide, most popular frameworks already ship Workers adapters, so you swap the Pages adapter for the Workers one, add a Wrangler configuration file if you do not have one, and point your static assets at the build output. Cloudflare even publishes an experimental AI migration prompt you can hand to a coding assistant to do the conversion. Once you have validated behavior and moved production traffic, you delete the old Pages project. If you are weighing a platform move as part of a larger rebuild, I walk through how I sequence that work in my replatform checklist.
The one thing I would not do is start a brand-new project on Pages in November 2026 because it is familiar. Familiar is how teams end up maintaining the deprecated path.
What this does not cover
This is a platform-direction piece, not a line-by-line pricing analysis. I have not modeled Workers Paid costs against your specific traffic, compared Cloudflare feature-for-feature against Vercel and Netlify, or covered Workers for Platforms, which is the right answer only if you are hosting a very large number of sites. It also does not cover enterprise contract terms, which are their own conversation. Treat this as the "which door do I walk through for a new build" decision, not the full procurement spreadsheet.
FAQ
Is Cloudflare Pages being shut down?
No. Cloudflare's documentation says Pages "continues to work," and there is no announced end-of-life date. What changed is that new features and optimizations now go to Workers, and Cloudflare recommends Workers for all new projects. Pages is a maintained platform, not a growing one.
Can I still create a Cloudflare Pages project?
Yes, but you have to ask for it. The create-cloudflare CLI now defaults to Workers, and per the docs you must pass --platform=pages explicitly, "otherwise C3 will always create a Workers project."
Does moving from Pages to Workers cost more?
Not inherently. Cloudflare states that static asset requests are free on both and that Pages Functions invocations are billed at the same rate as Workers, so the cost structure is similar. The exception is server-side rendering, which usually requires the Workers Paid plan because the free plan caps CPU time at 10 milliseconds per request.
What is the biggest migration risk?
Custom domains. Workers only supports domains whose nameservers are managed by Cloudflare, while Pages allowed external DNS. If your DNS lives elsewhere, resolve that before you migrate, because it is a hard requirement rather than a recommendation.
Should I migrate my existing Pages site right now?
Only on your own schedule. There is no urgency, since Pages still runs. The urgency is the other direction: do not start new projects on Pages. For existing sites, migrate when you have a rebuild, a feature need that only Workers covers, or capacity to test the custom-domain and SSR paths properly.
If you are choosing a hosting platform for a build you will ship in 2027 and want a second set of eyes before you commit, book a 20-minute stack review and I will tell you where Workers fits and where it will fight you.