Cloudflare Workers Get a Built-In Cache, No Extra Product Required

What happened

Cloudflare launched Workers Cache, a caching layer built directly into Cloudflare Workers, the serverless functions Cloudflare runs at edge locations close to your users. Before this, caching a Worker’s responses meant configuring a separate rules engine or bolting on another product.

Now it’s one line in your wrangler.jsonc config file, the file that tells Cloudflare how to deploy your Worker:

{
  "name": "my-worker",
  "cache": { "enabled": true }
}

Once enabled, Cloudflare checks its cache before your Worker runs at all. If it finds a fresh cached response, it serves that directly. If not, your Worker runs as usual, and Cloudflare stores the result for next time.

Why it matters

Caching used to be something you bolted onto a Worker after the fact. Workers Cache flips that: the cache now sits in front of your code by default, and your code controls it using standard Cache-Control headers, the same HTTP headers that have told browsers and CDNs how to cache content for decades.

The cost model changes too. On a cache hit, Cloudflare still charges the standard request rate, but you pay no CPU time, since your Worker never ran. On a miss, you pay the usual request rate plus CPU time. For a Worker that serves the same product page or API response to many visitors, that adds up.

Who should care

This matters if you’re running an app, API, or site on Cloudflare Workers, including apps deployed there through an AI app builder or coding agent that targets Cloudflare as its hosting platform. It’s most useful for anything that renders the same response repeatedly: product pages, blog posts, or API endpoints that don’t change on every request.

If your Worker currently recomputes the same public response for every visitor, this can reduce cost and latency. The word public is important. Account pages, user-specific API responses, private files, and anything containing credentials or personal data should not enter a shared cache.

What builders should do next

Add the cache block to your Wrangler config, then set a Cache-Control header on any response you want cached:

return new Response(body, {
  headers: {
    "Cache-Control": "public, max-age=300, stale-while-revalidate=3600",
  },
});

max-age=300 tells Cloudflare to treat the response as fresh for 300 seconds. stale-while-revalidate=3600 lets Cloudflare keep serving that response for up to an hour after it goes stale, while quietly re-running your Worker in the background to refresh it, so visitors never wait on a slow rebuild.

Start with one endpoint that returns identical public content for every visitor. Do not copy this header onto authenticated routes. For private or personalized responses, use private or no-store as appropriate and confirm that Cloudflare does not cache them.

Verify the result from three sessions: the original user, a logged-out browser, and a second user account. Change something visible in the first account, then confirm neither of the other sessions receives it. Also inspect the response’s cache status so a correct-looking page does not hide an unsafe cache hit.

When something changes and you need the cache cleared early, tag responses with a Cache-Tag header and purge them from your own code with ctx.cache.purge({ tags: ["product:123"] }).

Workers Cache is live today for every Worker, on every plan, with no beta sign-up. Use it for repeatable public content first. Cost savings are not worth creating a cross-user data leak.

End of article