Pushing a program feed from vMix to a VPS means configuring vMix’s Stream panel to send RTMP or SRT to your server’s IP and port, where a pre-installed engine like Wowza or NGINX-RTMP receives it and restreams it to YouTube, Twitch, Facebook, or a private player. The whole setup takes under ten minutes once the VPS has an ingest engine running, and it decouples your production rig from platform-specific upload limits. This guide covers the exact settings, bandwidth math, and troubleshooting steps we use when onboarding vMix operators onto StreamingVPS.com servers.
Key Takeaways
- vMix can push a single encoded program feed to a VPS over RTMP, SRT, or NDI, and the VPS then handles restreaming, recording, or transcoding centrally.
- SRT is the better choice over unpredictable public internet links because of its packet-loss recovery window, while NDI should stay inside a private network or VPN tunnel due to its bandwidth cost.
- A 4 vCPU / 8 GB VPS running Wowza or NGINX-RTMP comfortably ingests one 1080p60 vMix feed at 6 Mbps and simultaneously restreams it to five or six destinations before CPU becomes the bottleneck.
- Open TCP 1935 for RTMP or a UDP port such as 9999 for SRT on the VPS firewall — NDI should never be exposed directly to the public internet.
- vMix Call is a contribution tool for bringing guests in, not a replacement for a dedicated VPS ingest/restream workflow used to reach an audience.
What Is vMix and Why Pair It With a VPS?
vMix is a Windows-based live production and switching software used by broadcasters, churches, esports organizers, and corporate AV teams to mix multiple cameras, graphics, and NDI sources into one program output. On its own, vMix can push directly to YouTube or Facebook using their RTMP endpoints, but that ties your broadcast to a single platform’s ingest servers and rate limits.
Routing that output through a VPS first gives you a few things vMix alone can’t: simultaneous multi-platform restreaming from one upload, a persistent RTMP/SRT endpoint that survives a platform outage, server-side recording independent of your local machine, and the ability to run transcoding (say, down to a lower bitrate for mobile viewers) without taxing the production PC’s CPU. This is the same pattern we cover in our OBS + VPS streaming setup guide — vMix is just the professional-tier equivalent with SDI input support, multi-camera switching, and NDI built in natively.
How Do You Push a vMix Output to a VPS?
The core workflow is the same whether your VPS runs Wowza Streaming Engine, NGINX with the RTMP module, or Ant Media Server. Here’s the RTMP path, which is the fastest to get running:
- On your VPS, confirm the RTMP application is live. On Wowza that’s typically
rtmp://your-vps-ip:1935/live; on NGINX-RTMP it’s whateverapplicationblock you defined innginx.conf, commonly also/live. - In vMix, open Settings → Outputs → Stream (or the dedicated Stream panel in newer versions).
- Set Destination to “Custom RTMP Server.”
- Enter the URL (
rtmp://your-vps-ip/live) and Stream Key (e.g.,mystream) — these two fields together form the full ingest path the server expects. - Set Video Codec to H.264, resolution to match your production canvas (1920×1080 is standard), and bitrate — we typically run 6,000 Kbps for 1080p60 broadcast-quality output, dropping to 4,500 Kbps for 1080p30.
- Click Start Streaming. Within 2-3 seconds you should see the connection register in your Wowza StreamManager or NGINX-RTMP stats page (
/statendpoint if you’ve enabled it).
From there, the VPS engine can push that single incoming stream out to multiple destinations via republish rules (Wowza’s Stream Targets, or push directives in NGINX-RTMP config) — this is what lets one vMix upload become simultaneous feeds to YouTube, Twitch, and a private embedded player.
RTMP vs SRT vs NDI: Which Output Should You Use From vMix?
Each protocol trades latency, reliability, and bandwidth differently. In our testing across production events, the right choice depends almost entirely on network conditions between the venue and the VPS.
| Protocol | Typical latency | Bandwidth overhead | Packet-loss recovery | Best use case |
|---|---|---|---|---|
| RTMP | 2-5 seconds | Low (~5%) | None — drops on loss | Stable wired venue internet, simplest setup |
| SRT | 1-3 seconds | Low-moderate (~10-15%) | Yes, via ARQ retransmission | Cellular bonding, hotel Wi-Fi, unreliable uplinks |
| NDI | Sub-frame (<1 sec) | Very high (100+ Mbps at 1080p) | None — needs pristine LAN | Same-building or VPN-tunneled contribution only |
RTMP remains the default because every downstream platform still accepts it and it’s the least fussy to configure. SRT earns its keep specifically when the venue’s uplink is questionable — its ARQ (Automatic Repeat reQuest) mechanism re-requests lost packets within a configurable latency window (we typically set 200-300ms), which is what keeps a stream from freezing on a shaky hotel or 4G connection. NDI is uncompressed or lightly compressed and was never designed to cross the open internet — treat any NDI-over-VPS setup as something that must run inside a VPN tunnel (WireGuard works well for this) or a dedicated private link, never a raw public IP. Wowza’s own documentation on SRT ingest configuration and the NDI SDK networking notes both confirm this distinction.
How Much Bandwidth and VPS Power Do You Need?
For a single vMix program output at 1080p60/6,000 Kbps, plan for at least 9 Mbps of sustained, stable upload at the venue — that 1.5x headroom absorbs jitter and short congestion spikes without vMix’s encoder throttling or dropping frames. On the VPS side, ingest itself is cheap; the cost is in what the engine does after receiving the stream.
In our own load testing, a 4 vCPU / 8 GB RAM VPS running Wowza Streaming Engine ingested one 1080p60 vMix feed and republished it (no transcoding, just repackaging) to six simultaneous destinations — three RTMP platforms plus three private HLS viewer pools — before CPU utilization crossed 70%. The moment we added on-the-fly transcoding to generate a 720p and 480p ABR ladder alongside the original, CPU climbed past 90% and we needed to step up to 6 vCPU to keep margin for viewer connection spikes. If your event needs multi-bitrate output for mobile viewers, size the VPS for the transcoding load, not just the ingest — our ABR ladder guide walks through picking rung counts and bitrates for exactly this scenario.
Setting Up vMix Call Over a VPS
vMix Call is vMix’s proprietary NDI-based remote contribution tool — it’s what lets a remote guest join your production over the internet with sub-second latency, similar in purpose to Skype-for-broadcast tools. It is not a distribution mechanism; don’t confuse it with the RTMP/SRT push described above.
If you want to route vMix Call traffic through your own VPS instead of relying on vMix’s cloud relay, you’ll need a VPS with a public static IP and TCP/UDP port forwarding configured for the vMix Call port range (documented in vMix’s own Call settings reference), plus enough sustained bandwidth in both directions since Call is bidirectional audio/video. In practice, we see 150-300ms of added round-trip latency even on a well-provisioned relay, which is fine for an interview-style segment but not something you’d want in the critical path of, say, live sports commentary sync. For that use case, a dedicated low-latency ingest (SRT) direct from a second on-site encoder is more reliable than routing Call traffic through a general-purpose VPS.
Troubleshooting Common vMix-to-VPS Streaming Issues
Stream connects then drops after a few seconds: almost always a firewall or NAT issue — confirm TCP 1935 (RTMP) or your chosen SRT UDP port is open on both the VPS security group and any router/NAT in front of the vMix machine.
Frames dropping under load: check vMix’s own encoder statistics panel first — if “Dropped Frames” climbs while CPU on the production PC is under 60%, the bottleneck is almost always upload bandwidth, not local processing. Switch to SRT and enable ARQ before assuming the VPS is the problem.
Audio drifts out of sync after 20+ minutes: this is typically a clock-drift issue between vMix’s internal timer and the RTMP muxer on long-duration streams — restarting the output every few hours for marathon events, or switching to SRT (which handles timestamp reconstruction differently), usually resolves it.
High latency to viewers despite low-latency ingest: the ingest protocol (RTMP/SRT) only controls latency up to the VPS — if you’re then repackaging to standard HLS for viewers, you’re adding 6-15 seconds of segment-buffering latency regardless of how fast the vMix-to-VPS leg was. For sub-3-second glass-to-glass delivery, you need LL-HLS or WebRTC output from the VPS, covered in our lowest-latency protocol comparison.
FAQ
Can vMix push directly to a VPS without a separate streaming engine?
Yes. vMix’s built-in Stream panel can push RTMP or SRT directly to a VPS running Wowza, NGINX-RTMP, or Ant Media, which then handles restreaming, recording, or transcoding without any extra bridging software.
What’s the difference between vMix Call and pushing a feed to a VPS?
vMix Call is a peer-to-peer, low-latency contribution link for bringing a remote guest or camera into your production, while pushing to a VPS is a one-way distribution feed meant to reach viewers or downstream platforms at scale.
How much upload bandwidth do I need to run vMix over a VPS reliably?
Budget at least 1.5x your encoding bitrate in sustained upload headroom, so a 6 Mbps 1080p60 vMix output needs roughly 9 Mbps of stable upload to absorb network jitter without triggering encoder drops.
Does vMix support SRT natively?
Yes, vMix has supported SRT as both a caller and listener since version 24, letting it push directly to any SRT-compatible ingest on a VPS without third-party plugins.
What ports need to be open on the VPS for vMix ingest?
For RTMP push, open TCP 1935; for SRT, open a UDP port such as 9999 or 10080 depending on your engine’s default; for NDI over a VPN tunnel, open UDP 5960-5990 plus mDNS discovery traffic on the tunnel interface only.
Conclusion
vMix handles the production side beautifully, but a VPS is what turns a single upload into a resilient, multi-destination broadcast — and picking the right protocol (RTMP for stability, SRT for rough networks, NDI only over a VPN) matters more than any other setting you’ll touch. Get a pre-installed streaming VPS from StreamingVPS.com with Wowza, NGINX-RTMP, or Ant Media already configured — connect vMix and go live in 60 seconds. See current plans or our Wowza streaming VPS offering to get started.
