A cache layer you control: what stays cached, for how long, and how rarely your origin gets asked. Dedicated cache capacity for libraries that do not fit a shared eviction policy.
Reply within 3 business hours. No sales sequence.
Dedicated nodes answer the question where. A private cache layer answers a different one: what stays cached, for how long, and who decides.
On shared cache, a large library competes for space with everyone else’s. Cold files get pushed out and the next request goes back to your origin. Dedicated cache removes that competition entirely.
How long an object lives in cache stops being a platform default and becomes your decision, per path and per content type.
An individual CDN server buys you capacity in a named place. A private cache layer buys you control over what that capacity holds.
Permanent cache keeps your files inside the network instead of letting them expire back to origin. It is priced separately and openly.
$0.02 per GB a month, with the first 500 GB included. That is the whole retention line: you are paying to keep files in the network, not to move them.
Delivery of those files is billed on your normal tier, exactly as it is for anything else.
Large catalogues with a long tail: back catalogue video, old game builds, archived software releases. Each file is requested rarely, so on shared cache it is always cold, and every request becomes an origin fetch.
If your hit ratio looks fine but your origin bill does not, this is usually why.
On a shared platform, caching rules are a negotiation. On dedicated cache, they are configuration.
A release artefact and a thumbnail do not deserve the same lifetime. Set them separately instead of taking one number for the whole zone.
Invalidate a file or a whole zone from the panel or the API, at the moment your release goes out rather than when a TTL happens to expire.
Because the cache is yours, an object leaves it when your rule says so, not when a neighbour’s traffic pushes it out.
Dedicated cache appears next to your existing zones. Automation you already wrote keeps working, and raw logs are available on the usual terms.
Cache quality is not a vanity metric. It decides how often your origin is asked for the same file.
A file that stays cached is fetched from your origin roughly once per TTL per region, instead of once for every user the edge missed. That ratio is the whole point of a cache layer.
Our network averages a 96%+ hit ratio. Once the edge is holding that much, a download no longer depends on your origin being able to carry the load, or to stay online at all.
Current network figures are published on performance metrics.
Four platform classes cover almost every private cache build. What separates them is how much of your library stays local, and how much traffic one node has to answer.
The working set answered from flash. The usual starting point for a private cache in a data centre rack.
Twice the flash and eight times the port. Network processing moves to the DPU, so the cores keep serving cache.
Flash in front of disk, so a long tail stays local instead of going back to origin every time somebody asks for it.
For a catalogue kept whole in one place: 1.4 petabytes of disk in a single chassis, fronted by flash.
Every configuration is specified per build. Cores, memory, flash, raw capacity and port speed follow the size of the library and the shape of the tail, and they are written into the quote before anything is ordered.
Both are dedicated hardware. They solve different complaints.
Your complaint is origin load and cold files. The library is large, the tail is long, and the shared cache keeps forgetting it.
Your complaint is a place. One region reads badly, or a launch needs capacity that is yours alone. See Individual CDN Servers.
And if the complaint is a country rather than a policy, with the node possibly living in your own rack or your operator’s network, start on Local Cache Servers.
Often the answer is both, and then it is a build rather than a product. That conversation starts on Custom Enterprise CDN Infrastructure.
Tell us how big the library is and how cold the tail gets. You get a reply within 3 business hours, with either a sizing or an honest answer that permanent cache on the standard tiers already covers you.
He reads every request sent from this page and replies within 3 business hours, including the reply that says permanent cache on the standard tiers already covers you. No sales sequence in between.
BlazingCDN private cache servers give one tenant dedicated cache capacity, with retention, TTL per path and purge timing set by the customer. Builds range from a 1U flash node with 7.6 TB NVMe to a 4U archive node with 1,440 TB of raw disk. Each build is quoted individually, and an engineer replies within 3 business hours.
BlazingCDN quotes private cache servers per build, so a 1 PB catalogue has no list price: cores, memory, flash, raw capacity and port speed are written into the quote before anything is ordered. One 4U archive node carries 1,440 TB of raw disk behind 1.9 TB of flash, with hardware RAID setting the usable figure.
Delivery of cached files bills on the standard per-TB tiers, separately from the hardware. For smaller libraries, permanent cache on the standard tiers may be enough. Permanent cache costs $0.02 per GB a month with the first 500 GB included (as of October 2026). For example, a 3 TB library adds 2,500 billable GB, or $50 a month. An engineer replies within 3 business hours with either a sizing or an honest answer that permanent cache already covers the case. No sales sequence follows the reply.
On BlazingCDN private cache servers, one tenant owns the cache capacity, so no other customer’s traffic can evict its objects. On shared cache, a large library competes for space, cold files get pushed out, and the next request goes back to origin. The BlazingCDN network averages a 96%+ hit ratio, yet a long tail can still miss.
With a private layer, retention becomes customer configuration. TTL is set per path and per content type, so a release artifact and a thumbnail get different lifetimes. Purge runs from the panel or the REST API at release time. An object leaves the cache when the customer’s rule says so. For example, a file that stays cached is fetched from origin roughly once per TTL per region, not once per user. Dedicated cache appears next to existing zones, existing automation keeps working, and raw logs stay at $50 a month (as of October 2026).
Many BlazingCDN customers need only permanent cache at $0.02 per GB a month, with the first 500 GB included (as of October 2026). A private cache layer makes sense when retention policy, not storage, is the problem. Permanent cache keeps files inside the network instead of letting them expire back to origin.
A private cache fits large catalogues with a long tail: back-catalogue video, old game builds and archived software releases. Each file is requested rarely, so on shared cache the file stays cold. A common symptom is a healthy hit ratio next to a high origin bill. For example, a 3 TB long-tail library on permanent cache costs $50 a month plus delivery on the normal tiers. If that solves the problem, BlazingCDN says so. Teams needing dedicated capacity, per-path TTL control or isolation from other tenants should scope a build. An engineer answers within 3 business hours, including when the answer is no.
BlazingCDN separates the two by complaint: a private cache layer fixes origin load and cold files, while individual CDN servers fix capacity in one named place. Both run on dedicated hardware, and both appear in the same panel and REST API as existing zones.
A private cache suits a large library with a long tail that shared cache keeps forgetting. Individual CDN servers suit a region that performs badly or a launch that needs capacity reserved for one tenant. Local Cache Servers cover a third case, where a node lives in a specific country, possibly in your own rack or an operator network. When the answer is both, the project becomes Custom Enterprise CDN Infrastructure, scoped as a build. For example, a publisher with a 1 PB archive of old builds and one weak region might combine an archive node with a regional server. Every configuration is quoted per build, and an engineer replies within 3 business hours.
BlazingCDN builds private cache on four platform classes, from a 1U flash node with 7.6 TB NVMe to a 4U archive node with 1,440 TB of raw capacity. The 1U flash node pairs 72 CPU cores with 1 TB of memory and a 25GbE port, and serves the working set from flash.
The 2U DPU node doubles flash to 15.2 TB NVMe, uses 96 EPYC cores and 1.5 TB of memory, and offloads network processing to an NVIDIA BlueField-3 DPU on 200GbE or NDR200. The 2U high capacity node puts 8 TB of flash in front of 192 TB of raw disk, so a long tail stays local. The 4U archive node uses 32 Xeon 6 cores, 512 GB of memory, 1.9 TB of flash and hardware RAID. For example, a catalogue near 150 TB points toward the high capacity class. Final cores, memory and port speed follow the library size and are fixed in the quote.