Your Worker can now have its own cache in front of it

概要

公開日: 2026-07-06 翻訳生成に失敗したため、原文をそのまま保存しています。

原文

Your Worker can now have its own cache in front of it 2026-07-06 Dan Lapid Connor Harwood 17 min read 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 wit