Streaming servers.
The big night costs the same.
Transcoding on cores that are yours alone, delivery on a port with no counter. The stream that finds its audience does not turn into a bill.
- port
- 1, 10, 25, 40, 100 Gbps
- egress
- unmetered
- locations
- AMS · MEP · IAD · PHX
Two jobs that look like one.
A stream is encoded into several qualities, the ladder, so a phone on a weak connection and a TV on fibre both get something they can play. Then those versions are delivered, and every viewer pulls a copy of their own.
Encoding is limited by CPU or GPU. Delivery is limited by the port. They scale with different things, so a streaming server is sized in two steps, not one.
How to choose.
- 01 ─ ladder
Write down the renditions and the codec. Every rendition costs encoding work, and the number of cores, or whether you need a GPU, follows from that list.
- 02 ─ audience
Estimate viewers at the same moment and the bitrate each one pulls. The calculator further down turns that into a port size.
- 03 ─ delivery
Decide whether viewers are served from this machine or whether it hands segments to a CDN. Serving viewers directly needs a much wider port.
- 04 ─ rights
What you are entitled to broadcast is between you and the rights holder. Settle it before the first stream, not after the first complaint.
- 01 ─
The big night is the expensive night
on a meter or a shared hostThe stream that finds an audience turns into sustained egress at the moment metered billing is least forgiving.
hereUnmetered: ten viewers or ten thousand, the invoice does not move.
- 02 ─
Transcode and delivery pull different ways
on a meter or a shared hostTranscoding is bound by cores or a GPU, delivery by the port. Sizing one for the other wastes both.
hereCores or a GPU sized to the ladder, and a port sized to the audience, chosen separately.
- 03 ─
Shared cores drop frames
on a meter or a shared hostOn a shared host another tenant's burst lands on the same cores as your encoder.
hereSingle tenant: no shared cores, no neighbour in the encode path.
What to look for in the machine.
CPU transcoding scales with core count and clock; more renditions, more cores.
GPU transcoding trades flexibility for throughput per watt. The ladder decides, not the label.
Delivery is bound by the port, and the peak is the night that counts.
The servers that fit this today are marked under the processor on the price list. The shelf changes; what to look for in the machine does not.
Which port your audience needs.
Set the audience and your bitrate. Egress is one times the other; the rows show which port carries it.
- egress needed
- 5 Gbps
- smallest port
- 10 Gbps
- per hour on air
- 2.25 TB
- billed for it
- $0
carries over: port 10 Gbps
Questions to settle before ordering.
- 01 ─
Is there a GPU on the stock plans?
No. A GPU is available on a built-to-order machine. Tell us the codec and the ladder, and we come back with a build, a price and a date.
- 02 ─
Can the port run at full rate around the clock?
Yes. There is no transfer allowance and no overage: line rate every hour of every day, and the invoice does not change. The port is yours alone. The uplink behind it is shared, sized for the servers on it, and when it gets close to full we add capacity rather than hold anyone back.
The rest, for every machine: all questions and the terms.
- No transcoding service, no player, no packager, no DRM. Bring your own stack.[no]
- No guaranteed mitigation if a stream draws an attack.[no]
- What you are entitled to broadcast is between you and the rights holder.[limit]
Tell us what it serves.
The workload, the working set, where the users are. We come back with a machine sized to it, a price and a date.
alsounmetered servers · CDN origins · game servers · storage servers · download servers · database & compute · virtualisation hosts · blockchain node servers