# VDO.Ninja: peer-to-peer remote cameras for OBS without a build step

> VDO.Ninja is a browser-based WebRTC frontend that feeds remote phone and laptop cameras into OBS and other studio software. This review covers how the static frontend is served, what the repository does and does not include, and where the self-hosting story stops.

**steveseguin/vdo.ninja** — VDO.Ninja is a powerful tool that lets you bring remote video feeds into OBS or other studio software via WebRTC.

- Repository: https://github.com/steveseguin/vdo.ninja
- Website: https://vdo.ninja
- Stars: 4,060 · Forks: 1,221
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/steveseguin-vdo-ninja

## The problem VDO.Ninja solves in a live production

Getting a remote guest's camera into a studio setup usually means asking them to install something, or routing their feed through a conferencing tool that adds latency and compresses the image. VDO.Ninja takes a different route: the guest opens a link in a browser, allows camera access, and the video is carried over WebRTC. The README describes the result as "Direct peer-to-peer video transfer in most cases," with the qualifier doing real work, since a direct path is not guaranteed on every network.

The audience is narrow and specific. It is for streamers and producers who already run OBS, vMix or similar software and need a camera that is not physically attached to the machine doing the mixing. The README lists smartphone wireless webcam use and a director control room with group chat among the features, which points at multi-guest shows rather than solo recording. The repository topics include obs, vmix, studio and low-latency, and the alternative frontends listed in the README (a mixer app with custom layouts, a WHIP/WHEP client, a whiteboard, an esports feed manager) confirm that the project is aimed at production workflows rather than general video calling.

## How the WebRTC path is assembled: signaling, STUN and TURN

The README separates the browser client from the services it depends on. Signaling is what establishes an ordinary room and the peer connection. STUN helps each side discover its network address. TURN relays the traffic when a direct connection cannot be established. Only the first of those three is present in this repository as a client-side concern; the README states that install.md links to a separate handshake-server project and describes configuring the client for it.

This split explains the phrase "in most cases" in the feature list. A peer-to-peer path works when both ends can reach each other, and falls back to a relay when they cannot. That fallback is not optional infrastructure you can skip if you care about reliability across restrictive networks, and it is the part the repository deliberately does not ship. The README is direct about the boundary: hosting the frontend does not deploy the production authentication, signaling, relay, or call-in backends.

The repository does include self-hosting examples. turnserver.md, turnserver_basic.conf and the .sample files are described as optional TURN configuration examples, with the explicit caveat that the website does not execute them and that placeholder settings must be replaced before use. Treat them as a starting point for your own TURN deployment, not as a turnkey configuration.

## Serving the frontend locally and running the translation checks

The README states that there is no frontend build step or package installation required. To host it yourself you serve the repository from an HTTPS-enabled static web server. For a local preview, the README gives this command from the repository root:

```bash
python -m http.server 8080 --bind 127.0.0.1
```

Open http://localhost:8080/ afterward. The README notes that a local preview serves the frontend only, and that normal rooms still connect to the configured signaling and relay services, so do not expect a working room just because the page loads. Use HTTPS when accessing the site from other devices.

Before publishing changes, the README says to run the repository's translation checks, which require Node.js:

```bash
node .github/ci-validateTranslations.js
node .github/ci-checkTranslationKeys.js
```

Those two scripts check translation keys and do not cover browser behavior. The README says to test the affected publishing, viewing, recording, or device-selection flows separately. That is a fair description of the coverage: passing both scripts says nothing about whether a room still connects.

## Develop, alpha and release branches, and why the hosted app lags

VDO.Ninja runs three tracks. The develop branch, which is the default branch here, is described in the README as a preview or nightly version: functional but possibly not well tested, and possibly carrying incomplete features. It aligns closely with what is normally served at vdo.ninja/alpha/. A hosted copy of the develop branch is available on GitHub Pages.

Release versions live on their own branches and are updated to fix bugs or critical issues as needed, but are otherwise unchanged. Then there is the primary hosted app at vdo.ninja, which the maintainer updates infrequently on purpose. The README gives the reasoning plainly: unexpected changes to a live video production app are not welcomed, and constant updates make it hard to tell whether a reported issue is a code problem or a user problem.

That is a defensible position, and it has a cost. If you want a recent feature you are pointed at alpha, which the README itself frames as carrying greater risk. The most recent release listed is v30.2 from 2026-05-12, described as changing video quality defaults when used for conferencing; v29.0 from 2026-01-18 added an improved podcast studio and a Director mesh-debug view. The last push to the repository was on 2026-09-21, so development activity is current even though the public hosted instance moves slowly.

## What self-hosting VDO.Ninja does not give you

