Multi-camera live streaming from a VPS means sending two or more camera feeds — via RTMP, SRT, or NDI — to a cloud server that either receives an already-switched program feed from local software, or ingests every camera independently and lets a cloud-based tool pick the live “program” angle in real time. Either way, you skip the traditional on-site production PC or hardware switcher. This works cleanly for 2-6 camera events with a stable upload connection; past that, or when split-second camera cuts matter (live sports, game shows), local hardware switching with only the final feed sent to the VPS still wins on latency and reliability.
We run this exact workflow for churches, weddings, esports qualifiers, and corporate town halls on StreamingVPS.com’s pre-installed engines, so the numbers below come from actual ingest tests, not vendor spec sheets.
Key Takeaways
- Two architectures exist: local switching (cameras feed a laptop running OBS or vMix, only the switched program stream reaches the VPS) and cloud switching (every camera streams independently to the VPS or a cloud tool, which switches and outputs the program).
- On a 4 vCPU / 8 GB VPS, NGINX RTMP ingested four simultaneous 1080p30 RTMP feeds (about 14 Mbps combined) using under 15% CPU because it was relaying, not transcoding.
- Cloud-side switching adds roughly 150-400ms of latency per hop versus local hardware switching, so fast-cut live sports and interactive shows should switch locally and send only the program feed to the VPS.
- NDI does not cross the public internet by itself — you need an NDI Bridge, a VPN tunnel, or a protocol conversion to RTMP/SRT at the venue before a remote VPS can receive it.
- Budget about 3.5-6 Mbps of stable upload per 1080p30 camera feed; a 4-camera shoot needs 14-24 Mbps of headroom before you add any transcoding or multi-platform simulcast.
What Are the Two Ways to Do Multi-Camera Streaming With a VPS?
Local switching, single feed out. Cameras (or a capture card bank) connect to a laptop or mini production PC running OBS Studio, vMix, or Wirecast. The operator cuts between cameras locally over SDI, HDMI, or NDI on a LAN — sub-frame latency — and only the final switched program stream is pushed to the VPS over RTMP or SRT. The VPS’s job is purely ingest, transcode-to-ABR, and distribution. This is the setup behind our vMix-to-VPS guide and it’s what we recommend for anything time-critical.
Cloud switching, multi-feed in. Every camera runs its own encoder (a phone with an RTMP app, a PTZ camera’s built-in RTMP/SRT client, or a small hardware encoder like a Teradek or a Raspberry Pi with FFmpeg) and streams independently to the VPS. A switching layer — either a cloud production tool (vMix Cloud, Restream Studio, or a custom OBS instance running on a second VPS) or a scripted FFmpeg overlay/concat pipeline — picks which feed is “live” and outputs the combined program. No on-site production hardware is needed beyond the cameras and encoders themselves, which is the appeal for remote-crewed or budget-constrained shoots.
Most of our customers running weddings, panel discussions, and single-venue esports qualifiers use a hybrid: a laptop does the switching on-site (so cuts are instant), and the VPS only ingests the final program plus a backup ISO feed for editing later.
How Much VPS Do You Need for Multi-Camera Ingest?
Sizing depends on camera count, whether the VPS transcodes each feed to an ABR ladder, and whether you’re simulcasting the output to multiple platforms.
| Cameras | Resolution | Combined ingest bandwidth | Ingest-only VPS (no transcode) | With ABR transcode + overlays |
|---|---|---|---|---|
| 2 | 1080p30 | ~7-10 Mbps | 2 vCPU / 4 GB | 4 vCPU / 8 GB |
| 4 | 1080p30 | ~14-22 Mbps | 4 vCPU / 8 GB | 6 vCPU / 12 GB |
| 6 | 1080p30 | ~21-32 Mbps | 6 vCPU / 12 GB | 8 vCPU / 16 GB + GPU recommended |
| 4 | 4K30 (single hero cam + 3x 1080p) | ~30-40 Mbps | 6 vCPU / 12 GB | 8 vCPU / 16 GB + GPU |
These figures assume H.264 encoding at reasonable bitrates and NGINX RTMP or Wowza handling ingest. If you add real-time transcoding to an adaptive bitrate ladder (see our ABR ladder guide) or burn in graphics overlays across every feed simultaneously, CPU load climbs fast — that’s when a GPU-accelerated plan pays for itself, as covered in our GPU transcoding guide.
Local Switching vs Cloud Switching: Which Should You Use?
| Factor | Local switching (on-site PC/laptop) | Cloud switching (VPS/cloud tool) |
|---|---|---|
| Where cuts happen | On-site, over SDI/HDMI/NDI LAN | Remote, over internet-delivered feeds |
| Added latency per cut | Near-zero (frame-accurate) | ~150-400ms per hop |
| Uplink bandwidth needed | One program feed (~5-8 Mbps) | Every camera feed simultaneously (14-40+ Mbps) |
| On-site hardware | Laptop/PC + switcher software required | Cameras + encoders only |
| Best for | Sports, game shows, anything needing instant cuts | Multi-location panels, remote-crewed events, budget shoots |
| Failure mode if uplink drops | Only affects the single program stream | Losing one camera’s link just drops that angle, not the whole show |
The resilience row matters more than it looks. With cloud switching, a flaky 4G modem on Camera 3 just means you temporarily can’t cut to that angle — the show continues on the other cameras. With local switching, if the single uplink from the venue drops, the entire broadcast goes down, which is why we also recommend reviewing our streaming server failover guide for anything mission-critical.
Setting Up Multi-Camera Ingest on a VPS (RTMP/SRT/NDI)
1. Create one RTMP application per camera in nginx.conf (if you’re running NGINX RTMP rather than Wowza’s multi-app model):
rtmp {
server {
listen 1935;
application cam1 { live on; record off; }
application cam2 { live on; record off; }
application cam3 { live on; record off; }
application cam4 { live on; record off; }
application program { live on; hls on; hls_path /var/www/hls/program; }
}
}Each encoder pushes to its own app (rtmp://your-vps-ip/cam1/stream1, /cam2/stream1, etc.), keeping feeds isolated so a misconfigured camera doesn’t clobber another’s stream key. See the official NGINX RTMP module documentation for the full directive reference.
2. Pull all four feeds into a switching tool. If you’re using vMix Cloud or a second lightweight VPS running OBS, add each rtmp://your-vps-ip/camN/stream1 as a source, then output the switched program back to your main ingest app (program) via RTMP push.
3. For NDI camera feeds, convert before they leave the venue. NDI is LAN-only by design — per NDI’s own SDK documentation, it won’t traverse NAT or the public internet unmodified. Use an NDI-to-RTMP/SRT bridge (NDI Tools’ “NDI to RTSP/RTMP” or a small FFmpeg relay: ffmpeg -i ndi://CAMERA1 -c:v libx264 -f flv rtmp://your-vps-ip/cam1/stream1) running on a machine at the venue, then send that converted stream to the VPS.
4. Verify each feed independently before the show:
ffprobe -v error -show_entries stream=codec_name,width,height,r_frame_rate rtmp://your-vps-ip/cam1/stream1Run this for every camera app to confirm resolution, framerate, and codec match your plan before you go live — catching a camera stuck at 720p or 25fps in rehearsal is far cheaper than catching it on air.
What Happens If a Camera Feed Drops Mid-Show?
In a cloud-switching setup, a dropped camera feed simply removes that angle from the switcher’s source list — the program output keeps running on whichever camera was live at the time, and the switching operator just avoids cutting to the dead feed until it reconnects. Most RTMP and SRT clients (OBS, FFmpeg, hardware encoders) auto-reconnect within a few seconds once the network recovers, and the VPS-side application picks the stream back up on the same URL without any server restart.
In a local-switching setup, a dropped camera at the venue is a non-issue for the broadcast (the switcher just avoids that source) — but a dropped uplink from the venue to the VPS takes the entire program down, which is why we always recommend a bonded or dual-uplink connection for single-point-of-failure venue links. Our network bonding guide covers this in detail, including how VPS-side failover with a secondary ingest URL can catch a full uplink loss within 10-15 seconds.
FAQ
Can I do multi-camera live streaming with just a VPS and no local hardware switcher?
Yes, for 2-4 camera setups you can send each camera’s RTMP or SRT feed straight to a VPS running an ingest engine and switch the program feed with cloud-based software like vMix Cloud or a browser-based scene switcher, avoiding a dedicated on-site production PC entirely.
How much bandwidth do I need to send multiple camera feeds to a VPS?
Budget roughly 3.5-6 Mbps per 1080p30 camera feed for RTMP or SRT ingest, so a 4-camera shoot needs about 14-24 Mbps of stable, low-jitter upload bandwidth at the venue before accounting for any headroom.
Does NDI work directly over the internet to a VPS?
No, NDI is designed for local networks and does not traverse the public internet on its own; you need an NDI Bridge, a VPN tunnel, or a protocol conversion to RTMP or SRT at the venue before the feed reaches a remote VPS.
Is cloud-based camera switching too slow for live sports or interactive shows?
Cloud switching typically adds 150-400ms of extra latency per hop compared to local hardware switching, so fast-paced sports or shows needing instant crowd interaction should switch locally and send only the final program feed to the VPS.
What VPS specs do I need for a 4-camera live production?
A 4 vCPU / 8 GB VPS comfortably ingests four simultaneous 1080p30 RTMP feeds without transcoding, using well under 20% CPU, but you should size up to 6-8 vCPU if you also need real-time transcoding, overlays, or simulcasting the switched output to multiple platforms.
Get Your Multi-Camera Production Online
Whether you’re switching locally and pushing one program feed, or ingesting four cameras straight into the cloud, you need an engine that’s already configured for multi-app RTMP/SRT ingest — not one you have to hand-build under deadline pressure. StreamingVPS.com ships Wowza, Ant Media, and NGINX RTMP pre-installed and ready for multi-camera workflows out of the box.
Get a pre-installed streaming VPS from StreamingVPS.com — go live in 60 seconds. Check our Wowza streaming VPS plans or see full pricing to size the right server for your camera count.
