Cache Reserve leaves closed beta
Cache Reserve — Cloudflare's approach to extending cache lifetimes using R2's persistent storage — is now available in open beta. The product, first announced earlier this year, lets customers serve content from Cloudflare's cache for longer, reducing origin egress fees while improving load times for website visitors. Enabling it from the Cloudflare dashboard requires a single button press.
During the closed beta, Cloudflare used feedback from initial users to iterate on the product multiple times. The transition to open beta means anyone can now test and integrate Cache Reserve into their content delivery strategy without waiting for access.
Where Cache Reserve fits in the request path
Content served from Cloudflare's cache ultimately originates at a customer's origin server. Each request that reaches the origin costs the customer bandwidth or egress fees from their cloud provider, and the physical distance between visitor and origin can slow response times.
Cloudflare's CDN sits between the two, evaluating origin responses for cacheability. When a response can be cached, subsequent requests are answered from a data center near the visitor, cutting both transit time and origin load. Tiered Cache, introduced several years ago, organizes data centers into a hierarchy where lower tiers sit near visitors and upper tiers near origins. A cache miss in a lower tier checks an upper tier before falling back to the origin.
Cache misses happen for two reasons. First, customers set cache-control headers that mark content stale after a certain period, requiring revalidation. Second, the network itself must evict content when cache space fills up. Cloudflare uses an LRU (least recently used) eviction algorithm, which means content may be evicted before its cache-control lifetime expires if it isn't being requested frequently enough.
This eviction behavior works well for most traffic patterns but creates problems for customers with large libraries of long-tail content that might go unrequested for extended periods. Under traditional caching, such assets get evicted, and the next request forces a trip back to the origin — incurring egress costs to re-serve something that had already been fetched once.
Catching evicted content
Cache Reserve acts as an additional upper-tier layer for content that would otherwise be evicted. Once admitted to Cache Reserve, content is stored for 30 days by default. A new request within that window resets the clock for another 30 days, unless cache-control says the content should no longer be served from cache. The effect is a safety net for cacheable content, removing the worry about cache eviction driving unnecessary origin egress.
Egress savings beyond hit ratios
The core promise of Cache Reserve is higher hit ratios and lower origin egress for rarely requested content. The product includes additional savings mechanisms. On a cache miss, objects are written to Cache Reserve as they're served — the response goes to the visitor while the asset is stored, so the same object won't require another origin fetch for a long time.
Cache Reserve is designed to work with Tiered Cache enabled. When both lower and upper tiers miss, Cache Reserve is checked. A hit there populates both tiers on the way back to the visitor, and the origin never sees the request. Pricing is based on R2 costs; details are in Cloudflare's documentation.
Scaling on the developer platform
Demand for the closed beta was high — over 20,000 users requested access. During testing, Cloudflare observed sustained usage above 8,000 PUT operations per second, GET rates over 3,000 per second, and roughly 600 TB of cached content for some large customers. Opening the product to everyone required significant scaling work.
Cache Reserve stores data in R2 via its S3-compatible API. Under the hood, R2 relies on Workers and Durable Objects to manage object storage complexity. This architecture let the team experiment with different distribution strategies under load without exposing that complexity to users.
The single-button enablement hides several coordinated operations:
- On a cache miss, Pingora, Cloudflare's L7 proxy, fetches content from the origin and writes the response to R2 while the content streams back to the visitor.
- Inside R2, a Worker persists the content while Durable Objects track metadata from Pingora, including origin headers, freshness values, and retention information.
- For subsequent requests, Pingora computes the cache key, whose hash determines both the object's name in R2 and which bucket holds it. Each zone's assets are sharded across multiple buckets.
- After retrieval, Pingora attaches the metadata and sends the content from R2 to the nearest upper tier, then the lower tier, then the visitor.
Planned capabilities
The open beta opens the door to deeper integrations. Cloudflare plans to add analytics so users can see what's stored in Cache Reserve and how much egress it saves. More complex R2 integrations are in the works for customers who want to move into full storage management, along with finer-grained controls over which content is eligible for Cache Reserve.
Beta feedback from customers was positive. Delivery Hero reported a 5% cache hit ratio improvement, which let the company scale back infrastructure for its global site. Anthology reduced daily egress traffic by two-thirds with a single button press. Enjoei saw its cache hit ratio improve by more than 10%, cutting origin egress costs and boosting performance for merchants in South America. Patron Technology, which operates in the live events space, used Cache Reserve to smooth out volatile egress fees caused by unpredictable demand for cacheable content.
Getting started with Cache Reserve
Cache Reserve is now available in open beta, so any Cloudflare user can begin using it without a waiting list or special approval.
To enable Cache Reserve:
- Open the Caching tile in the Cloudflare dashboard.
- Go to the Cache Reserve page and click the enable data sync (or purchase) button.
Enterprise customers can also reach out to their Cloudflare Account team for access to Cache Reserve.
Once enabled, you can confirm that Cache Reserve is functioning by checking the Cache Reserve section of the dashboard, which shows baseline metrics for cached data volume and operation counts. For more granular visibility, you can use Logpush v2 and look for HTTP requests where the field CacheReserveUsed is present. This lets you confirm that specific requests are being served directly from Cache Reserve.
The team is continuing to triage user feedback quickly and refine Cache Reserve to make it more intuitive, more effective, and the go-to option for cutting egress fees on cached content. Future updates are planned as the product matures.
Try Cache Reserve
With Cache Reserve now in more users’ hands, the focus is on expanding its capabilities and refining the tools needed to build an optimal caching strategy. You can test Cache Reserve today and share your experience with the team directly.
