# Cloudflare Workers Cache: tiered edge cache for your Worker

> Cloudflare Workers Cache is a tiered cache that sits in front of a Worker itself, enabled with one Wrangler line. Cache hits skip the Worker, so no CPU billing.

Published: 2026-07-06
URL: https://daniliants.com/insights/cloudflare-workers-cache-tiered-edge-cache-for-your-worker/
Tags: cloudflare, serverless, devops, edge-caching

---

## Summary

Cloudflare launched Workers Cache: a tiered cache that sits in front of a Cloudflare Worker itself (not just in front of an origin), configured with one Wrangler config line plus standard `Cache-Control` headers. Cache hits skip the Worker entirely (no CPU billing), while `stale-while-revalidate` lets stale content serve instantly during background refreshes, giving server-rendered apps static-site speed without static-site rebuild delays.

## Key Insight

- **The architectural shift**: Workers used to run in front of the cache (a CDN transforming requests to an origin). Frameworks like Astro, Next.js, Remix, and SvelteKit now ship Cloudflare adapters where the Worker *is* the origin, so there was nothing to cache in front of it until now.
- **Billing model is the real story**: cache HIT = standard request charge, zero CPU billing. MISS and BYPASS both bill request + CPU normally. A previously-free path (static assets, worker-to-worker calls via service bindings/ctx.exports) now bills at standard request rate once caching is enabled, because each one consults the cache.
- **Per-entrypoint cache control is the standout feature**: a single Worker can have multiple `WorkerEntrypoint`s, each opted in/out of caching independently via the `exports` map in Wrangler config. A gateway entrypoint (auth/routing) stays uncached; an inner "expensive work" entrypoint gets cached, enabling patterns no other platform offers (per their claim): authenticated, multi-tenant APIs cached at the edge without leaking data between users.
- **Multi-tenant safety via `ctx.props`**: passing a `userId` (or tenant ID) into `ctx.props` when calling a cached entrypoint makes it part of the cache key automatically, so different users hitting the same URL get separate cache entries. Pattern: gateway authenticates, strips `Authorization` header (otherwise Cloudflare's automatic bypass kills caching), forwards with `ctx.props: { userId }`.
- **Two-tier topology, no config**: a lower tier per data center, an upper tier that aggregates fills network-wide. First request anywhere populates the upper tier, so subsequent requests from any data center can hit without ever touching the Worker, giving dramatically higher hit ratios than a flat single-layer cache, and it's automatic (no "enable tiered cache" toggle).
- **Vary header support done properly (RFC 9110/9111)**: separate cached variants per distinct header combination (Accept, Accept-Language, Accept-Encoding, etc.), no allowlist restriction, but `Vary: *` disables caching entirely, and unbounded variant fan-out is a real footgun if headers aren't normalized upstream.
- **Concrete TTL guidance from the post**: product catalog updating every few minutes gets `max-age=300, stale-while-revalidate=3600`. Near-static blog archive gets `max-age=86400, stale-while-revalidate=2592000` (Worker runs once/day per page).
- **Launch caveat**: at launch, cacheable response size is capped at the Free plan limit (512 MB) regardless of paid plan (temporary, with per-plan limits coming later). Astro has first-class integration today (`cacheCloudflare` provider); TanStack Start and Next.js (via Vinext) integrations are in progress.
- **No new SKU**: no separate cache pricing, no per-GB storage fee, all folded into the existing Workers billing model.