Dedicated nodes bought one at a time, in the locations you name. Not a whole network: capacity where your current setup is thin, operated by us.
Reply within 3 business hours. No sales sequence.
A single physical node in a single data centre, reserved for your traffic and run by our engineers. You do not rack it, patch it or monitor it.
The machine carries your traffic and holds your objects. Nothing else shares its disk, its memory or its port.
Storage, port capacity, transit and the data centre itself are chosen for the job the node has to do, then written into the quote before anything is ordered.
You get dedicated capacity without buying, racking or replacing a machine. Failures, firmware and lifecycle stay on our side.
A dedicated node appears next to your existing zones. Cache rules, purge and logs behave exactly as they do on the shared tiers.
Most infrastructure conversations start with a single weak spot, not with a map. One node in the right city often settles it.
Updates, DLC and patches land on a known date and every player pulls the same large files at once. A dedicated node in the busiest region absorbs that hour instead of queueing behind other tenants.
Your numbers are fine everywhere except one market, and the fix is local rather than global. A node goes where the p95 is ugly and the rest of the setup stays untouched.
A build goes out and the whole installed base fetches it within a few hours. Dedicated capacity keeps that spike off the shared pool and off your origin.
If the answer turns out to be several regions at once, with your own hostname and routing, you are looking at a Private CDN Network rather than a node. And if the requirement is a country rather than a data centre, with the node possibly sitting in your own building or inside your ISP, that is Local Cache Servers.
A dedicated node does not ask you to move anything. It sits beside the setup you already have and takes the part of the load that setup handles worst.
Keep the incumbent for everything it does well and point one hostname or one region at a dedicated node. Nothing about the migration is all-or-nothing.
A node placed close to your origin absorbs repeated fetches, so the origin answers once per file per TTL instead of once per edge that missed.
Traffic can fall back to the shared network rather than to your origin. Whether that happens automatically or waits for your call is a configuration choice, agreed in writing during scoping. Either way a single dedicated node is an upgrade on top of a working platform, not a new single point of failure.
We confirm what is available there, what transit it gets and what the node needs to hold.
Monthly figure, term and the date the node is live, all in writing. Nothing is ordered until you have that.
The node goes live while everything you run keeps running, so you compare on real traffic before shifting anything.
Add another location when the numbers justify it, or wind one down at the end of its term. Overflow above a node’s capacity can be allowed to run on the shared tiers, or the node can stay hard-capped, whichever suits your build.
Both are dedicated hardware. The difference is whether you are buying capacity or a network.
You are buying capacity in named places. Start with one node, keep your current delivery, add locations when the numbers say so. Routing and hostnames stay as they are.
You are buying a delivery layer: several nodes, your own hostname and certificate, your own routing and your own regional map. See Private CDN Network.
Four platform classes cover almost every single-node build. Each one is preconfigured rather than assembled to order, which is why a node can be specified and shipped without waiting on parts.
The everyday build. Enough flash for a working set and enough memory to answer most requests without touching disk.
For TLS-heavy traffic and many small objects, where request rate rather than object size is what saturates a node.
Four times the flash of the standard build, for a catalogue that has to stay in cache instead of falling back to origin.
The DPU carries network processing instead of the CPU, so the cores stay free for cache work at 200 gigabit.
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. Larger builds and mixed racks exist and are quoted the same way.
A dedicated node is a fixed monthly figure, plus delivery on your agreed tier. The figure follows the location, the hardware the job needs and the term. It is quoted per build and it is not a metered rate.
For reference, 100 TB a month on the public tiers costs $415. Whether a node beats that depends on how concentrated your traffic is in one place. The full ladder sits on Custom Enterprise CDN Infrastructure, alongside Hybrid CDN Solutions and Private Cache Servers.
Tell us the location and what the node has to carry. You get a reply within 3 business hours, with either a quote 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 the shared tiers already cover you. No sales sequence in between.
BlazingCDN supplies individual CDN servers: dedicated nodes reserved for one customer, placed in the data centres you name and operated by BlazingCDN engineers. Each node is specified per build, priced as a fixed monthly figure, and appears in the same panel and API as shared zones. A reply with a quote, or an honest no, arrives within 3 business hours.
A dedicated BlazingCDN node is priced as a fixed monthly figure per build, so the useful comparison point is the public shared tiers, where 100 TB a month costs $415 (as of October 2026). A node wins only when traffic is heavily concentrated in one place.
The node price follows three inputs: the location, the hardware the job needs and the term. Delivery on your agreed tier is added on top. The figure is quoted per build and is not a metered rate, so BlazingCDN does not apply the per-TB table to the server itself. Monthly price, term and go-live date are all written into the quote before anything is ordered. For example, a game studio whose patch traffic lands mostly in one city may justify a node, while a spread-out audience usually does not. BlazingCDN says so directly when the shared tiers already cover you.
A BlazingCDN individual server sits beside your existing setup and takes the part of the load that setup handles worst, so nothing has to migrate. You can point one hostname or one region at the dedicated node and keep the incumbent CDN for everything else.
The node is a single physical machine in a single data centre, reserved for your traffic. Nothing else shares its disk, memory or port. BlazingCDN engineers rack, patch and monitor the hardware, and failures, firmware and lifecycle stay on the BlazingCDN side. A node can also act as a shield in front of your origin, so the origin answers once per file per TTL. If the node goes down, traffic can fall back to the shared BlazingCDN network rather than to your origin. Whether that fallback is automatic or waits for your call is agreed in writing during scoping. Cache rules, purge and logs behave as they do on shared zones.
BlazingCDN builds dedicated nodes on four preconfigured platform classes, from a 1U delivery node with 32 CPU cores to a 2U DPU node with 96 cores and 15.2 TB of NVMe. Preconfigured builds can be specified and shipped without waiting on parts.
The everyday delivery node has 32 Xeon 6 cores, 1 TB of memory, 1.9 TB of NVMe and a 25GbE port. The dense compute node uses 64 dual EPYC cores and 1.5 TB of memory for TLS-heavy traffic and many small objects. The flash cache node has 72 cores and 7.6 TB of NVMe, four times the flash of the standard build, for a catalogue that must stay in cache. The DPU node pairs 96 EPYC cores with an NVIDIA BlueField-3 DPU and 200GbE or NDR200 networking, so the cores stay available for cache work. For example, a large VOD library suits the flash cache node. Every specification is written into the quote.
An individual BlazingCDN server is the wrong choice when the shared tiers already cover your traffic, or when the need is a whole network rather than capacity in one place. BlazingCDN says so in the first reply, within 3 business hours.
Three cases point elsewhere. If traffic is spread evenly across many markets, shared delivery at one rate from $5 per TB down to $2.50 per TB (as of October 2026) usually costs less than a fixed node. If you need several regions at once, with your own hostname, certificate and routing, the better fit is a Private CDN Network. If the requirement is a country rather than a data centre, possibly with hardware in your own building or inside an ISP, Local Cache Servers fit better. A single node makes sense for one weak spot. For example, one region where p95 latency looks bad, or a patch day that floods one market.
BlazingCDN orders a dedicated node in four steps: you name the location, BlazingCDN confirms availability and transit, you receive a written quote, and the node goes live beside your current setup. Nothing is ordered until the monthly figure, the term and the go-live date are in writing.
Scoping starts with what the node has to carry. An engineer replies within 3 business hours with an architecture sketch or an honest no. After go-live, you compare the node on real traffic before shifting anything. Scaling happens node by node: add a location when the numbers justify it, or wind one down at the end of its term. Overflow above a node’s capacity can run on the shared tiers, or the node can stay hard-capped. For example, a software vendor might start with one node in its busiest market for release day, then add a second location after two releases. Each node appears in the same panel and API.