Running live streams through Twitch or YouTube is fine until you need control they don’t give you — custom latency, multiple simultaneous streams, audience-specific routing, or a setup where the platform takes no cut of monetization. Self-hosted streaming on a dedicated server solves all of these, but the hardware and configuration requirements are specific. Getting…
What Live Streaming Actually Demands from a Server
A live streaming server performs three distinct operations, each with different resource profiles:
Ingest: Receives the encoded stream from your broadcasting software (OBS, Restream, vMix) via RTMP (Real-Time Messaging Protocol). CPU-light — the server is just accepting a network connection and writing to disk or memory.
Transcoding: Re-encodes the incoming stream to multiple quality levels (1080p, 720p, 480p, 360p) so viewers with different bandwidth can watch without buffering. CPU-intensive. This is where most servers encounter their limits.
Delivery: Sends the HLS (HTTP Live Streaming) or DASH segments to viewers via a CDN or directly. Bandwidth-intensive. For 100 concurrent viewers at 4Mbps each, that’s 400Mbps of sustained outbound bandwidth.
Your server needs to handle all three simultaneously, potentially for multiple concurrent streams.
Hardware Requirements by Use Case
Single Stream, Up to 500 Concurrent Viewers
Minimum viable configuration: InMotion Essential ($99.99/month, 64GB DDR4, 2×1.92TB NVMe)
At 1080p30 with x264 medium preset transcoding to 3 quality levels, expect 4-6 CPU cores fully utilized during active streaming. The Essential server’s processor handles this comfortably. At 500 concurrent viewers receiving 4Mbps streams, outbound bandwidth hits 2Gbps — within the burstable 10Gbps envelope.
RAM is not the constraint at this scale — 8-16GB is sufficient for the streaming stack. 64GB provides headroom for the OS and any other services running alongside the stream.
Multiple Streams or 500-5,000 Concurrent Viewers
Recommended: InMotion Elite or Extreme ($199.99-349.99/month)
Multi-stream operations or high viewer counts need either more CPU cores for concurrent transcoding or enough RAM to buffer stream segments aggressively. At 2,000 concurrent viewers receiving 4Mbps HLS delivery, you’re at 8Gbps sustained — approaching the burstable limit and a strong argument for guaranteed unmetered 10Gbps bandwidth.
The AMD EPYC 4545P’s 16 cores with 32 threads is well-suited to concurrent transcoding workloads. Software transcoding using libx264 or libvpx scales linearly with core count — two concurrent 1080p streams consume roughly double the CPU of one.
Delivery at Scale (5,000+ Concurrent Viewers)
At this scale, the dedicated server handles ingest and transcoding; a CDN handles delivery. The math is straightforward: 5,000 viewers at 4Mbps is 20Gbps of delivery bandwidth, which exceeds any single server’s realistic output. A properly configured CDN pulls the HLS stream from your server once and distributes it to viewers — your server sees a small number of CDN PoP connections rather than 5,000 individual viewer connections.
Setting Up Nginx-RTMP on Linux
Nginx with the RTMP module is the standard open source streaming server. On AlmaLinux or Ubuntu:
apt–get install nginx libnginx–mod–rtmp –y
# AlmaLinux/Rocky
dnf install nginx –y
# Compile RTMP module or use community packages
Basic Nginx configuration for ingest and HLS delivery:
# /etc/nginx/nginx.conf
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
# HLS delivery
hls on;
hls_path /var/www/html/hls;
hls_fragment 3s;
hls_playlist_length 60s;
# Transcode to multiple qualities
exec_push ffmpeg –i rtmp://localhost/$app/$name
–c:v libx264 –b:v 3000k –s 1920×1080 –r 30
–c:a aac –b:a 128k
–f flv rtmp://localhost/hls/$name_1080p
–c:v libx264 –b:v 1500k –s 1280×720 –r 30
–c:a aac –b:a 128k
–f flv rtmp://localhost/hls/$name_720p
–c:v libx264 –b:v 600k –s 854×480 –r 30
–c:a aac –b:a 96k
–f flv rtmp://localhost/hls/$name_480p;
}
application hls {
live on;
hls on;
hls_path /var/www/html/hls;
hls_fragment 3s;
hls_nested on;
}
}
}
http {
server {
listen 80;
location /hls {
types {
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
root /var/www/html;
add_header Cache–Control no–cache;
add_header Access–Control–Allow–Origin *;
}
}
}
This configuration accepts an RTMP stream from OBS on port 1935, transcodes to three quality levels via FFmpeg, and serves HLS segments via HTTP on port 80.
OBS Stream Settings:
Server: rtmp://your-server-ip/live
Stream Key: any string (becomes the stream name)
Encoder: x264 or NVENC (if GPU available)
Bitrate: 6,000 Kbps for 1080p60 source
Stream to Twitch and YouTube Simultaneously via Dedicated Server
A dedicated RTMP server can restream to multiple platforms simultaneously, eliminating the need for a paid restreaming service.
live on;
# Push to Twitch
push rtmp://live.twitch.tv/app/YOUR_TWITCH_STREAM_KEY;
# Push to YouTube
push rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY;
# Keep local HLS copy
hls on;
hls_path /var/www/html/hls;
}
Your broadcaster sends one stream to your dedicated server; the server fans it out to Twitch, YouTube, and your own HLS endpoint simultaneously. This requires outbound bandwidth equal to the sum of all destination bitrates — typically 6,000-18,000 Kbps depending on platform requirements.
FFmpeg Transcoding Optimization
FFmpeg’s default settings prioritize quality over CPU efficiency. For live streaming where real-time performance is required, tune the preset and tune flags:
–c:v libx264 \
–preset veryfast \ # Critical for real–time: veryfast or ultrafast
–tune zerolatency \ # Reduces encoding delay
–b:v 3000k \
–maxrate 3000k \
–bufsize 6000k \
–g 60 \ # Keyframe interval (2x framerate for 30fps)
–sc_threshold 0 \ # Disable scene change detection (adds latency)
–c:a aac \
–b:a 128k \
–f flv rtmp://localhost/hls/$name_1080p
The -preset veryfast setting reduces encoding quality slightly compared to slow or medium, but reduces CPU usage by 60-70% — essential for real-time transcoding on a CPU that’s handling multiple streams or other workloads simultaneously.
FFmpeg’s encoding guide covers the tradeoffs between preset values in detail.
Firewall Configuration for Streaming
Open the ports your streaming stack requires:
nft add rule inet filter input tcp dport 1935 accept
# Allow HTTP delivery of HLS segments
nft add rule inet filter input tcp dport 80 accept
nft add rule inet filter input tcp dport 443 accept
# Restrict RTMP ingest to known broadcaster IPs if possible
# Replace with actual broadcaster IP
nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 1935 accept
nft add rule inet filter input tcp dport 1935 drop
Leaving RTMP open to the internet allows anyone to stream to your server. IP-restricting the ingest port prevents unauthorized use of your server’s bandwidth.
Storage for Stream Recording
Recorded streams at 1080p consume approximately 1GB per 10 minutes of recording at 12-15 Mbps. For regular streaming operations, plan storage accordingly:
2 hours of recording per day: ~12GB/day, ~360GB/month
InMotion’s Essential server includes 2×1.92TB NVMe — sufficient for approximately 3,000 hours of recordings before requiring archival
application live {
live on;
record all;
record_path /var/recordings;
record_suffix -%d%m%Y-%H%M%S.flv;
record_max_size 1000M; # Split at 1GB to keep files manageable
}
InMotion’s Premier Care backup storage (500GB) provides an off-server copy of important recordings. For longer-term archival, configure rclone to sync the recordings directory to S3-compatible object storage on a scheduled basis.
Related reading: Network Latency Optimization for Dedicated Servers | CDN Origin Server Optimization