bunny.net lets Edge Scripts run before the CDN cache without giving up caching

bunny.net has put new Edge Scripting cache controls into public preview. Developers can now run client-request and client-response hooks before and around the normal CDN cache path, rather than having Edge Scripts skipped when a cached response is served. A separate Cache API gives scripts explicit match, put and delete operations for a regional cache. Together, the changes allow per-request logic such as authentication, personalization or request rewriting without automatically forfeiting edge caching.

The previous execution model forced an architectural trade-off: logic that had to run on every request could conflict with the CDN’s cheapest and fastest path because cache hits could bypass the script. Pre-cache execution lets builders keep dynamic control at the edge while preserving automatic caching, and the Cache API adds a lower-level option for application-managed cache behavior. That can simplify authenticated content, feature flags, routing, API acceleration and personalized responses, but it also moves cache correctness into application logic when developers opt into the explicit API.

bunny.net says the new onClientRequest and onClientResponse hooks execute before and after cache handling on the client side of the edge request. That means a script can inspect or modify a request before the CDN looks for a cached object and can alter the response on its way back to the client. Builders can therefore apply authentication, headers, rewrites or personalization logic on every request while still allowing the underlying content to benefit from bunny.net’s automatic CDN cache.

The preview also adds script-level cache.match(), cache.put() and cache.delete() operations. This cache is regional rather than globally replicated and uses exact cache keys, giving developers explicit control over what is stored and invalidated. bunny.net documents a 100 MB per-object limit, so the API is better suited to application responses and derived data than arbitrarily large assets.

Pre-cache execution is useful when the existing CDN cache should remain authoritative but request-specific logic must always run. The Cache API is useful when the script itself needs to decide what constitutes a hit, how keys are formed, or when an object is replaced. Using the latter means developers also own more of the invalidation and consistency logic, especially because cache contents are regional rather than a single globally synchronized store.

The capability is available as a public preview rather than a settled GA contract. Teams can use it to test edge-auth, personalization and API-cache patterns, but should monitor execution pricing, limits and semantics before making it a hard dependency. Region-local cache behavior also deserves explicit testing for applications that assume immediate global consistency after writes or deletes.