Workers

Standalone Cloudflare Workers and Wrangler configuration

Cloudflare Workers are serverless functions that run at the edge. They can be standalone services or part of a Pages project (as Pages Functions).

Workers vs Pages Functions

When to Use Standalone Workers

Use standalone Workers when:

• The function is a separate service (e.g., search worker, AI chat worker)

• You need custom domains or routing

• The worker has its own release cycle independent of the static site

• You need features not available in Pages Functions

In This Section

• Wrangler Config -- Configuration file format and options

• Standalone Workers -- Deploying independent Workers

• Compatibility Dates -- Understanding and managing compatibility dates

• Durable Objects -- WebSocket Hibernation and SQLite-backed Durable Objects

• Static Assets -- the [assets] binding, run_worker_first, and the preview-URL trap

• Browser Caching for Hashed Assets -- the _headers immutable rule for content-hashed bundles, 103 Early Hints, and why full CSS inlining is the wrong fix

• Deploy from Zero -- provisioning a repo-based Worker from scratch and its non-obvious traps

• Local Dev: Binding Support Matrix -- which bindings emulate locally in wrangler dev, and the credential-free e2e config pattern

• Runtime Gotchas -- self-fetch hostnames, stored fetch responses, waitUntil/scheduled budgets, binding-wrapping libraries, the cloudflare:workers ambient env, and CORS vs WebSocket

• Pages to Workers Migration -- moving a live site from Pages to Workers Static Assets with minimal downtime, and rolling back cleanly if it doesn't go well

• Workers Cache (ctx.cache) -- the edge-level cache.enabled / ctx.cache feature -- version floor, Cache-Control/Cache-Tag/Vary, ctx.cache.purge scoping, Cf-Cache-Status, the Next.js ISR question, and why verification only works against a deployed Worker