Ninja class size is the practical limit on how many students can watch (or interact with) a VDO.Ninja teaching stream before your home internet or your computer becomes the bottleneck - docs.vdo.ninja 
The key idea is that a simple VDO.Ninja push/view link is usually peer-to-peer. If ten students open the same teacher VIEW link, that typically means ten simultaneous viewer connections, and your upstream load can scale roughly with the number of viewers - docs.vdo.ninja
# The default bandwidth model
For simple push/view links the documented default target video bitrate is about 2500 kbps (2.5 Mbps). That is a decent “talking head” baseline, but it means your upload usage grows quickly with each extra student - docs.vdo.ninja
You can treat “per student cost” as roughly 2.5 Mbps plus overhead for audio, retransmissions, and protocol headroom. In practice it is often safer to budget closer to about 3 Mbps per viewer for planning, then validate with a real test - docs.vdo.ninja
# Your connection, in plain numbers
With a reported upload 77.9 Mbps and download 472 Mbps. For teaching, upload is the main limit when students are watching your camera - the download is plenty for watching one student’s screen share while teaching - docs.vdo.ninja
A sensible home-teaching rule is to avoid saturating the uplink, so leave headroom for network variability and for everything else on your connection. If you reserve roughly 30 percent headroom, you have about 55 Mbps of “comfortable” upstream budget for teaching traffic.
At the default 2.5 Mbps target (plan as ~3 Mbps per viewer), that suggests a comfortable watch-only class size around 15–20 students before you start living on the edge of your upstream, assuming your computer also keeps up.
If we deliberately lower bitrate to around 1500 kbps, you can often push closer to 25–35 viewers on bandwidth alone, at the cost of softer detail and more compression artifacts.
If you raise bitrate to 6000 kbps for “very crisp camera”, the comfortable watch-only class size can drop toward the high single digits or low teens.
These are bandwidth-only estimates. CPU, Wi-Fi, and awkward networks can reduce the real number - docs.vdo.ninja - docs.vdo.ninja
# The other constraint: your computer’s encoding load
Even if your upstream is strong, your machine still has to capture and encode video in real time, and the load can grow as more viewer connections are added. If you see stutter or increasing lag over time, it can be a sign your encoder is overloaded rather than your internet line - docs.vdo.ninja
A practical mitigation is boring but effective: teach from a wired ethernet connection, close unnecessary apps, and avoid running extra heavy video workflows at the same time unless you need them.
# How to scale above one student There are two distinct “scaling problems” in wiki teaching. The first is “many students watching the teacher”. That stresses the teacher’s upstream in peer-to-peer mode. The second is “many students actively talking and sharing screens”. That is a different product category, and it is where a meeting tool or SFU-based setup usually makes more sense. VDO.Ninja gives you levers for the first problem, and a different architecture for larger broadcast-style groups.
# Knob 1: cap the bitrate in the VIEW link
VDO.Ninja lets you request a bitrate using URL parameters. This is the cleanest way to trade quality for capacity while keeping the setup simple - docs.vdo.ninja
The key mental model is that lowering bitrate reduces “per student cost”, which increases class size, but only up to the point where your picture becomes too compressed for what you are teaching.
If you are teaching wiki mechanics, a lower bitrate is often fine because the talking head does not need cinema quality.
# Knob 2: use quality presets instead of explicit resolution
The `&quality` parameter is a preset system that tends to be less brittle than forcing explicit width and height, especially across different devices and browsers - docs.vdo.ninja
If you are teaching, you usually want stability and low latency more than maximum resolution.
# Knob 3: teach “one active student at a time” For “Two Way Ninja” sessions, the easiest scalable pattern is to keep the class in watch mode, but rotate who is actively screen sharing. That means you always have one incoming screen share to watch, while many students can still watch your teacher camera stream. This pattern avoids the complexity of a full multi-party call while still enabling hands-on coaching.
# Knob 4: offload distribution with Meshcast or WHIP/WHEP
If you want to broadcast to many viewers without your home uplink scaling linearly with the number of students, you want an SFU-style distribution step. VDO.Ninja calls this Meshcast, and it also supports WHIP/WHEP style hosting options, including Cloudflare-based publishing flows - docs.vdo.ninja - vdo.ninja
The advantage is that you publish once to a server, and the server redistributes to students. The trade-off is that it is no longer “pure peer-to-peer end-to-end”, and you need to think more carefully about privacy and link sharing - docs.vdo.ninja
# The relay trap
If a connection ends up using a TURN relay, it can add latency and reduce quality. VDO.Ninja documents relay mode as an emergency/testing approach, not the default desired path - docs.vdo.ninja - docs.vdo.ninja
This matters for class size because “a few students on hostile networks” can create support overhead and degrade the feel of the session even if your bandwidth is ample.
# What the teacher needs to install
For the basic Ninja teaching setup, the teacher generally installs nothing. You need a modern browser, permissions for camera/mic, and your ATEM Mini presenting itself as a webcam input.
If we later decide to scale up production quality, OBS becomes an optional tool for composing scenes, but it is not required for the minimal workflow.
If we decide to scale to larger classes reliably, you may end up deploying or using a hosted SFU path such as Meshcast-like distribution or WHIP/WHEP hosting, which is more “service setup” than “software install” - docs.vdo.ninja - vdo.ninja
# Pragmatic recommendation
With 77.9 Mbps upload, you can comfortably teach a watch-only class of around 15–20 students at default settings, and you can likely push higher if you deliberately cap bitrate and keep your teaching machine stable.
If we want to teach above that regularly, plan on an SFU distribution step (Meshcast or WHIP/WHEP) so you are not relying on “one home uplink times N viewers” as your scaling strategy - docs.vdo.ninja - docs.vdo.ninja