Today we are launching Workers Cache : a tiered cache that sits in front of your Worker, configured by a single line of Wrangler config and the same Cache-Control headers you already know. When Workers Cache is enabled, every cacheable request to your Worker hits Cloudflare's cache first. If there's a fresh cached response, Cloudflare returns it directly — your Worker doesn't run, and you don't pay CPU time for it.
On a miss, your Worker runs, and if your response is cacheable, Cloudflare stores it for the next request. The next request from anywhere on Earth can be served straight from cache. The whole thing is one config block: { "name": "my-worker", "main": "src/index.
ts", "compatibility_date": "2026-05-01", "cache": { "enabled": true } } After that, you control caching the way HTTP has always wanted you to — by setting headers on your responses: return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123", }, }); And when content changes, your Worker purges its own cache: await ctx.
cache. purge({ tags: ["product:123"] }); That's the whole API. There is no zone to configure, no rules engine to set up, no separate cache to provision, and no second product to log into.
The Worker's code is the configuration surface, and the cache follows the Worker wherever it runs — on a custom domain, on workers. dev , behind a service binding, in a preview, in a Workers for Platforms tenant. One Worker, one cache, configured once.
That's the surface area. There’s a lot underneath: tiered caching across our entire network, full support for stale-while-revalidate so stale responses never block a user, content negotiation via Vary , multi-tenant-safe cache keys via ctx. props , programmatic purges by tag or path prefix, and — the part we think is the biggest unlock — a cache that sits in front of every Worker entrypoint, not just the public one, with per-entrypoint control over which ones cache and which don't.
That last piece means you can compose caching directly into the structure of your app: a chain of entrypoints with cache stages slotted in wherever you want them, configured by the code on either side. We'll walk through all of it below. Workers Cache is available today to every Worker on any plan, enabled in Wrangler.
This is the caching API we've always wanted Workers to have. Here's why it took us this long, what becomes possible because of it, and what's coming next. Why server-rendered apps need a cache in front When we introduced Workers in 2017 , the pitch was that you could run code on Cloudflare's network to transform requests on their way to your origin.
The Worker sat in front of the cache and the origin: This was the right model for the use cases we were targeting. If you wanted to add a header to every request, rewrite a URL, do an A/B split, or filter traffic before it reached your origin, putting the Worker in front of the cache and the origin gave you full control over what got cached and what didn't. Customers built incredible things with it.
But the world changed. Workers stopped being a thing you bolted onto an origin and started being the origin. Frameworks like Astro , TanStack Start , Next.
js , Remix , and SvelteKit all ship a Cloudflare adapter that builds your app as a Worker. There's no origin behind them. The Worker is the server.
When the Worker is the origin, the original architecture has nothing to cache. Every request runs your code, even when the response would be byte-for-byte identical to the one you returned a second ago. The Workers runtime is fast enough that this works — it routinely handles tens of millions of requests per second without breaking a sweat — but "fast enough to render every request" still costs you latency on every page load and CPU time on every invocation.
And on a server-rendered app, every page load is, by definition, a render. Workers Cache flips the architecture. Cloudflare's cache now sits in front of the Worker: On a cache hit, your Worker doesn't run at all.
Cloudflare returns the cached response and your CPU billing stays at zero. On a miss, your Worker runs once, populates the cache, and the next request — from anywhere — gets served from cache without invoking your code. This is what was missing for server-side rendering on Workers.
You used to have to choose between two unsatisfying options: Prerender everything at build time ("static site generation"). Fast page loads, but every change requires a full rebuild and redeploy. For a docs site with a few thousand pages, that's 5–10 minutes.
For a large e-commerce site, it's worse — and the build runs every single time you touch anything. Render every page on every request. Up-to-date content, but every page load pays the rendering cost and every visitor pays the latency.
Workers Cache gives you a third option: server-render on demand, cache the rendered response, refresh it on a time-to-live ( TTL ) you choose. The first request to a new page still renders. Every subsequent request, until the cache expires, is served as if the page were static.
When the cache expires, the next request triggers a re-render — and with stale-while-revalidate , even that one doesn't wait. You get the speed of a static site without the build time, and the freshness of server rendering without the cost. No framework-specific machinery like Incremental Static Regeneration.
Just HTTP caching, working the way it was designed to work, in front of code that was designed to be the origin. stale-while-revalidate is the part that makes it feel instant The stale-while-revalidate directive tells Cloudflare that when a cached response expires, it's allowed to serve the stale copy immediately while it refreshes the response in the background .
Cloudflare shipped full support for stale-while-revalidate earlier this year , and it's the directive that turns "we cache your Worker" into "your Worker's site feels static."
Originally published at blog.cloudflare.com
