Cloudflare offers several distinct products that are easy to conflate: Pages, Workers, and (more recently) Workers with static Assets. Understanding the difference matters when deciding how to deploy a small site or product, because the wrong choice adds either unnecessary complexity or an artificial ceiling on what the deployment can do.
Cloudflare Pages
Pages is built for static output: HTML, CSS, JavaScript, and other assets produced by a build
step (like vite build), deployed to Cloudflare's edge network and served directly
from cache at the nearest location to a visitor. There is no server-side code running per
request beyond routing and header rules — which is exactly right for a company site, a
documentation site, or any project where content doesn't need to be computed per request.
Cloudflare Workers
Workers run actual JavaScript/TypeScript (or WASM) code at the edge, per request. This is where you'd put an API endpoint, a redirect that depends on request data, authentication logic, or anything that needs to read a database, call another service, or branch based on the request itself rather than serving the same file to everyone.
Workers with static Assets
More recently, Cloudflare unified these models: a Worker project can also serve a directory of
static assets directly (configured via an assets block pointing at a build output
directory), with the option to fall back to Worker code for anything the static assets don't
match — including a custom 404 page or dynamic routes. This is the same underlying
infrastructure as Pages, exposed through the Workers configuration format.
How to decide
- Purely static content (a company site, a docs site, a marketing page) → static hosting is sufficient. No Worker logic needed.
- Static content plus a handful of dynamic behaviors (a contact form endpoint, an auth callback, a custom 404) → static hosting with a Worker attached for just those routes.
- An API-first product (a backend that many clients call) → a Worker (or Worker with Durable Objects / D1 / KV as needed) is the primary deployment target, with static assets as a secondary concern if any.
A concrete example: custom error pages
A common need is a branded 404 page instead of a generic host error. With static asset hosting,
this is typically handled by placing a 404.html file in the build output and
configuring "not found" handling to serve it, rather than writing Worker code just to return a
different HTML string. Reaching for a full Worker for something this simple adds a maintenance
surface — a deployable script, a set of routes, error handling — for a problem a plain static
file solves.
Why this distinction matters for cost and reliability
Static assets served from cache are cheap, fast, and have no server-side failure mode beyond the CDN itself. Worker code, by contrast, can fail, time out, or have bugs, because it's running logic on every request. Keeping as much of a project static as genuinely possible, and reserving Worker code for the parts that actually need computation, is usually the more reliable and lower-maintenance choice for a small team.
Related reading: Security headers and CSP on Cloudflare Pages and Choosing a stack for small independent teams.