Cloudflare Workers vs Pages: Which One Do You Actually Want?
I finished my first deployment, got a URL, clicked it — and it was something.workers.dev, not the .pages.dev address every guide showed me. I hadn’t done anything obviously wrong. I’d just landed, without realizing it, on the wrong Cloudflare product.
Two Different Tools, Same Company
Cloudflare Pages is built specifically for static websites — sites made of pre-built HTML, CSS, and JavaScript files, like an Astro site with no server-side logic. You connect a GitHub repo, Cloudflare builds it, and it serves the resulting files.
Cloudflare Workers is a platform for running actual server-side code at the edge. It’s genuinely powerful, but it’s solving a different problem than “host my static website.”
For a typical Astro site with no server-side code, Pages is what you want. Workers can technically serve static files too, but it does so by running a full server-side runtime check on every single deploy — overhead your site doesn’t need.
How You End Up on the Wrong One by Accident
Both products live under the same Workers & Pages section of the Cloudflare dashboard, and some setup paths (particularly ones involving a tool called Wrangler) default to Workers even when you built a static site.
The Real Cost of Being on the Wrong One
- Unpredictable deploy failures — Workers mode can re-verify and even regenerate configuration on every deploy, occasionally hitting version mismatches with Cloudflare’s own build tooling
- Extra overhead on every request, which can matter for performance testing
- Confusing routing behavior, since Workers-based routing and Pages-based custom domains work differently under the hood
How to Check Which One You’re On
Look at your project’s sidebar in the Cloudflare dashboard. Durable Objects, Queues, Workflows → you’re on a Workers service. A Pages project’s sidebar looks different, focused on Deployments, Custom domains, Settings.
The Fix
Option A — Migrate to Pages properly. Create a new Pages project pointing at the same GitHub repository.
Option B — Pin your Workers config to skip auto-injection. Committing an explicit wrangler.jsonc configuration that tells Workers to serve your build output as pure static assets removes most of the unpredictable failure modes without requiring a full migration.
The Takeaway
Cloudflare gives you multiple valid paths to “your site is live,” and only one of them is usually what you actually meant to do for a simple static site.