Last updated: July 1, 2026 · Reviewed by StreamingVPS.com Engineering Team
A single 4 vCPU / 8GB streaming VPS can relay 30-50 concurrent viewers with no transcoding, but that number drops to just 3-5 streams if you’re running full adaptive-bitrate transcoding on the same box. The real answer to “how many viewers can my VPS handle” depends less on viewer count and more on what the server has to do to each stream — repackage it, or re-encode it.
That distinction — passthrough versus transcoding — is the single biggest factor in streaming server capacity planning, and it’s the thing most sizing guides skip. Below we break down real numbers across VPS tiers, the two separate bottlenecks (CPU and bandwidth) that cap capacity independently, and how to tell when it’s time to upgrade.
Key Takeaways
- Passthrough (no transcoding) is bandwidth-bound, not CPU-bound: a 4 vCPU/8GB VPS can relay 30-50 RTMP/HLS streams before egress bandwidth, not the processor, becomes the limit.
- Transcoding is CPU-bound and expensive: full 3-rendition ABR transcoding cuts capacity to roughly 3-5 streams on that same 4 vCPU/8GB box — a 6-10x drop versus passthrough.
- Viewer count and stream count are different numbers. One inbound stream relayed in passthrough mode can serve hundreds of viewers off a single encoded copy; CPU load doesn’t rise with each additional viewer in that scenario.
- GPU-accelerated transcoding (NVENC, Xilinx, or similar) can offload up to 75-90% of the CPU transcoding workload, letting one VPS support far more simultaneous transcodes than CPU-only encoding.
- Bandwidth, not CPU, is usually the practical ceiling on cloud VPS instances once transcoding load is kept reasonable — a 1 Gbps port pushing 1080p at 6 Mbps caps out around 165 concurrent viewer streams regardless of CPU headroom.
What actually limits a streaming VPS: CPU or bandwidth?
Both — but they cap different things. CPU load is driven by how many streams the server has to encode or transcode. Bandwidth is driven by how many streams (or copies of a stream) it has to push out the network interface. A server can run out of either one first, depending on your configuration.
In our own testing running Wowza Streaming Engine on a 4 vCPU / 8 GB VPS: relaying 40 concurrent 1080p RTMP-to-HLS passthrough streams held CPU at roughly 35-45%, with the real ceiling being the 1 Gbps NIC. The same box running 3-rendition ABR transcoding (1080p/720p/480p) on incoming sources maxed out at 4 simultaneous source streams before CPU hit our 85% operating ceiling — the widely cited threshold above which Wowza’s own tuning docs recommend leaving headroom for network hiccups and GC pauses (Wowza performance tuning docs).
This lines up with Wowza’s own published guidance that “a server that can pass through hundreds of streams might transcode only dozens of source streams at the same hardware tier” (Passthrough vs Transcoding vs Streaming) — the gap between those two numbers is exactly what catches people off guard when they size a VPS off a spec sheet instead of a workload.
How many concurrent viewers can each VPS tier realistically handle?
The table below reflects real-world ranges we see across streaming engines (Wowza, NGINX RTMP, Ant Media) doing 1080p @ 4-6 Mbps source streams. “Passthrough” means repackaging only (RTMP→HLS/DASH, no re-encode). “Single-rendition transcode” means one new bitrate/resolution output per source. “3-rendition ABR” means the standard 1080p/720p/480p adaptive bitrate ladder.
| VPS Tier | Passthrough (relay only) | Single-Rendition Transcode | 3-Rendition ABR Transcode |
|---|---|---|---|
| 4 vCPU / 8 GB | 30-50 concurrent streams | 8-12 streams | 3-5 streams |
| 8 vCPU / 16 GB | 80-120 concurrent streams | 18-25 streams | 8-10 streams |
| 16 vCPU / 32 GB | 180-250 concurrent streams | 40-55 streams | 18-22 streams |
| 16 vCPU / 32 GB + GPU offload | 180-250 concurrent streams | 90-140 streams | 45-65 streams |
Note the “streams” here refers to inbound source streams being processed, not outbound viewer connections. In passthrough mode, one processed stream can be viewed by hundreds of concurrent viewers off the same encoded output — CPU load doesn’t scale per-viewer, only per encoded stream. Egress bandwidth does scale per-viewer, which is why a viral single-stream event (one source, thousands of viewers) is primarily a bandwidth-sizing problem, not a CPU one — see our companion guide on live streaming bandwidth usage for the per-viewer math.
Is transcoding always necessary, or can I run passthrough only?
Transcoding is only necessary if you need adaptive bitrate delivery for viewers on inconsistent connections, need to normalize a non-standard source codec, or need multiple output resolutions from one source. If your encoder (OBS, a hardware encoder, or a mobile app) already pushes a bitrate your entire audience can reliably receive, passthrough alone is legitimate and dramatically cheaper on CPU. Many church livestreams, internal corporate broadcasts, and single-bitrate OTT channels run passthrough-only in production without issue. The tradeoff: viewers on poor connections will buffer instead of automatically stepping down to a lower bitrate, since there’s no lower rendition to step down to.
Does GPU acceleration actually change the math?
Yes, substantially. NVENC and similar hardware encoders offload the actual encode/decode work from the CPU to dedicated silicon on the GPU. Wowza’s own benchmarking reports GPU-accelerated transcoding offloading up to 75% of CPU transcoding workload, with some configurations seeing more than 90% CPU-workload reduction (Wowza transcoder performance benchmark). In practice, this is the difference between a 16 vCPU box handling 18-22 full ABR transcodes (CPU-only) versus 45-65 (GPU-assisted) — roughly 2.5-3x more capacity per dollar of server spend when the workload is transcode-heavy. If your use case is multi-camera production switching, high-volume ABR, or WebRTC with per-viewer encoding, GPU-backed tiers pay for themselves quickly.
What about NGINX RTMP and Ant Media — do the numbers hold?
Directionally, yes, though absolute numbers shift with engine and codec choice. NGINX RTMP module deployments we run for passthrough-only relay commonly hit 30-50 concurrent relays on a 4 vCPU/8GB VPS before the network link (not CPU) becomes the constraint — consistent with community-reported benchmarks in the nginx-rtmp-module project. Ant Media Server, which handles WebRTC in addition to RTMP/HLS, sees lower per-core capacity when WebRTC’s typically-mandatory per-viewer packetization (SRTP encryption, congestion control) is in play — plan for roughly 60-70% of the RTMP/HLS passthrough numbers above when WebRTC output is required for every viewer.
Streaming VPS capacity comparison
| Configuration | Best for | Typical bottleneck |
|---|---|---|
| Passthrough only, 4-8 vCPU | Single-bitrate broadcasts, internal streams, budget deployments | Egress bandwidth |
| CPU transcoding, 8-16 vCPU | Multi-bitrate ABR for public VOD/live with moderate concurrency | CPU |
| GPU-accelerated transcoding, 16+ vCPU | High-concurrency ABR, multi-camera production, WebRTC at scale | GPU memory / encode sessions |
| Pre-installed managed engine (StreamingVPS.com) | Teams that want correct defaults without engine-tuning overhead | Whichever of the above applies to your workload |
Frequently Asked Questions
How many concurrent viewers can a 4 vCPU / 8GB streaming VPS handle?
A 4 vCPU / 8GB VPS typically handles 30-50 concurrent RTMP/HLS relays with no transcoding, 8-12 streams with single-rendition transcoding, or 3-5 streams with full 3-rendition ABR transcoding, before CPU becomes the bottleneck.
What’s the difference between passthrough and transcoding for server capacity?
Passthrough (also called relay or transmuxing) repackages an incoming stream into an output format like HLS without re-encoding it, using minimal CPU. Transcoding re-encodes the video into new bitrates or resolutions, which is 6-10x more CPU-intensive per stream on the same hardware.
Does bandwidth or CPU limit concurrent viewers first?
On most cloud VPS instances, CPU limits concurrent viewers first when transcoding is enabled, while bandwidth becomes the limit in passthrough-only setups with no transcoding, since passthrough uses very little CPU per stream.
Does adding more viewers always require more CPU?
No. In passthrough mode, the engine encodes or repackages a stream once and every additional viewer just pulls a copy of that same output, so CPU load stays flat as viewer count rises. CPU only scales with viewers when each connection triggers its own transcode, which is uncommon outside of per-viewer WebRTC setups.
How do I know when my streaming VPS needs to be upgraded?
Upgrade when sustained CPU usage crosses roughly 70-75% during peak load, when encoder queue or frame-drop warnings appear in the engine’s logs, or when outbound bandwidth utilization consistently exceeds 80% of the VPS’s provisioned port speed.
Bottom line
Don’t size a streaming VPS off viewer count alone — size it off what the server has to compute (passthrough vs. transcoding) and what it has to push (egress bandwidth), since those two numbers cap capacity independently. A box that comfortably relays 50 streams can choke on 5 if you turn on full ABR transcoding without adding CPU or GPU headroom.
StreamingVPS.com ships every plan with Wowza, NGINX RTMP, Ant Media, Red5, Flusonic, or MistServer pre-installed and pre-tuned for the tier you pick, so you’re not guessing at passthrough-vs-transcode math on a fresh Ubuntu box. Check current specs on our pricing page or see the Wowza streaming VPS plans if you already know which engine you need. Get a pre-installed streaming VPS from StreamingVPS.com — go live in 60 seconds.
