A dedicated server for video and streaming
There are two jobs here, and they hit different hardware. Serving finished video is limited by the uplink and the disks, while the CPU barely works. Transcoding is limited by the CPU: a single 1080p x264 stream on the veryfast preset eats several cores. Size them separately and split them onto different machines as you grow.
- Size the uplink as "bitrate times concurrent viewers" plus 20% headroom for spikes.
- Transcoding is software: an E5-2680v4 with 28 threads handles several simultaneous 1080p streams, but only a test gives the exact number.
- The 30 TB allowance on Dedicated Start US is roughly 11,000 viewing hours at a 6 Mbit/s bitrate.
- HLS segments are written and read as many small files: NVMe removes latency that a sequential read test never shows.
- Keep the archive off the working disks: an extra 1 TB HDD is $15/month, offloading to external storage is $10/month.
How much uplink your viewers need
| Quality and bitrate | 100 Mbit/s (Start DE) | 500 Mbit/s (Start FR) | 1 Gbit/s (Pro and above) |
|---|---|---|---|
| 720p, 3 Mbit/s | about 25 viewers | about 130 | about 260 |
| 1080p, 6 Mbit/s | about 13 | about 65 | about 130 |
| 4K, 20 Mbit/s | about 4 | about 20 | about 40 |
These numbers already include the 20% headroom: without it, the first surge of viewers turns into buffering for everyone at once. An unmetered uplink removes the volume question, but port width stays a hard ceiling, which is covered in the article on the server uplink and traffic limits. Gigabit unmetered comes with the Pro and Enterprise plans, including the US facility: the configurations are on the dedicated servers in the USA page.
Transcoding: measure it, do not guess
How many streams a CPU will carry depends on the preset, the resolution and the content of the frame. The only honest method is to encode into nothing and read the speed factor.
# Debian/Ubuntu
apt-get install -y ffmpeg
# RHEL/AlmaLinux/Rocky (RPM Fusion repository)
dnf install -y ffmpeg
# encode into /dev/null: the speed= figure is what you need
ffmpeg -i source.mp4 -c:v libx264 -preset veryfast -b:v 6M \
-c:a aac -b:a 128k -f null /dev/null 2>&1 | tail -3A speed= value above 1x means the stream encodes faster than real time. Keep a factor of two in reserve: at speed=2x one CPU carries roughly two such streams, and beyond that frames start dropping. How to turn this into a plan choice is covered in the article on choosing a server processor.
HLS packaging and delivery
For browser playback the de facto standard is HLS: the stream is cut into 2-6 second segments, the playlist is refreshed, and plain nginx serves everything.
# three renditions in one pass, 4-second segments
ffmpeg -re -i rtmp://127.0.0.1/live/stream \
-filter_complex "[0:v]split=3[v1][v2][v3];[v2]scale=-2:720[v2o];[v3]scale=-2:480[v3o]" \
-map "[v1]" -c:v:0 libx264 -b:v:0 6M \
-map "[v2o]" -c:v:1 libx264 -b:v:1 3M \
-map "[v3o]" -c:v:2 libx264 -b:v:2 1200k \
-preset veryfast -g 96 -sc_threshold 0 \
-f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments \
-master_pl_name master.m3u8 /var/www/hls/v%v/index.m3u8 \
> /var/log/ffmpeg-hls.log 2>&1 &
# confirm segments really appear and old ones are removed
watch -n 2 'ls -1 /var/www/hls/v0 | wc -l'Keeping the segment directory on tmpfs is convenient: a live stream is overwritten anyway, and the disk is spared thousands of small writes. For recordings kept on disk, the difference between drive types is covered in the article on NVMe, SATA SSD and HDD in a server.
Storing the archive
Keep working disks and the archive apart. Pro plans give 2x1 TB NVMe in RAID1 and Enterprise US gives 4x1 TB NVMe in RAID10; for the archive you add a 1 TB HDD at $15/month or offload recordings to external storage at $10/month. Which is better on cost and delivery speed is easier to decide with the comparison in the article on S3 cloud storage.
Location decides as much as hardware: the further the viewer, the longer the playlist takes to start and the more often buffering kicks in during peaks. The measurement procedure is in the article on choosing a server location.
The 30 TB allowance on Dedicated Start US looks generous right up to the first successful broadcast: at 6 Mbit/s it covers roughly 11,000 viewing hours, which is about a hundred viewers across a month of regular streams. Calculate the volume in advance and take unmetered if the audience is growing. The second trap is running transcoding on the same server as delivery with no resource limits: ffmpeg takes every core, nginx starts serving segments late, and viewers see buffering while the uplink sits idle. Cap the encoder with systemctl set-property ffmpeg.service CPUQuota=60% and verify the result from player logs rather than from "it looks fine": a rising stall count at a stable bitrate means you are CPU bound.
Key takeaways
- Delivery is limited by the uplink and transcoding by the CPU; size them separately.
- Uplink width is bitrate times viewers plus 20%; gigabit unmetered holds about 130 viewers at 1080p.
- Measure transcoding capacity with ffmpeg and
-f null, read the speed factor, and keep a factor of two in reserve. - HLS segments belong on tmpfs; the archive belongs on a separate HDD at $15/month or in external storage at $10/month.
- 30 TB on Start US is roughly 11,000 viewing hours at 1080p; a growing audience needs unmetered.