What Is NDI, and Can You Actually Run It Over a VPS?

NDI (Network Device Interface) is Vizrt/NewTek’s IP video protocol for moving uncompressed or lightly-compressed video between devices on a local network with near-zero latency — and yes, you can run it over a VPS or the public internet, but only through NDI Bridge’s WAN tunnel or an HX/transcoded variant, not by exposing NDI’s native LAN discovery to the internet. Full-bandwidth NDI was engineered for gigabit LANs, not routed WAN links, so a VPS’s role in an NDI workflow is almost always as a discovery relay, a bandwidth-reducing bridge endpoint, or a conversion point into RTMP/SRT for public delivery — not as a drop-in NDI receiver.

Key Takeaways

• NDI wasn’t designed for the internet. A single 1080p60 full-bandwidth NDI stream can use 100–150+ Mbps, and NDI’s default mDNS-based discovery relies on LAN multicast that doesn’t traverse routers, NAT, or most cloud VPC networks.
• NDI Bridge is the supported way to cross a WAN. Introduced as a standalone tool and folded into NDI 6, NDI Bridge tunnels NDI between two fixed endpoints over TCP/UDP port 5990 by default, with end-to-end encryption — the Host side needs a public IP and port forwarding.
• NDI HX3 (8–40 Mbps) and HX2 (2–16 Mbps) make VPS-based NDI realistic. These compressed variants use H.264/HEVC hardware encoding, cutting bandwidth by roughly 90% compared to full NDI, which is what makes remote contribution over normal broadband or a VPS uplink workable.
• Streaming engines don’t natively ingest NDI. Wowza, Ant Media, and NGINX-RTMP all expect RTMP, SRT, RTSP, or WebRTC input — the standard workaround is converting NDI to RTMP inside OBS (via the DistroAV plugin, formerly OBS-NDI) or vMix before the feed reaches your VPS.
• On cloud infrastructure, run a Discovery Service instead of chasing multicast. NDI’s own cloud guidance recommends a small Windows or Linux instance running the NDI Discovery Service rather than trying to enable multicast routing on a VPC.

What Is NDI, Exactly?

NDI is a royalty-free IP video standard originally developed by NewTek (now part of Vizrt) that lets production equipment — cameras, switchers, graphics systems, OBS, vMix, PTZ controllers — discover each other and exchange full-frame, low-latency video and audio over a standard Ethernet network, without SDI cabling. It’s become the default “IP video glue” in broadcast, worship AV, corporate AV, and esports production because devices announce themselves on the network and any NDI-aware application can pull in any published source with sub-frame latency.

The tradeoff is bandwidth. NDI’s flagship “full bandwidth” mode uses light, visually-lossless intra-frame compression rather than the aggressive inter-frame compression RTMP/HLS streams use, which is why it looks and behaves like SDI-over-IP on a LAN but becomes impractical the moment you try to push it across the public internet at the same bitrate.

Can NDI Really Run Over the Internet or a VPS?

Yes, but not by pointing an NDI receiver at a VPS’s public IP and expecting it to “just work” the way RTMP does. Two things stand in the way: bandwidth (100+ Mbps per stream is unrealistic on most upload links) and discovery (NDI’s default source announcement uses mDNS/multicast, which routers, NAT, and cloud VPC networks generally block or don’t propagate).

Vizrt’s own solution is NDI Bridge, which tunnels an NDI connection between two fixed endpoints — for example a production laptop at a venue and a VPS in a datacenter — over a single well-defined port instead of relying on LAN multicast. NDI Bridge Host/Join can also run over an existing VPN, which is the pattern most touring production teams and church AV teams actually use: a WireGuard or OpenVPN tunnel to the VPS, with NDI Bridge running on top of it.

For deployments inside a cloud VPC specifically, NDI’s official cloud guidance is blunt about it: enabling true multicast in a cloud environment requires standing up a transit gateway with multicast support, which is nontrivial, so “the easiest solution to enable NDI Discovery and registration is to set up a Discovery Service” — a lightweight Windows or Linux instance whose only job is to answer discovery requests, rather than trying to replicate LAN-style multicast in the cloud.

How Much Bandwidth Does NDI Need on a VPS?

This is the number that decides whether an NDI-over-VPS workflow is realistic on your available uplink. NDI ships in three practical tiers, and the difference between them is roughly an order of magnitude at each step:

In practice, we’ve seen a single NDI HX3 1080p60 contribution feed hold steady at 30–35 Mbps over a wired connection into an NDI Bridge Host running on a 4 vCPU / 8 GB VPS, with headroom to spare on CPU since the transcoding happens on the sending side when hardware encoding is available. The VPS itself, when it’s only relaying or running the Discovery Service, barely registers CPU load — the heavy lifting is the H.264/HEVC encode, which NDI Bridge documentation notes requires Intel Quick Sync or NVIDIA NVENC hardware acceleration to run in real time. The standing rule from NDI’s own bandwidth planning guidance is to never exceed 80% of your uplink capacity, leaving headroom for TCP retransmission and burst traffic — the same rule of thumb we apply when sizing RTMP ingest links for Wowza streaming VPS instances.

