How to size a self-hosted streaming server: cores, memory and bandwidth

"How big a server do I need?" has two separate answers. Processor and memory are set by how many streams you convert. Bandwidth is set by how many people watch. Mixing the two up is the most common sizing mistake.

Where the processor goes

Receiving a stream and passing it on unchanged is cheap: the server copies packets from one socket to another. The expensive part is transcoding, producing extra qualities so a viewer on a weak connection still gets a picture. Each extra quality means decoding the source, scaling it and encoding it again, live, without falling behind.

So the processor question is: how many streams, times how many extra qualities, at what resolution and frame rate? Encoding cost rises roughly with pixels per second, so a 1080p60 rendition costs about twice a 1080p30 one, and 720p30 a bit under half of 1080p30. The encoder preset matters as much as resolution: faster presets trade compression for processor time.

Exact figures depend on the processor generation and settings, which is why any honest sizing tool should tell you whether its numbers were measured on hardware like yours. Leave 30–40% headroom: an encoder that touches 100% falls behind, and live video cannot catch up later.

Bandwidth: the viewers' half

Outgoing bandwidth is plain multiplication:

egress = concurrent viewers × bitrate they watch

A modest event shows how quickly it grows. Five hundred people watching at 1080p and 5 Mbps need 2.5 Gbps; the same audience on 720p at 3 Mbps needs 1.5 Gbps.

Three ways to bring that number down:

• Offer lower qualities. Viewers on phones pick 720p or 480p; adaptive players do it for them. That is the reason to spend processor on a ladder.
• Put a CDN in front of HLS. Segments are ordinary files and cache well, so the server sends each one once per edge, not once per viewer.
• Restream big audiences to platforms. Send one copy to YouTube or Facebook and let their networks carry the crowd, while your own server keeps the private and interactive viewers.

Memory and disk

Memory is rarely the bottleneck for live video: each converted stream needs a few hundred megabytes for decoder and encoder buffers, and passthrough streams need far less. Plan 8 GB as a floor, 16 GB for a few dozen converted streams.

Disk, on the other hand, grows forever if you record. That is arithmetic too:

GB per hour = bitrate in Mbps × 0.45
6 Mbps × 0.45 ≈ 2.7 GB per hour per stream

A 24/7 camera at 6 Mbps writes about 65 GB a day, close to 2 TB a month. Decide how long you keep recordings before you buy disks, or move old ones to object storage.

A worked example

Measure before you buy

Every rule of thumb above is a starting point. The only number that settles it is a test on your own hardware: run your real streams with your real qualities, and watch processor use, dropped frames and the network port at your expected peak.