THE CYBER TOOLCHAIN
Cloudflare Blog is an official publication sharing updates, technical insights, and announcements about Cloudflare's internet security, performance, and networking products and services.
Cloudflare Workers Cache adds a tiered cache in front of Workers, configured via Wrangler and standard Cache-Control headers.
└──▷ USE IT
Enable Workers Cache for a Worker so Cloudflare's cache layer handles repeat requests before your code runs, eliminating CPUCPUThe main general-purpose processor in a computer. It runs application instructions and coordinates work with memory and other hardware. cost on cache hits.
{
"name": "my-worker",
"main": "src/index.ts",
"compatibility_date": "2026-05-01",
"cache": {
"enabled": true
}
}
Serve a server-rendered page at cache speed for most visitors while keeping content fresh — fresh for 5 min, stale-served for up to 1 hour while background revalidation runs.
return new Response(html, {
headers: {
"Content-Type": "text/html; charset=utf-8",
"Cache-Control": "public, max-age=300, stale-while-revalidate=3600",
},
});
Purge cached entries for a specific product after an inventory update, without touching any other Worker's or zone's cached content.
await ctx.cache.purge({ tags: ["product:123"] });
- New Workers Cache: a tiered cache that sits in front of a Worker, enabled with a single
cache.enabledblock inwrangler.toml, so cacheable requests never invoke Worker code or incur CPU billing. - Supports
stale-while-revalidate— stale responses are served instantly while the Worker re-renders in the background, so no user ever waits on a cache refresh. - Supports standard Vary header for content negotiation, storing separate cache variants per distinct header combination (e.g., Accept, Accept-Language) with no allowlist restrictions.
- New ctx.cache.purge() API enables Workers to programmatically purge their own cache by tag (
tags: ["product:123"]), path prefix, or everything — scoped to the Worker entrypoint, not the zone. - Cache follows the Worker, not the hostname — a single Worker's cache is shared across custom domains,
workers.dev, service bindings, preview URLs, and Workers for Platforms tenants.
+2 more show less
- Per-entrypoint cache control: Workers for Platforms tenants each get an isolated cache; preview deployments each get their own cache partition, preventing test traffic from polluting production.
- Multi-tenant-safe cache keys via
ctx.propsallow shaping the cache key programmatically without zone-level Cache Rules or Page Rules.
7 details in Everything
Was this useful?