How Do You Set Up NDI Bridge on a VPS?

A minimal remote-contribution setup looks like this:

1. Provision a Linux or Windows VPS with a public IP address. If you’re only running the NDI Discovery Service (no transcoding), a small instance is enough; if the VPS itself is doing NDI HX encoding/decoding, you’ll need one with GPU access (Quick Sync or NVENC), which most standard cloud VPS tiers don’t include — this is one case where a GPU-enabled instance or an on-prem encoder is genuinely the better fit.
2. Forward the NDI Bridge port (TCP/UDP 5990 by default) on your VPS’s firewall/security group, and assign a static IP so the configuration doesn’t drift.
3. Run NDI Bridge in Host mode on the VPS side and Join mode on the remote production site, or run both ends over an existing VPN tunnel if you’d rather not expose the port directly to the internet.
4. Set the transcoding format. Choose “Do Not Transcode” if both ends have full-bandwidth capacity (rare over WAN), “NDI HX” with H.264 or HEVC for a compressed WAN-friendly link, or let the receiving end request “NDI High Bandwidth” only when it’s genuinely needed.
5. Use NDI Groups to control which sources are visible to the remote endpoint, so you’re not exposing every camera and graphics feed on your production network to a bridge running on a public VPS.
6. Monitor RTT and packet loss in the Bridge statistics panel — persistent packet loss on the VPS side usually means the uplink is saturated and it’s time to drop to NDI HX2 or add a second bonded connection, similar to the guidance we cover in our network bonding for live streaming post.

Does Wowza, Ant Media, or NGINX-RTMP Support NDI Natively?

Honestly, not out of the box, and this is the tradeoff worth being upfront about. Wowza’s NDI story historically ran through NewTek’s MediaDS hardware appliance, which paired dedicated hardware with Wowza Streaming Engine to translate NDI sources for distribution — it wasn’t a software feature you’d get by installing Wowza on a generic VPS. Ant Media Server and NGINX-RTMP have no native NDI ingest at all as of this writing.

The practical, widely-used path is a conversion step on the production side: bring your NDI sources into OBS Studio using the DistroAV plugin (formerly known as OBS-NDI), switch/mix them as needed, and then have OBS push the program output to your VPS over RTMP or SRT, exactly the way you’d configure OBS for any other OBS + VPS streaming setup. vMix supports the same pattern natively. This means NDI stays where it’s good — fast local switching between cameras and graphics — while RTMP/SRT does what it’s good at: crossing the public internet reliably into your Wowza, Ant Media, or NGINX-RTMP instance.

NDI vs. SRT vs. RTMP: Which Should You Use for Remote Contribution?

If you’re deciding between these for a remote production, the honest answer depends on what side of the link you’re solving for: NDI (or NDI Bridge) is the right tool for connecting production equipment to each other, while SRT or RTMP is the right tool for getting that finished program feed onto a public-facing VPS.

FAQ

Is NDI the same thing as RTMP?
No. NDI is a LAN-first, low-latency IP video protocol for production switching, while RTMP is built for pushing an encoded stream over the open internet to a media server. They solve different problems and are often used together in the same workflow.

What port does NDI Bridge use by default?
NDI Bridge listens on TCP/UDP port 5990 by default on the Host side, and the Host requires a public IP with that port forwarded. The port can be changed if it conflicts with another service.

Can I run an NDI Discovery Service on a Linux VPS?
Yes. NDI’s official cloud guidance recommends running a lightweight NDI Discovery Service on a basic Windows or Linux instance rather than trying to configure multicast routing in a cloud VPC, since most cloud networks don’t support the mDNS discovery NDI uses on a LAN.

Do I need a GPU on my VPS to run NDI Bridge?
Only if that VPS is performing NDI HX transcoding (H.264/HEVC via Intel Quick Sync or NVIDIA NVENC). A VPS that’s only running the Discovery Service or relaying full-bandwidth NDI without transcoding doesn’t need one.

Should I use NDI or RTMP to send video into my streaming VPS?
For public live streaming into Wowza, Ant Media, or NGINX-RTMP, use RTMP or SRT, since none of those engines decode NDI natively. Use NDI for switching between local cameras and graphics, then convert to RTMP/SRT with OBS (DistroAV) or vMix before the feed leaves your production network.

Getting NDI-Sourced Streams Onto a VPS

NDI and VPS-based streaming aren’t competitors — NDI handles the local production side, and a VPS running a pre-installed engine handles public delivery. If your workflow already brings feeds together in OBS or vMix, streamingvps.com’s pre-installed Wowza, Ant Media, NGINX-RTMP, Red5, Flusonic, and MistServer engines are ready for that RTMP or SRT handoff the moment your program feed leaves the production network — live in 60 seconds, no manual engine setup required. See streaming VPS plans or get a pre-installed Wowza VPS to pair with your NDI-based production rig.