Cloudflare sends new projects to Workers; static sites stay free
Pages stays supported while feature work goes to Workers; static hosting stays free after a move, but only domains on Cloudflare's nameservers can follow.
The short read
Cloudflare's own docs now tell new projects to start on Workers, not Pages.
- Pages keeps running, but Cloudflare's feature work now goes to Workers.
- Static files stay free on Workers, but a custom domain can only move if Cloudflare runs its DNS.
What you can do with this
If you start a site now, create it as a Worker, not a Pages project. Static hosting stays free, and you skip a migration later.
Cloudflare’s documentation for Pages, its hosting product for static sites and frontends, now tells readers to use something else. The Pages overview says Workers “supports most Pages use cases and offers a broader feature set” and ends: “Start new projects with Workers.” A site on Pages keeps running. New features go to Workers, and moving does not change what static hosting costs.
Cloudflare set this course in April 2025. It said then that Pages “will continue to be supported”, but “all of our investment, optimizations, and feature work will be dedicated to improving Workers.” Now the advice sits on the Pages docs themselves, and the migration guides page opens it with “Are you sure you want to use Pages?” Neither page gives Pages an end date.
Workers now does what Pages was built for
A Worker can host a static site on its own. The files deploy with the Worker, and a request that matches a file is served without running any Worker code.
The price is the same. Cloudflare’s pricing page says requests to static assets “are free and unlimited”. Pages Functions “are charged at the same rate as Workers”, says the migration guide. The limits match as well: 20,000 files on the free plan, 100,000 on paid plans and 25 MiB per file, for both Workers and Pages.
Workers has more features and one real gap
The guide’s compatibility matrix marks Cron Triggers, Queue consumers, Workers Logs, rate limiting and gradual deployments as Workers-only. Durable Objects, which on Pages need a separate Worker to bind to, work directly.
Some things get harder. Branch deploy controls are less configurable on Workers, and file-based routing from a functions/ folder has to be compiled with Wrangler first.
The real gap is DNS. “Unlike Pages, Workers does not support any domain whose nameservers are not managed by Cloudflare,” the guide says. If your domain’s DNS sits with your registrar, moving means moving DNS to Cloudflare first, or staying on Pages.
Moving is mostly configuration
Most of the work happens in the Wrangler config file. The Pages setting pages_build_output_dir becomes assets.directory. Pages guessed your 404 behavior from index.html and 404.html; Workers wants not_found_handling set to single-page-application or 404-page, “to prevent accidental misconfiguration”. Locally, wrangler pages dev becomes wrangler dev, and the port moves from 8788 to 8787.
One change can catch you out. Pages ran Functions before static assets by default, while Workers “will default to serving static assets ahead of your Worker script.” If your code checks logins or logs requests before a file is served, set assets.run_worker_first.
That setting has a cost. Requests that match it “will always invoke your Worker script”, so they are billed. The free plan allows 100,000 requests a day, and past that those requests get a 429 error “instead of falling back to static asset serving.”
Cloudflare’s Astro post talks about Workers
On January 16, 2026 Cloudflare announced that the company behind Astro is joining it. The post describes local development running in “workerd, the open-source Cloudflare Workers runtime” and never mentions Pages. Cloudflare and Astro both say the framework stays MIT-licensed and keeps supporting other hosts. Disclosure: this site is built with Astro and hosted on Cloudflare.
What to do now
- Start new projects on Workers. That is where Cloudflare says its feature work goes.
- Check your nameservers before planning a move. If Cloudflare does not run your domain’s DNS, your custom domain cannot follow you to Workers.
- Search the repository for
_routes.jsonand middleware. The guide says to review the request order if you used either. Decide whether you needrun_worker_first, and count the billed requests it adds. - Run the Worker beside the Pages site. Connect it to Workers Builds, set
preview_urlstotrueand test on a preview link. Then turn off automatic deployments on the Pages project, add your domain to the Worker, and delete the Pages project last withnpx wrangler pages project delete. - Update templates and internal docs that still say “deploy to Pages”.
Nothing on either page forces an existing site to move. Move it when you need something on the Workers-only list, and start the next one on Workers.
Sources
- Cloudflare Pages overview, Cloudflare Docs
- Pages migration guides, Cloudflare Docs
- Migrate from Pages to Workers, Cloudflare Docs
- Full-stack development on Workers, Cloudflare blog, April 8, 2025
- Workers static assets and billing and limitations, Cloudflare Docs
- Workers pricing and Workers limits, Cloudflare Docs
- Pages limits, Cloudflare Docs
- Astro is joining Cloudflare, Cloudflare blog, January 16, 2026
- The Astro Technology Company joins Cloudflare, Astro blog, January 16, 2026