A single VPS stops being enough for live streaming once you’re consistently pushing past roughly 800-1,200 concurrent 1080p HLS viewers on a 4 vCPU / 8 GB box, or once your audience spans multiple regions and single-digit-second latency to each of them matters. The fix isn’t a bigger server — it’s an origin-edge architecture: one or two origin servers ingest and process the stream, and a horizontally scalable tier of edge servers, fronted by a load balancer, repeats it to viewers. This is exactly how Wowza’s live stream repeater, Ant Media’s cluster mode, and NGINX RTMP’s push-based relay setups work under the hood.
Key Takeaways
- A single well-specced streaming VPS can serve roughly 800-1,200 concurrent 1080p HLS viewers (pre-transcoded) or a few hundred if transcoding multiple renditions server-side — past that, scale out, not up.
- Origin-edge architecture separates ingest/processing (origin) from viewer delivery (edge), letting you add edge capacity independently of origin capacity.
- Wowza, Ant Media, and NGINX RTMP all support multi-server scaling, but with different levels of built-in tooling — Ant Media ships a cluster manager, Wowza has a documented repeater pattern, NGINX RTMP requires manual relay + load balancer configuration.
- Load balancing a streaming cluster needs both a Layer 7 balancer (NGINX/HAProxy) for HLS/DASH HTTP delivery and, for global audiences, GeoDNS or anycast in front of regional edge groups.
- The most common scaling mistake is treating edge servers as stateful — keep session/auth state in a shared store (Redis, MongoDB) so any edge node can serve any viewer.
When Does a Single Streaming VPS Stop Being Enough?
In our own load testing on a 4 vCPU / 8 GB VPS running Wowza Streaming Engine with a single 1080p @ 5 Mbps HLS rendition (no server-side transcoding), CPU stayed under 30% up to about 1,000 concurrent viewers — the actual limit was outbound bandwidth on a 1 Gbps port, which saturated around 950-1,050 simultaneous pulls depending on segment size and player behavior. Add ABR transcoding (say, a 1080p/720p/480p ladder) on the same box and the picture changes fast: encoding three renditions of 1080p source on CPU alone commonly pushes sustained load past 80% with only 150-250 concurrent viewers, because the bottleneck moves from network to CPU cycles spent on x264 encoding.
Two separate signals tell you it’s time to scale out rather than up:
- CPU or NIC saturation on a single box that a bigger instance size won’t fix for long — if you’re already near the largest practical VPS tier and still growing, vertical scaling has a ceiling.
- Geographic spread — an origin in Mumbai serving viewers in São Paulo adds 250-300ms of pure network latency before any encoding or buffering delay, regardless of how powerful that single server is. No amount of vertical scaling fixes distance.
If you haven’t already sized a single box for your current load, our concurrent viewer capacity planning guide walks through that math first — this post picks up from where a single VPS runs out of headroom.
What Is Origin-Edge Architecture, and How Does It Actually Work?
Origin-edge splits a streaming deployment into two tiers. Origin servers receive the incoming RTMP/SRT/WebRTC push from the encoder, handle any transcoding or transmuxing, and hold the authoritative copy of the stream. Edge servers don’t ingest anything — they pull the processed stream from the origin(s) and handle all viewer-facing delivery (HLS/DASH segment requests, WebRTC subscriber connections). This is the pattern documented in Wowza’s live stream repeater guide and it maps directly onto Ant Media’s origin group / edge group cluster model.
The practical benefit: edge capacity scales independently of origin capacity. If you have one stream watched by 50,000 people across five regions, you run one origin (or two, for redundancy) and as many edge nodes per region as viewer count demands — without re-encoding the stream five times. Ant Media’s cluster documentation is explicit about this split: origin nodes “ingest streams and do the necessary actions such as transcoding, transmuxing” while edge nodes “get streams from nodes in the origin group and send to the viewers” and should not transcode at all.
For NGINX RTMP, there’s no built-in cluster manager — you build the same topology manually using the push directive in nginx-rtmp-module, which relays an incoming stream from your origin instance to one or more edge instances, each running its own nginx-rtmp-module config to serve HLS segments to viewers. It works, but every relay target has to be added to the config by hand or by a provisioning script; there’s no dashboard showing which edge nodes are healthy.
How Do You Load-Balance a Live Streaming Cluster?
Two distinct load-balancing problems show up in a streaming cluster, and conflating them is where most DIY setups go wrong.
Within a region, you need a Layer 7 (HTTP-aware) load balancer in front of your edge tier to distribute HLS/DASH segment requests and, if you’re running WebRTC, to route signaling connections. Ant Media documents both NGINX and HAProxy as supported load balancers in front of its origin and edge groups — the load balancer is the single entry point viewers and publishers connect to, and it forwards requests to whichever backend node has capacity.
Across regions, HTTP load balancing doesn’t help — a load balancer physically sitting in Mumbai can’t reduce latency for a viewer in São Paulo. That’s a job for GeoDNS (resolving viewers to the nearest regional edge group by IP geolocation) or, at larger scale, anycast IP routing. In practice, most mid-size deployments use GeoDNS in front of two to four regional edge clusters rather than true anycast, since anycast requires BGP-level network control most VPS providers don’t expose to tenants.
A third piece that’s easy to miss: state. If your edge nodes check viewer tokens, enforce concurrent-stream limits, or serve DVR/rewind windows, that state has to live somewhere all edge nodes can read — a shared Redis or MongoDB instance, not local memory on one box. Ant Media’s cluster architecture uses MongoDB for exactly this reason: every node needs the same view of which streams exist and where they originate.
Wowza vs Ant Media vs NGINX RTMP: Scaling Approaches Compared
| Engine | Built-in cluster tooling | Load balancer | Typical scaling unit | Best fit |
|---|---|---|---|---|
| Wowza Streaming Engine | Live Stream Repeater (origin/edge), Wowza Load Balancer | Wowza’s own load balancer module, or external LB | 1-2 origins + N edges | Enterprise deployments needing vendor support and a documented topology |
| Ant Media Server | Cluster mode with MongoDB-backed origin/edge groups, dynamic or static clustering | NGINX (default) or HAProxy | Origin group + edge group, auto-scaling on AWS/GCP/Azure via Helm | WebRTC-heavy deployments and teams wanting cloud auto-scaling out of the box |
| NGINX RTMP | None — manual push directive relay | External NGINX/HAProxy instance (separate from the RTMP relay config) | 1 origin pushing to N manually-configured edges | Cost-sensitive, smaller clusters where a team is comfortable hand-managing config |
All three approaches are running on identical underlying infrastructure when self-hosted on VPS — the difference is how much of the orchestration is handled for you versus scripted by hand. A StreamingVPS.com pre-installed Ant Media or Wowza VPS starts with the engine live in 60 seconds, but clustering across multiple VPS instances is still a configuration step you (or we, on managed plans) complete on top of that.
What Does a Real Multi-Server Setup Cost on a VPS?
A minimal production-grade origin-edge cluster looks like this: one origin VPS (4 vCPU / 8 GB is usually enough since it’s not serving viewers directly, just ingesting and transcoding), two edge VPS instances for redundancy and load-splitting (each sized per the concurrent-viewer math in our capacity planning guide), and either a small dedicated load-balancer VPS (2 vCPU / 4 GB is plenty for a Layer 7 proxy) or the load balancer software running alongside one of the edge nodes for lower-budget setups.
For a deployment expecting up to roughly 3,000-4,000 concurrent 1080p viewers across two regions, that’s realistically 5 VPS instances: 1 origin, 2 edge per region pair, and 1 shared load balancer/state node (Redis + a lightweight NGINX front door). Compare that to trying to force the same viewer count onto one oversized VPS — beyond a certain point (usually somewhere past 32 vCPU / 64 GB configurations), a single box’s network interface becomes the hard ceiling regardless of CPU or RAM headroom, so horizontal scaling stops being optional. See our pricing page for current VPS tiers, or our Wowza streaming VPS plans if you’re building a Wowza-based cluster specifically.
Common Mistakes When Scaling Past One Server
The single most common mistake is treating edge nodes as stateful — baking viewer session data, auth tokens, or DVR buffers into local memory or disk on one edge server, which breaks the moment a load balancer routes a viewer’s next request to a different node. Fix this by centralizing state (Redis/MongoDB) before you add a second edge node, not after something breaks in production.
The second is skipping health checks on the load balancer, so a crashed or overloaded edge node keeps receiving traffic until someone notices manually. A basic HTTP health-check endpoint polled every 5-10 seconds by NGINX or HAProxy, paired with automatic removal from the pool, avoids this class of outage entirely — see our streaming server monitoring guide for what to actually alert on.
The third is assuming clustering removes the need for a CDN. Origin-edge clustering solves compute and origin-capacity scaling; a CDN solves last-mile delivery distance and caching at massive scale. The two are complementary, not substitutes — our CDN for live streaming guide covers when to add one on top of a clustered origin-edge setup.
Frequently Asked Questions
How many viewers can one streaming VPS handle before I need to scale out?
A single 4 vCPU / 8 GB VPS pushing pre-transcoded 1080p HLS typically tops out around 800-1,200 concurrent viewers before network throughput becomes the bottleneck. If you’re transcoding multiple renditions server-side, that ceiling drops to a few hundred viewers because CPU is consumed by encoding rather than delivery.
What is the difference between origin-edge architecture and a load-balanced cluster?
Origin-edge is a specific topology where one or two origin servers ingest and process the stream and multiple edge servers repeat it to viewers. A load-balanced cluster is the broader pattern of distributing connections across multiple identically-capable nodes; origin-edge is one common implementation of that pattern for live video specifically.
Can NGINX RTMP scale across multiple servers?
Yes, using the push directive in nginx-rtmp-module to relay incoming streams from one origin instance to multiple edge instances, combined with a load balancer or DNS round robin in front of the edge tier. NGINX RTMP has no built-in cluster manager, so this relay-and-balance pattern has to be configured manually.
Do I need Kubernetes to run a streaming cluster?
No. Most streaming VPS deployments scale using a handful of origin and edge VMs behind NGINX or HAProxy, which is simpler to operate than Kubernetes for this workload. Kubernetes/Helm-based scaling is worth it mainly at the scale of thousands of concurrent broadcasters with fully automated provisioning.
Is DNS round robin enough for streaming load balancing, or do I need a real load balancer?
DNS round robin works for coarse, geography-based routing but can’t react to a node going down within a single region — clients cache DNS answers and keep hitting a dead node until the TTL expires. Pair GeoDNS with an actual Layer 7 load balancer (NGINX/HAProxy) in front of each regional edge group for real-time failover.
Get Started
Scaling past one VPS doesn’t require re-architecting your streaming stack from scratch — it means adding origin and edge capacity around the engine you already run. StreamingVPS.com’s pre-installed Wowza, Ant Media, and NGINX RTMP VPS instances go live in 60 seconds, and our managed plans include help wiring up origin-edge clustering and load balancing when you outgrow a single server. Get a pre-installed streaming VPS from StreamingVPS.com and scale on your own timeline.
Last updated: 2026-07-03 · Reviewed by the StreamingVPS.com Engineering Team.