The clearest limitation is scope. The README states that this repository contains the VDO.Ninja web frontend and sample apps using its IFRAME API, and that production backend implementations and operational scripts belong in separate repositories. Anyone expecting a single clone-and-run deployment will find the frontend and a set of examples, plus documentation pointing elsewhere.

Two features have explicit external dependencies. Twilio call-in requires an explicitly configured backend URL, and the README says the Twilio backend implementation and a hosted default are not included; SIP call-in instead uses the provider settings entered by the user. Live translation accepts a user-supplied API key or a separately configured token. Neither works from the static frontend alone.

The examples directory reinforces the same pattern. Files such as examples/chatoverlay.html, examples/custom_video_switcher.html and examples/grid.html show how to drive the client through its IFRAME API, and examples/dataiframes.md and examples/httpwssapi.md document messaging between frames and the API surface. These are integration samples, not a control plane. If your requirement is a fully self-contained, offline-capable video routing stack, this project is the wrong tool, because the parts that make rooms connect are not in the box.

## VDO.Ninja against a relayed conferencing tool

The obvious alternative for a remote guest is a conferencing product where the guest joins a call and you capture the window. The difference is where the video goes. A conferencing tool routes media through its own servers by design, and you capture whatever the client renders, which usually means the platform's own encoding and resolution choices. VDO.Ninja attempts a direct peer connection first and only relays when STUN-based discovery fails, and the guest's browser is the camera source rather than a call participant.

That distinction matters for latency and for image quality, and it also shifts the operational burden. With a conferencing tool you inherit someone else's infrastructure and its limits. With VDO.Ninja you inherit the signaling and TURN configuration, and if you self-host the frontend you own the HTTPS serving and the endpoint configuration as well. The README's own list of alternative frontends inside the project, including the WHIP/WHEP client, suggests the maintainer expects users to pick a surface that matches their workflow rather than use one monolithic app.

## Licence, upgrade exposure and what to check before adopting

The project is licensed AGPL-3.0, with AGPLv3.md, LICENCE.md and LICENSE present at the repository root. The AGPL is a copyleft licence with a network-use clause, so if you modify the frontend and serve it to users, the licence terms reach that deployment. Whether that fits your organisation is a question for your own counsel; the practical point is that this is not a permissive licence you can ignore when you fork the frontend.

Upgrade cost depends on which track you follow. The primary hosted app changes infrequently by design, which lowers the chance that a working production setup breaks. The develop branch is the opposite: the README calls it a preview or nightly version that may not be well tested. Pinning to a release branch gives you bug fixes without new features, which is the conservative choice for a live show. Verification before adoption is concrete: read install.md for the handshake-server link and client configuration, read turnserver.md and turnserver_basic.conf if you need a relay, and run the two translation check scripts before publishing any fork.

## Conclusion

Adopt VDO.Ninja if you need a remote guest's phone or laptop camera inside OBS and you accept that the hosted service at vdo.ninja is the intended path. Do not adopt it expecting a self-contained deployable stack: the repository is the web frontend plus sample apps, and the README states that production backend implementations and operational scripts belong in separate repositories. Before committing, verify the signaling and TURN endpoints you intend to use, read install.md and turnserver.md, and confirm whether the Twilio call-in backend you need is something you must run yourself.

## FAQ

### Is VDO.Ninja free?

The README lists free software, free managed services and free support among the project's features, and the public service is available at vdo.ninja. The source is licensed AGPL-3.0, so self-hosted deployments carry that licence's obligations.

### Does VDO.Ninja work with OBS?

Yes. The README describes bringing peer-to-peer technology to OBS and other studio software, and the getting-started path is to open vdo.ninja in your browser and select Add your Camera to OBS. The repository topics include obs and obsninja.

### How do I set up VDO.Ninja?

The README says you can get started by opening vdo.ninja in your browser and selecting Add your Camera to OBS. If you want to host the frontend yourself, serve the repository from an HTTPS-enabled static server; there is no build step or package installation required.

### Is VDO.Ninja secure?

The README states that video transfer is direct peer-to-peer in most cases, with TURN relaying traffic when a direct connection cannot be established. The README does not document the security properties of the hosted signaling or relay services, and the repository contains a SECURITY.md file.

### Does VDO.Ninja work on iPhone?

The README lists basic versions on the App Store and Play Store, and describes smartphone wireless webcam capabilities. The main path is browser-based, so an iPhone can join through the browser as well.

## Sources

- [License: AGPL-3.0](https://github.com/steveseguin/vdo.ninja/blob/develop/LICENSE)
- [Project website](https://vdo.ninja)
- [README](https://github.com/steveseguin/vdo.ninja/blob/develop/README.md)
- [Releases](https://github.com/steveseguin/vdo.ninja/releases)
- [steveseguin/vdo.ninja on GitHub](https://github.com/steveseguin/vdo.ninja)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/steveseguin-vdo-ninja