Hardware for streaming workloads, on your terms. Buy a machine outright, have us source and configure one and stand it up in the location you name, or bring your own rack and let us host it.
Reply within 3 business hours. No sales sequence.
Most vendors give you one option and call it a product. Streaming teams arrive with very different constraints, so there are three.
We specify and supply the machine, you own it. It goes on your balance sheet and into your rack, wherever that rack happens to be.
Suits teams with their own facility, or a capex budget that prefers hardware to a subscription.
We build the configuration around your workload and stand it up in the location you name, with transit chosen for that market. If the build needs hardware we do not already hold, we buy it in: the capital is ours, you pay a monthly figure. You are not limited to a stock list.
Suits teams who want capacity in a specific city without opening a relationship with a data centre, or without putting hardware on their own balance sheet.
You already own the hardware and it needs somewhere to live. We take the rack into a data centre, give it power, cooling and transit, and keep hands available for the physical work.
Suits teams who have made the hardware decision already and need the facility, not the machine.
The arrangement changes what you pay for and who owns what. Everything else about the build, sizing, locations and transit, is decided the same way in all three.
Served fromhttps://cdn84906683.blazingcdn.net/boxing/hls/master.m3u8 · Segments: 4 s · Footage: Pixabay, free licence A streaming server is only as useful as the software on it, and that software is yours. Here is the honest division of labour.
The specification, the build, the network it sits on and, where we host it, the power and the physical work. What we operate is monitored by us around the clock, and the availability commitment for your build is written into your order.
Ingest, the media server, packaging and manifests, your ladder and your DRM decisions. We do not transcode, re-package or generate manifests on any of our infrastructure, and we say the same on Streaming CDN.
If the encoding itself is the bottleneck rather than the server it runs on, start from Video Content Processing Servers.
Four platform classes cover almost every streaming build, whether you buy the machine outright, have us place it, or bring your own rack. The stack that runs on them stays yours.
Where the mezzanine and the packaged renditions live. Flash in front of disk, so the catalogue is read fast and stored cheaply.
The node that answers players. Sized so a live window and a hot VOD tail both stay in flash.
For teams that run their own encoder. The same card handles ladders, packaging and the graphics work sitting next to them.
A back catalogue kept whole on one chassis rather than pulled from object storage every time somebody requests it.
Every configuration is specified per build. Cores, memory, flash, raw capacity and port speed follow the ladder, the concurrency and the size of the catalogue, and they are written into the quote before anything is ordered.
The three arrangements differ mostly in this table, which is the part worth agreeing before anyone quotes a number.
Buy: yours from delivery.
Placed: ours, sourced for the build, on a monthly figure.
Colocated: yours already.
Buy: yours to arrange.
Placed: ours, including power, cooling and transit.
Colocated: ours, including remote hands.
Yours in all three. Your media server, your packager, your ingest and your licences. We do not run the stack and we do not charge you for it.
Two different purchases that both get described as «streaming infrastructure».
You are buying machines and a place to put them. Ordered per build, in whichever of the three arrangements fits how your company buys.
You are buying delivery. You bring the stream and it reaches viewers on the shared network, billed per terabyte. See Streaming CDN.
The two sit together often: your own servers produce and originate the stream, delivery runs on the network. The rest of the build-to-order line is on Custom Enterprise CDN Infrastructure.
Tell us what the server has to run and which arrangement suits you. You get a reply within 3 business hours with a specification and a price, or an honest answer that a shared setup covers you already.
He reads every request sent from this page and replies within 3 business hours, including the reply that says a shared setup covers you already. No sales sequence in between.
BlazingCDN supplies streaming servers in three arrangements: buy a machine outright, have BlazingCDN source and place one in the location you name for a monthly figure, or colocate your own rack in a BlazingCDN data centre. Each build is specified per workload, and an engineer replies within 3 business hours with a specification and a price.
BlazingCDN prices a streaming origin, such as the 2U node with 192 TB raw capacity, per build rather than from a list: the quote follows the arrangement, the location and the term. Per-TB delivery pricing does not apply to servers.
The arrangement changes what you pay for. Buying outright means BlazingCDN specifies and supplies the machine, and the hardware sits on your balance sheet. A placed build means BlazingCDN owns the hardware, covers power, cooling and transit, and bills a fixed monthly figure. Colocation means you already own the machine and pay for the facility and remote hands. The origin node in this example carries 48 EPYC cores, 768 GB of memory, 8 TB of flash in front of disk and a 25GbE port. Cores, memory, flash and port speed are written into the quote before anything is ordered. For example, a larger catalogue might move to the 4U deep library node with 1,440 TB raw capacity.
BlazingCDN offers three arrangements for streaming servers: sourced, configured and placed hardware that you own; configured and placed hardware that BlazingCDN owns and bills monthly; and your own rack hosted in a BlazingCDN data centre. Sizing, location and transit are decided the same way in all three.
The first option suits teams with their own facility or a capex budget. BlazingCDN specifies and supplies the machine, and the hardware goes into your rack. The second suits teams that want capacity in a specific city without a data centre contract. BlazingCDN builds the configuration, buys hardware if needed, and places the server with transit chosen for that market. The third suits teams that already own hardware. BlazingCDN provides power, cooling, transit and remote hands. For example, a broadcaster with new encoders but no facility in a target market would pick colocation. The streaming stack stays yours in every case.
No, BlazingCDN answers for the machine, and you answer for the stream: ingest, media server, packaging, manifests, bitrate ladder and DRM decisions remain yours. BlazingCDN does not transcode, re-package or generate manifests on any of its infrastructure.
The division of labour is explicit. BlazingCDN covers the specification, the build, the network the server sits on and, where BlazingCDN hosts the server, power and physical work. Everything BlazingCDN operates is monitored around the clock, and the availability commitment for your build is written into your order. Your licences and software stay under your control, and BlazingCDN does not charge for the stack. For teams that run their own encoder, the 2U encoding node carries 2x NVIDIA RTX PRO 6000 Blackwell cards, 32 CPU cores, 512 GB of memory and a 10GbE port. For example, a team running FFmpeg ladders installs its own build. When encoding is the bottleneck, Video Content Processing Servers are the starting point.
BlazingCDN offers four streaming platform classes: a 2U origin node, a 1U edge delivery node, a 2U encoding node and a 4U deep library node with 1,440 TB raw capacity. All four work in any arrangement: bought, placed or colocated.
The origin node has 48 EPYC cores, 768 GB of memory, 8 TB of flash and 192 TB raw capacity, for mezzanine files and packaged renditions. The edge delivery node has 72 cores across two Xeon 6 sockets, 1 TB of memory and 7.6 TB of NVMe, sized so a live window and a hot VOD tail stay in flash. The encoding node pairs two NVIDIA RTX PRO 6000 Blackwell cards with 32 cores and 512 GB of memory. The deep library node keeps a back catalogue on one chassis with 32 Xeon 6 cores and hardware RAID. For example, a sports archive could sit on the deep library node instead of object storage. Larger builds are quoted the same way.
BlazingCDN sells two different things: servers are machines and a place to put them, while Streaming CDN is delivery on the shared network, billed per terabyte from $5 per TB down to $2.50 per TB (as of October 2026). Most teams decide by what they need to own.
Choose servers when you need dedicated hardware for origin, encoding or a large library, ordered per build in one of three arrangements. Choose Streaming CDN when you already produce the stream and only need it to reach viewers. The two often run together: your own servers produce and originate the stream, and delivery runs on the network. For example, a platform streaming 100 TB a month to viewers pays $415 for delivery on the Streaming CDN, while its origin node is a separate fixed quote. Delivery comes with a 14-day testing period on real traffic. For either path, an engineer replies within 3 business hours.