Cloudflare just flipped the caching model for Workers. Until now, your Worker always ran first — you were responsible for writing responses into the Cache API, managing TTLs in code, and accepting that the ephemeral, data-center-local cache would miss more than it hit. Workers Cache, launched July 6, 2026, sits in front of your entrypoints as a two-tier regional cache. On a hit, Cloudflare returns the cached response directly. Your Worker does not execute. CPU is not billed. For server-rendered apps on Workers, this changes the economics entirely.
What Workers Cache Actually Is (and Is Not)
Workers already had a Cache API — caches.default.put(), caches.default.match() — which let you manually store and retrieve responses. If you have used it, you know the friction: it is ephemeral, local to the data center where the Worker ran, does not replicate across the network, and requires you to write all the caching logic yourself. Workers Cache is fundamentally different.
Workers Cache operates as an automatic, global, two-tier cache that runs in front of your Worker. No new APIs to call. No manual entry management. Everything is controlled through standard HTTP headers: Cache-Control, Vary, Cache-Tag. The configuration surface is your Worker’s response headers — headers you are already writing.
The two-tier architecture matters. There is a lower tier at the data center nearest to the user and an upper tier aggregating across Cloudflare’s network. The first request for a given cache key anywhere on Earth populates the upper tier. Every subsequent request from any Cloudflare data center is served from the upper tier without running your Worker. Hit ratios are dramatically higher than a flat single-layer cache. Add request collapsing — where concurrent cold-start requests execute the Worker once and fan the response to all waiting clients — and you have a caching model that actually scales under load.
Getting Started: Five Minutes to Your First Cache Hit
Enable Workers Cache with a single addition to your wrangler.jsonc. Requires Wrangler 4.69.0+:
{
"name": "my-worker",
"cache": {
"enabled": true
}
}Then control caching behavior directly from your Worker’s response headers:
return new Response(renderedHtml, {
headers: {
"Cache-Control": "public, max-age=300, stale-while-revalidate=3600",
"Cache-Tag": "blog,post:slug-123"
}
});That is it. max-age=300 caches the response fresh for five minutes. stale-while-revalidate=3600 keeps serving the stale version for up to an hour while the cache refreshes in the background. Cache-Tag enables programmatic purging by tag.
Every response includes a Cf-Cache-Status header so you can see what happened: HIT means no Worker execution, MISS means the Worker ran and the result is now cached, UPDATING means a stale response was served while the background refresh runs, and BYPASS means the cache was skipped — typically because the response set a cookie or the request carried an Authorization header.
Why Stale-While-Revalidate Makes This Production-Grade
Without stale-while-revalidate, cached SSR responses have a structural problem: the first request after the TTL expires causes a latency spike. A user hitting second 301 of a 300-second TTL experiences full render time. That is not materially better than no caching.
With stale-while-revalidate, the expired response is served immediately with Cf-Cache-Status: UPDATING while the Worker runs asynchronously in the background to refresh the cache. The user gets the fast response. The cache gets refreshed. No one waits on a render.
This is what turns “we cache your Worker” into “your Worker’s app feels fully static.” A short max-age (60 seconds) paired with a long stale-while-revalidate (one hour) gives you content that refreshes quickly when the cache is warm while never blocking a user on a re-render. That is the pattern most SSR apps should use by default.
Per-Entrypoint Control: Cache the Backend, Skip the Gateway
If your Worker uses multiple entrypoints — an auth gateway and a data-fetching backend, for example — you can configure caching per entrypoint. This is where Workers Cache becomes genuinely powerful for layered architectures:
{
"cache": { "enabled": true },
"exports": {
"default": { "type": "worker", "cache": { "enabled": false } },
"DataBackend": { "type": "worker", "cache": { "enabled": true } }
}
}The auth gateway runs uncached — requests are user-specific, nothing to cache. The data backend caches aggressively — same product catalog for thousands of users. Wire them together with service bindings and you have a gateway pattern where authentication always runs fresh but expensive data fetches are served from cache globally.
Multi-Tenant Safety
If you are building on Workers for Platforms — or any multi-tenant architecture — the cache key automatically incorporates ctx.props values. Set the tenant identifier in ctx.props and different tenants receive isolated cached responses. One tenant’s data cannot appear in another’s cache entry. This is automatic; no custom cache key logic required.
The Billing Picture
Cache hits do not bill CPU time. That is the core value proposition — you are paying request rates instead of compute rates for repeat traffic. The savings scale linearly with your hit ratio.
The caveat worth knowing: requests that are normally free — Worker-to-Worker invocations via service bindings, static asset requests — are billed at the standard request rate when Workers Cache is enabled. If you have high-volume, zero-cost internal traffic, enabling global caching on those routes could introduce unexpected request charges. Use per-entrypoint configuration to enable caching selectively rather than globally.
Workers Cache vs. Your Other Options
| Option | Replication | SWR Support | Auto-managed | Best For |
|---|---|---|---|---|
| Workers Cache | Global, 2-tier | Yes | Yes | SSR pages, API responses |
| Cache API | Local only | No | Manual | Legacy code, ephemeral use |
| Workers KV | Global | No | Manual | Config, sessions, feature flags |
| R2 | Global | No | Manual | Static assets, large files |
Workers Cache does not replace Workers KV or R2 — they solve different problems. Workers Cache is the answer to “how do I cache dynamic HTTP responses without managing a cache store.” KV is the answer to “how do I store and read structured data at low latency from Workers.”
Who Should Enable This Today
If you are running any server-rendered framework — Astro (which Cloudflare acquired in January 2026), Next.js via OpenNext, or Remix — on Workers, and you handle more than a few thousand requests per day, Workers Cache is a straightforward win. Enable it, set a Cache-Control header on your rendered responses, and your CPU bill drops proportionally to your cache hit ratio. Add stale-while-revalidate and perceived latency becomes static-site-fast for the majority of users.
If you are building APIs where responses are user-specific or session-dependent, be more deliberate. The automatic Set-Cookie and Authorization bypasses handle the common cases, but review your response shapes to confirm you are not accidentally caching user-specific data. The full configuration reference covers the complete bypass logic and how to override it safely.
Workers Cache is the caching model Workers should have had from the start. It is available now on all paid Workers plans.
