Cloudflare moves response-header rewrites into Cache Response Rules

Why it matters

Cache Response Rules let infrastructure teams fix costly caching mistakes and preserve cache tags during CDN migrations without changing application code or maintaining a Worker.

Cloudflare, founded by Matthew Prince, Michelle Zatlyn and Lee Holloway, published a product post explaining Cache Response Rules, a feature that moves a specific class of CDN fixes out of origin code and custom Workers and into Cloudflare's rules control plane.

The timeline needs precision. Cloudflare's cache changelog recorded Cache Response Rules on March 24, 2026, before the product post. The post is the full technical explanation of an existing feature, rather than its first availability.

The product fits the operating thesis Prince, Zatlyn and Holloway established before Cloudflare had a name. Prince and Holloway started Project Honey Pot in 2004 to track how spammers harvested addresses and how malicious traffic moved across the web. Zatlyn joined Prince at Harvard Business School in 2009 and pushed the project toward stopping abusive traffic, according to Cloudflare's account of its founding. Early investors worried that placing another network between websites and their visitors would add latency. Caching became central to Cloudflare's answer: absorb repeat traffic at the edge, protect the origin and make pages load faster.

Cache Response Rules extends that founder bet into a common source of infrastructure waste. The edge can only absorb traffic when origin headers allow it to store and reuse the response. One misplaced header can send every visitor back to the origin.

The missing response phase

Cloudflare's product post starts with a routine failure. A visitor requests /static/app.js, Cloudflare misses the cache and fetches the file from the origin. Session middleware adds a Set-Cookie header to the response, even though the JavaScript file is static. Cloudflare then treats the asset as uncacheable, leaving the origin to serve the same file repeatedly.

The same problem appears when frameworks attach Cache-Control: no-cache broadly, when browser-oriented directives reach the CDN, or when ETag and Last-Modified values trigger unnecessary revalidation. These errors often sit outside the control of the engineer managing the CDN. Fixing one header can require an application deployment or a negotiation with another internal team.

Cloudflare's earlier Cache Rules run while the request is moving toward the origin. They can inspect the URL, extension, request headers, geography and device type to decide whether to check the cache and which cache key to use. They cannot inspect an origin response that does not exist yet.

Cache Response Rules run after that response arrives and before Cloudflare stores it. Customers can remove or set individual Cache-Control directives, add or translate cache tags, and strip Set-Cookie, ETag or Last-Modified. A separate cloudflare_only setting lets an operator give Cloudflare a longer edge lifetime while preserving a shorter browser lifetime.

Before the feature, Cloudflare customers had three practical options: change the origin, write a Worker that fetched and rewrote the response, or accept a lower cache hit ratio. The native rule removes the Worker from that path. That cuts code and another piece of infrastructure from a fix that often amounts to deleting one header.

Cloudflare exposes the rules through its dashboard, Rulesets API and Terraform. Free accounts receive 10 rules, Pro accounts 25, Business accounts 50 and Enterprise accounts 300. If Cache Rules and Cache Response Rules conflict, the response-phase rule takes precedence, according to Cloudflare's documentation.

Cloudflare built a migration tool into the cache

One of the most commercially useful actions has little to do with stray cookies. Cache Response Rules can translate another CDN's cache-tag format into Cloudflare's Cache-Tag header as responses pass through the edge.

For example, an origin that emits a comma-delimited Surrogate-Keys header can keep doing so. Cloudflare can split that value and attach the resulting tags to its cached object, allowing tag-based purges without an origin release.

That lowers a practical barrier to moving traffic between CDN providers. Cache tags often become embedded in publishing systems, deployment pipelines and application code. Asking a customer to rewrite that machinery before switching providers stretches a network migration into an application project. Cloudflare can now absorb part of that incompatibility at its edge.

Cloudflare benefits directly from that abstraction. The easier it is to preserve existing origin behavior, the easier it is to put Cloudflare in front of an application. Cache Response Rules also strengthen Cloudflare's argument that its rules layer can replace custom edge code for routine configuration work.

The underlying capability is established in the CDN market. Fastly supports cache-stage response header changes before objects are stored, including setting, appending and deleting headers. Akamai's Property Manager provides rules and response-header controls around cacheability and TTLs. Cloudflare is packaging that class of control into the same interface customers already use for its request-side cache rules.

More control creates more ways to cache the wrong thing

Removing Set-Cookie is safe for a versioned JavaScript bundle or font file when the cookie has no effect on the content. Applying the same action to account pages, checkout flows or authenticated HTML can break sessions and expose user-specific responses to the wrong visitors.

Cloudflare's own troubleshooting documentation warns that caching dynamic pages too aggressively can prevent browsers from receiving session cookies. The resulting failures include sign-in loops, missing session state and CSRF errors. Cloudflare advises excluding routes such as /login, /account, /cart, /checkout and authentication APIs from caching.

That makes staging and URL-level checks important before a rule is promoted broadly.

Cloudflare has not disclosed customer adoption, measured cache-hit improvements, origin cost savings or performance data for Cache Response Rules. The product post uses technically credible examples, though it stops short of quantifying the effect in production.

The rules layer keeps expanding

Cache Response Rules follows Cloudflare's broader effort to pull operational decisions into its own control plane. Related RuntimeWire coverage has looked at Cloudflare bringing private DNS into its Zero Trust control plane and Meerkat, an internal consensus project designed to keep control-plane writes moving across a globally distributed network.

This cache feature is narrower, but it follows the same product strategy: let customers change network behavior in Cloudflare without coordinating a release at the origin. That has substantial reach. Cloudflare reported about 332,000 paying customers at December 31, 2025, including 4,298 customers generating more than $100,000 in annualized revenue, in its 2025 annual filing.

For a small engineering group, the immediate payoff is fewer custom Workers and fewer origin deployments. At larger organizations, the larger gain is organizational: the group responsible for CDN performance can correct cache behavior without waiting for the group that owns the application. Prince, Zatlyn and Holloway built Cloudflare around moving work away from origins and into the network. Cache Response Rules gives that network authority over the response headers that previously limited what it could do.