If you have ever asked yourself how many listeners can my stream and server handle, the honest answer is: it depends on three numbers you can measure in minutes. Take your server’s upload bandwidth, divide it by your stream’s bitrate, and you get the maximum concurrent listeners your infrastructure will support. A 100 Mbps upload serving a 128 kbps audio stream can handle roughly 780 simultaneous listeners before the connection saturates.
I have run self-hosted radio stations, tested Icecast and SHOUTcast setups on home fiber, and migrated to dedicated servers once audiences grew. The math never changes, but the variables around it do. This guide walks you through the formula, the factors that tighten or loosen your ceiling, and the exact thresholds where it pays to upgrade or add a CDN.
Table of Contents
- The Core Formula: Bitrate x Listeners = Bandwidth
- What Determines Your Stream Server Capacity
- Real-World Capacity by Bitrate and Server Type
- Hardware Factors That Limit Concurrent Listeners
- Protocol Impact: RTMP vs HLS vs DASH Capacity
- Transcoding vs Pass-Through and Why It Matters
- Home Hosting vs VPS vs Dedicated Server Capacity
- Listener Limit Errors and How to Fix Them
- When to Upgrade or Add a CDN for Scaling
- Frequently Asked Questions
- Final Thoughts on Stream and Server Capacity
The Core Formula: Bitrate x Listeners = Bandwidth
The single most useful calculation in streaming is bandwidth equals bitrate times concurrent listeners. Express your server’s available upload speed in kilobits per second (kbps), divide by the stream bitrate in the same unit, and the result is your listener ceiling.
For example, a 10,000 kbps upload (roughly a 10 Mbps home connection) divided by a 128 kbps audio bitrate yields about 78 concurrent listeners. Drop the bitrate to 64 kbps and the same pipe handles around 156 listeners. Crank the bitrate to 320 kbps for high-quality audio and you are back down to 31 listeners.
Quick Capacity Table
Use this table as a starting point. Real-world numbers run a little lower because of protocol overhead, TCP retransmissions, and headroom for peaks.
- 10 Mbps upload, 64 kbps stream: ~156 listeners
- 10 Mbps upload, 128 kbps stream: ~78 listeners
- 100 Mbps upload, 128 kbps stream: ~780 listeners
- 1 Gbps upload, 128 kbps stream: ~7,800 listeners
- 1 Gbps upload, 3000 kbps video stream: ~330 viewers
- 10 Gbps upload, 5000 kbps 1080p stream: ~2,000 viewers
Treat these as 80 percent of theoretical capacity. Always reserve 20 percent for spikes, system traffic, and encoding overhead.
What Determines Your Stream Server Capacity
Bandwidth is the headline number, but four other factors quietly cap your audience. Ignore them and your stream stutters even when the math says you have room.
1. Server Upload Speed
The bottleneck is almost always upstream capacity, not CPU. Home connections advertise fast download speeds but cripple uploads at 5-20 Mbps. A symmetric fiber line or a data center server with 1 Gbps+ upload removes that ceiling.
2. Stream Bitrate and Codec
Higher bitrate means better sound and picture, but each listener consumes more bandwidth. MP3 and AAC at 128 kbps sound fine for talk radio. Music-focused streams often run 192-320 kbps. Video at 1080p typically sits between 3,000 and 6,000 kbps.
3. Number of Concurrent Connections
Operating systems and software impose hard limits. The classic SHOUTcast server capped at 1,024 concurrent listeners on legacy systems. Modern Linux can handle far more, but each connection adds about 10 kbps of metadata and control traffic on top of your bitrate.
4. Encoding Workload
Transcoding burns CPU. A single 1080p transcode can saturate a modern desktop CPU. If you want multiple bitrates for adaptive streaming, plan dedicated cores or offload the work to a GPU.
Real-World Capacity by Bitrate and Server Type
Theory is helpful, but I want to show you what real configurations deliver. Here is what I have tested, plus what hosting providers publish for production tiers.
Home Internet Connection
A typical 10 Mbps upload cable or DSL line, even with overhead, supports 60-100 audio listeners or 1-2 video viewers at 1080p. Latency is usually high and bursting is unreliable. Acceptable for a small community stream, painful for a public radio station.
VPS Hosting
A 1 Gbps VPS (most providers cap port speed at 1 Gbps shared) reliably serves 500-1,500 audio listeners at 128 kbps. CPU and RAM are usually sufficient for a single stream with basic metadata. Expect around 200-400 video viewers at 1080p.
Dedicated Server
A dedicated server with a 1 Gbps unmetered port and modern Xeon or EPYC hardware handles 5,000-10,000 audio listeners comfortably. For video at 4 Mbps, expect 200-250 concurrent viewers without transcoding, more with adaptive bitrate ladders.
Multi-Server or CDN-Backed Setup
Once you cross 10,000 audio listeners or 500 video viewers, you are in CDN territory. The origin server feeds edge nodes across regions, and each edge serves a fraction of the audience. A properly designed CDN-backed setup scales into the millions.
Hardware Factors That Limit Concurrent Listeners
Bandwidth is the obvious limit. CPU, RAM, and storage quietly decide whether your stream survives a traffic spike.
CPU and Transcoding
Each transcoded output (say, 1080p, 720p, and 480p from one source) roughly triples your CPU load. A modern 8-core CPU can transcode one 1080p feed into 2-3 outputs and still serve a few hundred listeners. Beyond that, you need a streaming server with hardware acceleration or a beefier CPU.
RAM
Each concurrent connection uses a small chunk of RAM for buffers. 100 audio listeners typically consume under 200 MB. 1,000 listeners might use 1-2 GB. Plan 4 GB minimum for a small dedicated stream server, 16 GB or more for serious deployments.
Network Interface
A 1 Gbps NIC is the practical minimum for any non-trivial stream. Above 1 Gbps, you need link aggregation (LACP) or a 10 Gbps uplink. Also check whether your provider meters traffic. A 1 Gbps unmetered port is worth more than a 10 Gbps port with a 50 TB cap.
Storage (for VOD and Recording)
If you record your live stream for replay, plan storage. A 1080p stream at 5 Mbps writes roughly 2.2 GB per hour. A 24/7 audio stream at 128 kbps writes about 56 MB per hour, or 1.3 GB per day. Use NVMe SSDs for active recordings and rotate to bulk storage weekly.
Protocol Impact: RTMP vs HLS vs DASH Capacity
The protocol you choose changes how listeners connect and how many your server can juggle. Each has tradeoffs between capacity, latency, and compatibility.
RTMP (Real-Time Messaging Protocol)
RTMP uses persistent TCP connections and offers sub-2-second latency. The connection cost is higher than HLS, so a server typically handles 20-30 percent fewer concurrent RTMP viewers than HLS viewers on identical hardware. Most modern browsers no longer support RTMP playback natively, so it is now primarily used for ingest from encoders like OBS.
HLS (HTTP Live Streaming)
HLS uses short video segments delivered over HTTP. Each listener fetches a few files per minute rather than holding one persistent socket, which makes it easier for servers to scale and for CDNs to cache. HLS supports millions of viewers with proper infrastructure, at the cost of 6-30 seconds of latency.
DASH (MPEG-DASH)
DASH is functionally similar to HLS for capacity purposes. It delivers segmented HTTP chunks and supports adaptive bitrate. Choose DASH if you need codec flexibility (AV1, HEVC) or international standards compliance. Capacity numbers track HLS closely.
WebRTC and SRT
WebRTC and SRT target ultra-low-latency use cases (sub-second). They use UDP and are connection-heavy. A WebRTC server typically handles far fewer concurrent viewers per node than HLS, often 100-500 per server instance, but it offers real-time interactivity.
Transcoding vs Pass-Through and Why It Matters
Pass-through (also called relay or restream) means your server forwards the source feed without re-encoding. Transcoding means your server decodes and re-encodes the feed, often into multiple bitrates.
Pass-Through Capacity
Pass-through is bandwidth-bound, not CPU-bound. A server with 1 Gbps upload can pass through 7,800+ audio listeners at 128 kbps without breaking a sweat on CPU. This is the most efficient mode for serving a single bitrate.
Transcoding Capacity
Transcoding is CPU-bound. A single 1080p to 720p transcode uses roughly one modern CPU core. Transcoding to three outputs (1080p, 720p, 480p) typically uses 2-4 cores. Servers built for transcoding need 8+ cores, fast RAM, and ideally hardware acceleration (NVENC, Quick Sync, or ASIC encoders).
When Transcoding Pays Off
If your audience includes viewers on slow mobile networks, transcoding into multiple bitrates (an adaptive bitrate ladder) lets each viewer pick a quality their connection can handle. Without it, your single high-bitrate stream simply will not play for those users.
Home Hosting vs VPS vs Dedicated Server Capacity
Where you put it determines how far you can scale before the next move. Here is a side-by-side comparison based on a 128 kbps audio stream.
- Home 10 Mbps upload: 60-80 listeners, high latency, no SLA
- Home 50 Mbps symmetric fiber: 300-400 listeners, low latency, still no SLA
- VPS 1 Gbps shared port: 500-1,500 listeners, professional uptime, modest cost
- Dedicated 1 Gbps unmetered: 5,000-10,000 listeners, full hardware control, higher cost
- CDN-backed origin: 100,000+ listeners, scales horizontally, costs scale with usage
For audiences under 500 listeners, a quality VPS is usually the sweet spot. For 500-5,000, go dedicated. Above 5,000, plan a CDN from day one.
Listener Limit Errors and How to Fix Them
When your stream hits capacity, it usually fails in one of three ways. Knowing which one you hit points to the fix.
Error 1: Connection Refused
Your server has reached its configured maximum listener count (often set deliberately as a safety cap). Increase the MaxListeners setting in your server config, restart the service, and monitor CPU and bandwidth to confirm you have headroom.
Error 2: Buffering or Dropouts
Listeners connect but the stream stutters or pauses. This is almost always bandwidth saturation. Check your server’s outbound traffic. If it is near your port speed, you need more upload capacity, not more connections.
Error 3: HTTP 503 or Timeout
HLS and DASH viewers see this when the origin cannot keep up with segment requests. Solutions include caching segments at a CDN, increasing the server’s file descriptor limits, and adding more origin nodes behind a load balancer.
Diagnostic Checklist
Before increasing any limit, run through these checks: confirm your upload speed with a sustained speed test, check CPU load during peak hours, verify the OS file descriptor limit (Linux defaults are often too low), and review your server logs for the specific error message. Guessing wastes hours. Reading the logs takes minutes.
When to Upgrade or Add a CDN for Scaling
You will outgrow a single server eventually. Here are the thresholds where scaling stops being optional.
Under 500 Concurrent Listeners
A single VPS handles this comfortably. Focus on uptime, monitoring, and content quality rather than hardware upgrades.
500 to 5,000 Listeners
Move to a dedicated server with 1 Gbps unmetered bandwidth. Add basic monitoring and alerting. Consider a second origin for redundancy if downtime would cost you audience or revenue.
5,000 to 50,000 Listeners
Add a CDN. Cloudflare, AWS CloudFront, Fastly, or a specialist provider like Wowza or Edgio handle edge delivery so your origin serves fewer but heavier requests. Adaptive bitrate ladders become worth the transcoding cost.
50,000+ Listeners
You need multi-region origins, automatic failover, and CDN-grade monitoring. At this scale, the question shifts from “how many listeners can my stream and server handle” to “how do I architect for elasticity.” Plan capacity in tiers and budget for usage-based CDN pricing.
Frequently Asked Questions
How many users can a server handle?
A single server’s listener capacity equals its upload bandwidth divided by the stream bitrate. A 100 Mbps upload serving a 128 kbps audio stream can handle roughly 780 concurrent listeners, assuming the server has enough CPU and RAM.
How many requests per second can one streaming server handle?
Modern Linux servers with proper tuning handle 10,000 to 100,000 HTTP requests per second for static HLS segments. Live RTMP ingest typically tops out at 2,000 to 5,000 connections per server because each one holds a persistent socket.
How many people can stream from a Plex server at once?
Plex streams typically run between 4 Mbps and 20 Mbps per 1080p transcode. A home server on a 10 Mbps upload connection handles only 1 direct stream. For more viewers, you need a faster connection or hardware-accelerated transcoding.
How many gigs do you need for streaming services?
Bandwidth and data usage are different measurements. A 128 kbps audio stream uses about 56 MB per hour. A 4 Mbps video stream uses roughly 1.8 GB per hour. Multiply by your target listener count and hours of operation to estimate monthly data needs.
How do I increase stream listener capacity?
Lower the bitrate, upgrade upload bandwidth, optimize your server’s TCP settings, raise the OS file descriptor limit, add a CDN, or migrate to a dedicated server. The right choice depends on your current bottleneck.
Final Thoughts on Stream and Server Capacity
Answering how many listeners can my stream and server handle comes down to one formula, one bottleneck, and one honest read of your logs. Start with bandwidth divided by bitrate, confirm the math with a real load test, and upgrade the part that actually limits you. For most small broadcasters, a tuned VPS is more than enough. For everyone else, plan the upgrade path now and you will not panic the day your audience doubles.