Cloudflare has released Workers Cache, a feature that places a tiered cache directly in front of a Cloudflare Worker. When a request arrives and a fresh cached response exists, Cloudflare returns it without executing the Worker at all, meaning no CPU time is consumed and no billing is incurred for that invocation. On a cache miss, the Worker runs normally, and if the response is cacheable, Cloudflare stores it for subsequent requests worldwide.
How it is configured
Enabling Workers Cache requires a single block in the Wrangler configuration file, setting cache.enabled to true. From that point, caching behavior is controlled entirely by standard HTTP response headers set inside the Worker itself, including Cache-Control directives such as max-age and stale-while-revalidate, as well as Cache-Tag headers for granular purging. Programmatic cache purging is handled through a new ctx.cache.purge() call that accepts tag names or path prefixes.
There is no separate dashboard product to configure, no zone-level rules engine, and no additional provisioning step. The cache follows the Worker across custom domains, the workers.dev subdomain, service bindings, previews, and Workers for Platforms tenants.
Why this matters for server-rendered frameworks
When Cloudflare introduced Workers in 2017, the intended model placed the Worker in front of a separate origin, with Cloudflare’s cache sitting between the Worker and the origin. That architecture worked well for request transformation tasks. As frameworks such as Next.js, Astro, Remix, SvelteKit, and TanStack Start began shipping Cloudflare adapters that compile an entire application into a Worker, the Worker became the origin itself, and there was nothing left to cache at the network edge.
Workers Cache inverts the architecture: the cache now sits in front of the Worker rather than behind it. This gives server-side-rendered applications a third path between full static site generation (fast but requiring a full rebuild on every change) and rendering every request on demand (always fresh but always paying rendering latency and CPU cost).
With Workers Cache, the first request to a given URL triggers a render and populates the cache. Every subsequent request within the configured TTL is served from cache at zero CPU cost. When the TTL expires, the stale-while-revalidate directive allows Cloudflare to serve the stale copy immediately while refreshing the response in the background, so no visitor waits on a re-render.
Additional capabilities
- Per-entrypoint control: The cache can be placed in front of any Worker entrypoint, not just the public-facing one, allowing caching to be composed into multi-stage service binding chains.
- Content negotiation: Full support for the
Varyheader. - Multi-tenant cache keys: Isolated cache namespacing per tenant through
ctx.props, relevant to Workers for Platforms deployments. - Tag and prefix purging: Targeted cache invalidation without purging unrelated content.
Workers Cache is available today to all Workers users on any plan and is enabled through Wrangler.