Setting up BunnyCDN: where static and video delivery break
While traffic is small, static and video delivery looks healthy: files are served directly from where the application lives, and no one notices the substitution.
But as soon as the audience spreads across regions, the picture changes — a user from another region pulls heavy files over a long route, directly from the origin server.
The first thing visible in measurements is that time to first frame for video and time to render for images grow with distance. The player starts buffering, some requests time out, and support receives complaints about “lag” without specifics. The edge cache hit ratio remains almost zero: content is not cached near the user.
The second is origin server load. At peaks, bandwidth is fully consumed, and along with video everything else degrades: application responses, exports, database calls.
Slow video delivery stops being a separate problem and becomes a trigger for the entire service — the origin is busy serving files instead of handling logic.
The cause is usually not server capacity, but delivery configuration: cache headers are not set, query parameters make every URL unique, and delivery zones are not separated by content type.
Setting up BunnyCDN begins with diagnosing this picture — we'll break down how to close each failure point.
What a properly assembled CDN layer delivers: effects and metrics
A properly assembled CDN layer is measured not by the fact it is enabled, but by three numbers: cache hit ratio, delivery time from the nearest point, and the volume of traffic that never reaches the origin. Below is what each effect delivers and how it is achieved when configuring BunnyCDN.
Cache hit ratio and delivery time
At the start, the hit ratio usually stays at 60–70%: different cache key forms with query parameters, short TTLs, and dynamic paths that cannot be cached get in the way.
Key normalization, moving static content to long TTLs, and careful edge rules raise the figure to 90–95% — the edge serves content from the nearest point, the page arrives noticeably faster, and repeat requests do not reach the origin at all.
Cache warming after a release removes the classic dip: first visitors do not have to wait for the edge to fill up. Delivery remains even in mobile networks, where any extra delay is immediately visible.
Offloading the origin and outbound traffic
Cache at the edge cuts the main part of origin outbound traffic: the server serves only misses, content updates, and dynamic content.
The origin stops being a bottleneck during peaks — a sale, mass mailing, or media publication no longer turns into a queue of requests and failures.
At the same time, a whole class of failures goes away: hitting connection limits, timeouts during spikes, failures under load.
Video delivery is moved to a separate zone, and the heavy stream does not compete with the site for origin resources — the peak is distributed across points of presence, not a single server.
How this is assembled in practice — zones, edge rules, and the video delivery scheme — we cover below.
Setting up BunnyCDN: Pull zones, Push zones, and Edge Rules
The choice of delivery mode determines where the edge gets content from and what it does with it along the way. In BunnyCDN, this is set by the zone type and a set of rules — both delivery speed and file update behavior depend on them.
| Option | When it fits | Limitations |
|---|---|---|
| Pull zone | Content on your origin, published by deployment: static, builds, images | Cache warms on the first request in a region; on misses the origin bears the peak |
| Push zone | You need delivery without your own web server: files stored in storage | Publishing via API or panel; no automatic connection to a repository |
| Pull zone + Edge Rules | Headers, paths, and cache policy change without app changes | Logic lives at the edge — complex conditions are harder to debug |
| Hybrid: Pull + storage for video | Video is separated from web content, with its own publishing cycle and range delivery | Two configuration loops, synchronization of names and invalidation |
Caching by extensions and response codes
Rules are set with masks and priorities: for styles, fonts, and builds — a long term with the immutable flag; for video playlists and segments — seconds; for HTML — a short term or disabled cache.
Response codes are listed separately: 200 and 301 are cached, 404 — briefly, so as not to load the origin, 5xx and 403 are not cached. Cache invalidation is targeted — by URL or tag; a full zone purge resets warming and returns load to the origin.
Edge Rules: headers, path rewriting, restrictions
Edge Rules modify the request and response: they add Cache-Control, CORS, and HSTS, hide service headers, rewrite the path for versioned builds, and make redirects while preserving parameters. The first match wins, so specific conditions are placed above general ones.
Limitations — a finite number of rules per zone and no arbitrary code: we move complex logic to the origin.
Implementation order: from traffic audit to handover
We build the BunnyCDN implementation route so that delivery switches without downtime and without surprises for the origin server. First we record how traffic is distributed now, then design zones, and only after testing do we move the audience.
Audit of the current delivery scheme
- Inventory of traffic delivery. We take a request map: share of static, images, and video, geography, peak hours, which paths most often reach the origin server. The output is a table of volumes and cache requirements.
- Zone design. Pull zones for static and video; Push zones with preloading for large files with infrequent updates. Here we also define cache keys, retention periods, and separation by content type.
- Setting up edge rules. Cache headers, query parameter handling, compression, origin access by signature, and the procedure for forced cache refresh.
Testing on a realistic load profile
- Load testing. We reproduce the peak: simultaneous requests for video, a spike on one popular file, cold cache after purging. We look at hit ratio, response latency, and origin load.
- Traffic switching. We move traffic in shares via records with a short TTL, monitoring errors and origin response. The previous scheme remains operational until the switch is complete — rollback takes minutes.
- Documentation handover. We provide the description of zones and rules, cache refresh regulations, delivery scheme, access credentials, and the procedure for typical operations.
What the customer receives: configurations and regulations
After implementation, the team is left not with a set of settings in a web panel, but with a package that can be used to rebuild the infrastructure and hand it to an on-call shift.
All artifacts are stored in the repository and go through review — manual edits in the interface do not go unnoticed.
Flow diagram and zone configuration
- Declarative zone configurations: origin servers, zone type (pull or push), caching rules by content type, timeouts, and retries.
- Perimeter rules: redirects, security headers, method and geo restrictions, limits on request size and request rate.
- Traffic flow diagram: the request path from client to origin, cache trigger points, the video delivery segment, and the order of file range delivery.
- Signed link and access token policies: signature lifetime, binding to client address or referrer, key rotation without downtime.
Cache refresh and access role regulations
- Invalidation regulations: what is purged in a targeted way, what by prefix, what lives until expiry, and the expected time to readiness.
- Role and permission matrix: who changes configuration, who only invalidates, who sees analytics and exports.
- Instructions for the on-call shift: a layered diagnostic checklist, typical failures, and rollback procedures.
- Emergency origin switching procedure and video delivery degradation plan.
Case study: eliminated delivery dips under peak loads
The client is a media service with a catalog and video library: lecture recordings, breakdowns, broadcast recordings.
Delivery went directly from application servers, and during evening peaks, when thousands of viewers connected simultaneously, some requests ended in failure, and the catalog opened noticeably longer than usual. We analyzed and moved delivery to BunnyCDN.
What it was before
The same loop served video fragments, catalog images, and interface data. Cache headers on video segments were not set at all, and previews were re-requested from the application every time the feed refreshed.
The cache hit ratio stayed around 55%, dropping to 40% at peak — almost all traffic went to the application servers, and 95th percentile response time increased several times over. During the hottest hours, delivery failures reached 2% of requests.
What it became after
We separated delivery by purpose: video — into a pull zone with a long retention period for segments in cache; static — into a separate zone with versioning by file name, so that a catalog update would not reset the entire cache.
We moved conditional logic into perimeter rules: a separate lifetime for images, another for manifests, forced caching for requests without headers. We separately covered spike protection: rate limiting to the origin and priority of video fragments over service requests.
We switched gradually — first a small share of traffic, then fully, with a one-step rollback ready.
We took metrics after stabilization: cache hit ratio grew to 94%, load on application servers at peak dropped by an order of magnitude, 95th percentile response time was cut by three times, delivery failures — from 2% to 0.05%. Dips during evening peaks stopped reproducing even with a twofold increase in simultaneous viewers.
What to do if the CDN is already deployed but cache does not work
Cache "does not work" more often not because of storage settings, but because the origin forbids storage.
We look at response headers: Cache-Control with no-store, private, or max-age=0 values, Set-Cookie on static content, Vary by user data — any of these forces the edge to go to the origin for every file.
Configuration checking starts with two requests to the same address — what the origin returns and what the node returns after warming; a discrepancy in headers shows where storage is lost.
The second cause is different addresses for the same file. Version parameters, campaign tags, trailing slash, variants with and without www — for the cache these are different objects, so the hit ratio drops, and the origin receives traffic that should not reach it.
This is treated with canonicalization: one address for the resource and rules that ignore extra parameters when calculating the key.
The third is bypassing the edge on the application side. Templates build links directly to the origin, the application goes past the node, old pages store absolute addresses.
The cache is configured correctly, but it is not used — this is visible in origin logs: the share of requests from edge addresses does not grow after warming.
The fourth is the lack of rules for dynamic content. If HTML and API responses are handled by the same settings as images and scripts, they are not cached: without a separate rule with a short term and cookie handling, every page goes to the origin.
And we check invalidation — after a release, old objects should be purged in a targeted way, otherwise edits do not reach users.
Technical doubts we resolve before start
Before starting, engineers and department heads ask almost the same questions — about delivery resilience, access to private files, and update speed. Below are short answers without marketing: as it works with Pull and Push zones in practice.
What happens to delivery if a node or an entire region goes down?
Traffic automatically goes to the nearest live nodes, and the edge cache continues to serve static content while the origin is unavailable. We duplicate the origin — a second server or object storage — so for static content the failure remains invisible to the user.
How do you restrict access to private files?
Signed links with a limited lifetime and token validation at the edge, plus a ban on direct access to the origin by address. The link stops working after expiry, and another domain cannot serve your content.
How quickly is content updated after a release?
Static content with a hash in the file name is published immediately — the new address simply is not in the cache. For the rest, we set a manageable cache lifetime and targeted purge by mask from the build pipeline.
Will infrastructure and DNS need to be rebuilt?
No. The layer sits in front of the origin: the domain is moved to CNAME, certificates are issued and renewed automatically. Rollback is by switching the record back, which takes minutes, not a downtime window.
What changes compared to serving directly from the server?
Static content moves to the edge, origin load drops — the server handles dynamic content and API. The browser receives files from the nearest node, and edge rules remove extra requests before they reach the backend.
Describe your delivery scheme and access restrictions — we will come back with an estimate and work plan.Let's discuss the task: what data is needed for an estimate
To come back with an estimate, not a range "from and to," we need source data on your delivery.
The more accurate the traffic profile and current scheme, the fewer assumptions in the work estimate and implementation plan — and therefore, fewer surprises during the switching stage.
- Traffic profile: average and peak load, daily and weekly fluctuations, share of requests that are cacheable at all.
- User geography: regions with the main volume, requirements for proximity of delivery nodes and delivery latency.
- Content types: static, large files, video — indicating duration and whether seeking within the stream is needed.
- Current delivery scheme: content origins, domains, how cache headers are set, and how stale content is currently purged.
- Limitations: deadlines, allowed downtime windows, requirements for availability and site behavior when a separate node fails.
- Access: control panel, management API, and DNS zones, if traffic is switched on our side.
As a result, you receive a work estimate, a zone and delivery rule scheme, and an implementation plan with traffic switching order and a rollback point to the previous scheme. Describe the task in free form — where what lies and what hurts. We will come back with an estimate and plan.