A cache node inside one country: in our data centre there, in yours, or inside the ISP network your audience already sits behind. For teams whose CDN is fine everywhere except the one market that matters.
Reply within 3 business hours. No sales sequence.
These are the numbers on our shared network, last measured in June 2026. They are good in the three regions we cover densely, and they say nothing about a country we do not sit in.
Average latency across European nodes, at 1.12 Gb/s average download speed.
Average latency across North American nodes, at 1.11 Gb/s average download speed.
Average latency across Asian nodes, at 761 Mb/s. A wider spread than the other two, because Asia is a continent rather than a city.
If your audience sits outside those three regions, or inside a national network that reaches all of them over one congested transit link, a shared node is the wrong tool for the job and a cache node inside the country is the right one. These figures are published and updated on Performance Metrics, and the regional detail sits on CDN by region.
A local cache server is a CDN cache node committed to one named country or city, rather than a slice of a shared global network. The hardware can sit in a BlazingCDN data centre in that country, in your own data centre or campus, or inside the network of the ISP that carries most of your audience. In all three cases we supply the node, configure it, monitor it and patch it.
Four situations where the fix is placement rather than more of the same. All four are measurable on your own traffic before you move anything that matters.
Your p95 is healthy across three regions and ugly in a fourth market that matters commercially. A node inside that country turns an intercontinental round trip into a national one, and nothing else about your setup has to change.
In many national markets one or two ISPs carry the majority of subscribers. A node inside that network answers their requests without touching a transit link, which takes load off the operator’s transit at the same time as it takes it off yours.
Internal software distribution, campus deployments, branch offices. The content is cached on hardware you host and served on the network you own. For the European version of this question, written into an agreement, see GDPR Cache Servers.
A launch in a country where you have no presence. A local node buys that presence without a build-out, a local entity or a contract with a facility you have never visited.
Underneath all four, the same two things happen. Each object is fetched into the local node once per TTL and served from there afterwards, so concurrent misses on a cold file collapse into one origin fetch instead of thousands of identical ones. And release day, patch day and match day are absorbed where the audience already is.
Same product, same operation, three answers to one question: whose building the hardware lives in.
We source the site, the transit and the local peering. You get in-country capacity without signing anything with a facility in a market you do not operate in, and the whole chain from the rack to the port is ours to answer for.
The node goes into your rack, on your campus or in your own facility, so cached content is served inside your network and never crosses the public internet to reach the people who asked for it. You provide space, power and a cross connect. We ship the hardware, configure it, monitor it and patch it.
The node is placed with the ISP that carries most of your audience, so a cache hit for that operator’s subscribers is answered without touching a transit link. A local cache takes traffic off the operator’s transit too, which is usually the argument that gets it agreed. We can make that case with you, or hand it to you to make.
All three are run the same way: our monitoring, our patching, our capacity planning. What we cover is what we operate, which on a node in our own facility is the whole chain, and on a node in your building or your operator is the node, the software and the transit we provide. The exact wording goes in your agreement. If your team would rather keep root access, the self-managed mode on Custom Enterprise CDN Infrastructure applies here too.
The honest answer depends on the country, and we do not know it until you name one. Here is what decides it.
Europe, North America and Asia are covered densely today, and the regional detail is published rather than described. If your market is on that map, a local node is a scheduling question rather than a sourcing one. See CDN by region.
In a market we do not sit in yet, we source the site, the transit and the local peering ourselves, then come back with what is actually available there and what it costs. That answer takes days, and it sometimes turns out to be no.
If the hardware goes into your own facility or into your operator, the geography question is already settled. What we scope instead is space, power, the cross connect and who has hands on site.
Three classes cover almost every local build. Each one is a preconfigured platform rather than a machine assembled to order, which is why a node can be specified and shipped without waiting on parts.
A compact node for a building rather than a data centre. Enough to hold what one site actually asks for, quiet enough to live in a comms room.
The default for a node in a data centre or an operator rack. Sized for a hot library that has to be answered from memory and flash rather than from disk.
For a large catalogue in one market: flash in front of disk, which is the layout a video or software library needs.
Every configuration is specified per build. Cores, memory, NVMe, raw capacity and port speed follow the job the node has to do, and they are written into the quote before anything is ordered. Because the platforms are preconfigured rather than assembled to order, the go-live date usually follows the facility rather than the hardware.
Three cases where this page is not what you need, and where to go instead. We would rather say it here than on the call after the build.
If no single country carries a meaningful slice of your volume, the shared tiers stay cheaper and faster to start, at the same rate in every region. See Pricing.
If the complaint is that a long tail keeps falling back to origin, the fix is cache policy rather than geography. See Private Cache Servers.
Several regions under your own hostname and routing is a Private CDN Network. Keeping your current CDN and adding nodes only where it struggles is Hybrid CDN Solutions.
Both put dedicated capacity somewhere you name. They answer different questions, and the wrong one costs you either money or a market.
What you are buying: presence in a market.
Where the hardware sits: in one named country, in our facility, in yours, or inside your operator’s network.
The question behind it: where your audience is, and whose network it reaches you through.
What you are buying: a dedicated machine.
Where the hardware sits: in a data centre we already operate, with storage, port capacity and transit specified per build.
The question behind it: how much capacity you need, and who else touches it. Detail on Individual CDN Servers.
Our facility in that country, your own data centre, or your operator’s network. If you already know which ISP carries your audience, name it. We come back with what is actually available there and what the node has to hold.
Monthly figure, term and the date the node goes live, in writing, along with everything you have to provide. Nothing is ordered and nothing is shipped until you have agreed to all of it.
The node goes up while everything you run keeps running. You point one hostname or one country at it and compare both on real traffic before moving anything that matters.
We monitor, patch and scale it, or your team keeps root access. In our own facility we answer for the network and the transit as well. In your building or your operator, we answer for the node, the software and the transit we provide.
The figure follows three things: the country, whose building the node sits in, and the term. A node in our own facility is usually the cheapest of the three, because we already hold the transit there. A node in your data centre trades that cost for the rack, the power and the port you supply. A node inside an operator is quoted against what that operator charges for space and cross connect, which is why we ask for the name of the ISP before we quote anything.
For reference, 100 TB a month on the public tiers costs $415, at the same progressive rate in every region. Whether a local node beats that depends on how much of your traffic sits in one country. The full ladder, from public tiers up to custom builds, is on Custom Enterprise CDN Infrastructure, and the public table is on Pricing.
A local node is quoted per build, so several of these answers start with what it depends on. Here is what it depends on.
Delivery can fall back to our shared network instead of falling through to your origin. Whether that switch is automatic or waits for your call is a configuration decision, agreed in writing during scoping. The exception is content pinned to a country for a residency requirement, which does not leave that country even during failover.
We do, unless the quote says otherwise. You provide rack space, power and a cross connect. We ship the node, configure it, monitor it and patch it, and we arrange replacement parts and remote hands with the facility. Everything you have to provide is listed in the quote before anything is ordered.
It applies to what we operate. On a node in our own facility that is the whole chain. On a node in your building or inside your operator, we answer for the node, the software and the transit we provide, while power, space and the facility itself stay with whoever owns them. The exact wording goes in the agreement rather than on this page.
Often yes, because a local cache takes traffic off their transit as well as off yours, and that is an argument they recognise. We can approach the operator with you, or hand you the technical case to make yourself. If they say no, the node goes into a facility in the same country instead and you keep most of the benefit.
The platforms are preconfigured, so the date usually follows the facility rather than the hardware, and it comes with the quote rather than from a web page. The term is set per build, because it follows the hardware and the commitment behind it, and it is in the quote before anything is ordered.
No. A local node appears next to your existing zones, and cache rules, purge and logs behave the way they do on the shared tiers. Automation you have already written keeps working. If traffic in that country outgrows the node, overflow can run on the shared tiers while capacity is added.
Tell us the country and what the node has to carry. You get a reply within 3 business hours, with either what is available in that market and what it would cost, or an honest answer that the shared tiers already cover you.
He reads every request sent from this page and replies within 3 business hours, including the reply that says a local node is not what your case needs. No sales sequence in between.