Streaming servers.
The big night costs the same.
Transcoding on cores that are actually yours, delivery on a port with no counter. The stream that finds its audience does not turn into a bill.
- traffic
- unmetered, sustained
- port
- 10 to 100 Gbps
- cpu
- Intel Xeon or AMD EPYC — core count sized to the transcode
- gpu
- available on a built-to-order machine
- tenancy
- single tenant — no shared cores
- addressing
- 2 × IPv4 + native IPv6
- operating system
- any Linux distribution, mount your own ISO over IPMI, Proxmox or VMware ESXi
- locations
- AMS · NL · MEP · NL · IAD · US-EAST · PHX · US-WEST
Mega or Ultimate for most stacks; a custom build when the transcode needs a GPU or the port needs to be wider.
Where the cost actually sits
A stream has two cost centres that do not move together. Transcoding is bound by cores or a GPU, depending on the codec and how many renditions the ladder needs; delivery is bound by the port. CPU transcoding scales with core count and clock speed, GPU transcoding trades flexibility for throughput per watt, and which one fits depends on the ladder, not on which sounds more serious.
Delivery is where a busy night actually costs money elsewhere: the stream that finds an audience turns into sustained egress at exactly the moment metered billing is least forgiving. An unmetered port does not care whether the audience was ten people or ten thousand.
- No transcoding service, no player, no packager, no DRM — bring your own stack.
- No guaranteed mitigation if a stream draws an attack.
- What you are entitled to broadcast is between you and the rights holder.