Cloudflare's Workers Cache puts a tiered cache in front of every Worker

Cloudflare has launched Workers Cache, which places a tiered, network-wide cache in front of a Worker and is turned on with a single Wrangler config line. Caching behavior is driven entirely by standard HTTP semantics — Cache-Control and Cache-Tag headers on responses — with programmatic invalidation through a purge call keyed by tag or path prefix. On a cache hit the Worker never executes, so there’s no CPU billing; on a miss it runs once, populates the cache, and subsequent requests from anywhere are served without invoking the code. There’s no zone setup, rules engine, or separate cache product to provision, and the cache travels with the Worker across custom domains, workers.dev, service bindings, previews, and Workers for Platforms tenants.

The feature addresses a shift in how Workers are used. The 2017 model put a Worker in front of the origin and cache to transform requests, but framework adapters for Astro, Next.js, Remix, SvelteKit, and TanStack Start now make the Worker itself the origin, leaving nothing behind it to cache. That meant every request re-rendered the page. Workers Cache inverts the arrangement, offering a middle path between build-time static generation (fast but requiring full rebuilds on every change) and rendering on every request (fresh but slow and costly): render on demand, cache the result, and refresh on a chosen TTL.

The piece Cloudflare highlights as the biggest unlock is full stale-while-revalidate support, which serves an expired response immediately (flagged with Cf-Cache-Status: UPDATING) while a background refresh runs, so no user waits on a re-render. Other capabilities include Vary-based content negotiation, multi-tenant-safe cache keys via ctx.props, and — notably — caching in front of every Worker entrypoint, not just the public one, with per-entrypoint control so caching can be composed into the app’s structure. It’s available today on all plans.