Jitsi Video Bridge

WebRTC infrastructure, honestly reviewed. Not a Zoom replacement you install in an afternoon — but the engine that makes building one possible.

TL;DR

• What it is: Jitsi Videobridge (JVB) is a WebRTC-compatible Selective Forwarding Unit — the media routing engine at the core of the Jitsi Meet stack. It routes video streams between participants without mixing them first [3].
• Who it’s for: Developers and technical teams building scalable video conferencing applications. Non-technical founders wanting a Zoom replacement should look at Jitsi Meet (the full stack) or JaaS (the managed cloud), not JVB in isolation [3][4].
• License: Apache-2.0 — genuinely permissive, no commercial-use restrictions [merged profile].
• Stars: 3,070 on GitHub [merged profile]. The more widely used Jitsi Meet (which JVB powers) has many more stars; JVB alone attracts infrastructure engineers.
• Key strength: Relays video rather than mixing it — less CPU per participant, lower latency, better quality at scale. Designed to handle hundreds of concurrent conferences per server [merged profile][2].
• Key weakness: Not a product — it’s a component. A working video conferencing deployment requires JVB plus Prosody, jicofo, nginx, a domain, TLS, and careful firewall configuration. Setup is non-trivial and debugging requires expertise [3][5].
• Managed option: JaaS (Jitsi as a Service) by 8x8 runs the full stack for you. Pricing not available in reviewed sources — check https://jaas.8x8.vc.

---

What is Jitsi Video Bridge

Jitsi Videobridge is a Selective Forwarding Unit (SFU) — a server-side media router. When you have a video call with four people, someone has to route video streams between them. The old approach was MCU (Multipoint Control Unit): mix all streams into one composite stream on the server. JVB does something different: it receives each participant’s stream and forwards the relevant streams to each other participant without mixing. The server sees packets but doesn’t transcode them. The result is lower CPU load per participant and better video quality, because each viewer receives the original stream rather than a re-encoded composite [merged profile][3].

JVB is one of several components in the Jitsi ecosystem [3]:

• Jitsi Meet — the browser-based frontend (React/React Native app)
• Jitsi Videobridge (JVB) — routes audio and video between participants
• jicofo — conference focus component; manages sessions and acts as load balancer between participants and JVB
• Prosody — XMPP server; handles user authentication and signaling
• jibri — recording/streaming service (launches a headless Chrome instance + ffmpeg)
• jigasi — SIP gateway for connecting telephone participants

None of these components works in isolation. When you read “self-host Jitsi,” you’re deploying all of them. JVB is the most resource-intensive piece, but it does nothing without the others.

The project has real history. Jitsi started as SIP Communicator in 2003, got video routing capabilities in 2012, spun out JVB as a separate server component in 2013, got acquired by Atlassian in 2015, then by 8x8 in 2018. The 2020 pandemic pushed meet.jit.si past 20 million monthly active users. 8x8 has since built JaaS as a commercial managed service on top of the same codebase [website scrape]. The open-source core remains Apache-2.0 licensed and actively developed.

---

Why People Choose It

The people actually building on JVB fall into two categories: developers who need an embeddable video infrastructure component, and organizations who want full data sovereignty over their video conferencing.

The data sovereignty case. Cuspera’s analysis of 513 Jitsi users [2] identifies improving internal communications and enhancing customer relationships as the top business priorities — but the deeper driver is control. When you self-host JVB as part of the Jitsi stack, video packets never leave your infrastructure. For healthcare providers, legal teams, or companies in jurisdictions with strict data residency requirements, that’s not a nice-to-have, it’s a compliance requirement.

The embedding case. The JVB homepage explicitly targets developers: “Build massively scalable multiparty video applications” [merged profile]. The Colibri protocol (controlled via XMPP or HTTPS REST) lets you programmatically create and manage conferences without a UI layer. Teams building video consultation tools, telehealth apps, or embedded meeting features use JVB as the infrastructure layer rather than paying per-minute API pricing to providers like Daily.co or Twilio Video.

The cost case. Self-hosting video infrastructure eliminates per-participant or per-minute costs. At scale, the difference between paying $0.001/participant-minute to a managed provider and running your own JVB on a €20/month dedicated server becomes significant fast.

Why developers choose JVB over alternatives: Apache-2.0 license (compared to some commercial video SDKs), the SFU architecture’s CPU efficiency at scale, and the JaaS fallback — if self-hosting becomes too painful, 8x8 operates the managed version of the same software, preserving integration compatibility [merged profile][website scrape].

The Freelancer.com listing [1] is an accidental data point worth noting: someone with a £250-750 budget needed a “Jitsi Meet and Jibri video bridge expert” for a one-month engagement with custom feature development. 40 freelancers bid with an average of £445. That’s the market signal — JVB deployments routinely require paid expertise even for baseline setups, let alone custom integrations.

---

Features

Core SFU capabilities:

• WebRTC-compatible video and audio routing [merged profile]
• Selective forwarding (relay, not transcode) — preserves quality, reduces server CPU [merged profile][2]
• DTLS/SRTP encryption — calls are encrypted end-to-end at the transport layer [merged profile][website scrape]
• Simulcast support — participants can send multiple quality layers; JVB forwards the appropriate one based on bandwidth [website scrape][2]
• Scalable Video Coding (SVC) support [website scrape]
• Bandwidth estimation [website scrape]
• SSRC rewriting for performance optimization at scale [2]
• Controlled via XMPP or HTTPS/REST (Colibri protocol) [merged profile]

Capacity: The README describes handling “hundreds of conferences per server.” The Jitsi website references a performance evaluation page showing that “even small CPUs can handle it” — though concrete participant-per-server numbers depend heavily on video resolution and bitrate [merged profile].

Ecosystem components (required for a working deployment):

• Prosody (XMPP server for signaling and auth) [3][5]
• jicofo (conference session management and load balancing) [3][5]
• nginx/Apache (reverse proxy, TLS termination, WebSocket forwarding) [4][5]
• jibri (optional — recording and streaming via headless Chrome + ffmpeg) [3][website scrape]
• jigasi (optional — SIP telephony gateway) [3]

What JVB does NOT include:

• A user interface (that’s Jitsi Meet)
• Recording (that’s jibri — separate setup, separate server recommended)
• Authentication beyond basic room passwords (JWT or internal auth requires Prosody config) [5]
• TURN server — required for participants behind strict NAT; you provision this separately [5]

---

Pricing: SaaS vs Self-Hosted Math

meet.jit.si (community instance): Free. No account required. Jitsi runs a public instance that anyone can use. Quality and availability aren’t guaranteed under load, and your calls go through 8x8’s infrastructure. Fine for personal use, not for a business product [4].

JaaS — Jitsi as a Service (8x8’s managed cloud): JaaS runs the full Jitsi stack including JVB, handles scaling, and provides SDK access for embedding. Pricing tiers exist with a free tier for development. Specific pricing was not available in the reviewed sources — check https://jaas.8x8.vc for current rates.

Self-hosted (full Jitsi Meet stack):

• Software license: $0 (Apache-2.0) [merged profile]
• Server: a Jitsi Meet deployment for up to ~50 concurrent participants needs 4+ GB RAM minimum per the installation guide [4]. A VPS with 4GB RAM runs €10-20/month on Hetzner or Contabo.
• Your time: see Deployment section

Comparison baseline (Zoom, approximate public pricing): Zoom Pro starts around $15.99/user/month. A team of 10 paying for Zoom Pro runs ~$160/month. Self-hosted Jitsi stack on a €15/month server replaces that for server cost only — but requires technical setup and ongoing maintenance. The math is compelling at scale; less so if a single junior developer is spending 20 hours on setup and debugging.

The honest calculation: Self-hosting JVB/Jitsi Meet makes economic sense when you have either (a) technical staff who can deploy and maintain it, or (b) a one-time deployment budget that pays for itself within 3-6 months of SaaS savings. For a team of 5 paying Zoom Pro, that payback period is fast. For a solo founder with no Linux experience, it’s not.

---

Deployment Reality Check

This is where honest review is most valuable. The installation tutorial for Debian [4] lists these prerequisites: non-root sudo user, OpenJDK 8 or 11, at least 4 GB of RAM, and a domain or subdomain pointed to your instance. That’s the baseline.

The full component setup [3][5]:

1. Set up Prosody (XMPP server) — configure domain, authentication method, components
2. Install jicofo — connect it to Prosody, configure bridge selection
3. Install Jitsi Videobridge — configure ICE, STUN/TURN, NAT settings
4. Configure nginx — reverse proxy with WebSocket forwarding to /xmpp-websocket/
5. TLS certificates (Let’s Encrypt)
6. Open firewall ports: TCP 443, UDP 10000 (media), optionally TCP 4443 (fallback), TCP 5222 (XMPP)

What goes wrong [5]:

The debugging guide from pc-freak.net [5] — written by someone who clearly operates Jitsi in production — identifies the common failure modes:

• “Failed to join conference” — usually Prosody misconfiguration
• No audio or video — JVB not reachable on UDP 10000, or NAT/firewall blocking media. This is the most common issue on cloud VMs
• WebSocket connection fails — nginx not forwarding WebSocket requests correctly
• Authentication not working — JWT token misconfiguration or wrong shared secret in Prosody

The debug cycle requires checking four separate log files: Prosody (/var/log/prosody/), jicofo (/var/log/jitsi/jicofo.log), JVB (/var/log/jitsi/jvb.log), and nginx (/var/log/nginx/error.log), plus the browser’s WebRTC internals [5]. For someone unfamiliar with XMPP, Java logging properties, and ICE/STUN protocols, this is a steep learning curve.

TURN server is a separate problem. Participants behind strict corporate firewalls or symmetric NAT cannot establish direct WebRTC connections. You need a TURN server (coturn is the standard choice). That’s another service to deploy, configure, and maintain.

Recording (jibri) is the most resource-intensive optional component. It launches a headless Chrome instance per recording, renders the conference UI in a virtual framebuffer, and encodes with ffmpeg. The recommendation is a separate server for jibri, not the same machine running JVB [3].

Realistic time estimate for a technical user: 4-8 hours to a working Jitsi Meet deployment on a fresh VPS, assuming familiarity with Linux, nginx, and firewall management. Debugging unexpected network issues can add another day. For a non-technical founder: budget professional deployment help — this is not a one-click install.

---

Pros and Cons

Pros

• Apache-2.0 license. Genuinely permissive. Self-host, fork, embed in a commercial product, resell — no commercial-use restrictions, no legal calls needed [merged profile].
• SFU architecture is the right approach. Relaying rather than mixing means better quality and lower server CPU per participant. This isn’t marketing — it’s the technically correct architecture for modern WebRTC at scale [merged profile][2].
• Full data sovereignty. Video packets stay on your infrastructure. For regulated industries or data-sensitive organizations, this is the point [2].
• Battle-tested at scale. 20 million monthly active users on meet.jit.si as of 2020 [website scrape]. 8x8 runs JaaS on the same codebase commercially. This is not a toy project.
• No per-participant or per-minute costs. Once deployed, unlimited participants within server capacity. The variable cost is server resources, not a billing meter.
• Active development and corporate backing. 8x8 has real incentive to maintain the codebase since their commercial JaaS product depends on it.
• JaaS escape hatch. If self-hosting becomes unmanageable, you can migrate to JaaS without changing your integration code [merged profile].

Cons

• Not a product — it’s infrastructure. JVB alone does nothing useful. A working deployment is a 5+ component system requiring coordination between Prosody, jicofo, nginx, and JVB [3][5].
• Setup complexity is real. UDP 10000 firewall configuration, NAT traversal, TURN server provisioning, XMPP signaling — these are genuine technical requirements, not optional polish [4][5].
• Debugging requires multi-domain expertise. Tracing a failed call through browser WebRTC internals, nginx logs, Prosody XMPP logs, and JVB ICE logs requires knowing all four systems [5]. Freelancer market confirms: even simple custom deployments fetch £300-750 in professional fees [1].
• No built-in recording without jibri. jibri is a headful Chrome-based solution — resource-heavy, fragile, and ideally runs on a separate server [3].
• 3,070 GitHub stars for JVB specifically — modest relative to the broader Jitsi ecosystem. The community is real but concentrated around Jitsi Meet, not the bridge component in isolation [merged profile].
• No SaaS pricing transparency from reviewed sources for JaaS tiers.
• TURN server is a separate problem. Participants behind strict NAT cannot connect without it; you provision and maintain this separately.

---

Who Should Use This / Who Shouldn’t

Use Jitsi Video Bridge (as part of the full Jitsi stack) if:

• You’re a developer or engineering team building a video application and need embeddable WebRTC infrastructure with a permissive license.
• You’re in healthcare, legal, finance, or another regulated industry where video call data must stay within your own infrastructure.
• Your team has Linux and networking competence, or budget to pay for a one-time professional deployment.
• You’re paying per-participant or per-minute fees to a managed video provider and want to own the infrastructure after initial setup.
• You need to embed video into your own product and Apache-2.0 licensing matters for your commercial use case.

Use JaaS (managed Jitsi) instead if:

• You want Jitsi’s quality and Apache-2.0 compatibility without running the infrastructure yourself.
• You’re a non-technical founder who needs video conferencing for your team — JaaS is the right entry point, not a DIY JVB deployment.

Skip it entirely (use Zoom, Google Meet, or Whereby) if:

• You need a video tool for your team in the next week, not a video infrastructure project.
• Your team has no Linux experience and no budget for a technical deployment.
• Call quality and uptime are non-negotiable and you can’t staff ongoing maintenance.
• You have fewer than 20 users and the cost savings don’t justify the setup time.

Skip it (use Daily.co, Twilio Video, or Vonage) if:

• You’re building a video product and want a managed SDK with SLA guarantees, SDKs across platforms, and per-minute pricing that someone else scales.

---

Alternatives Worth Considering

• Jitsi Meet (full stack) — what most people actually want when they search for “self-hosted video conferencing.” JVB is one component; Jitsi Meet is the complete system.
• JaaS by 8x8 — managed Jitsi, same codebase, no infrastructure to run. Right choice if the DIY path is too painful.
• BigBlueButton — open-source video conferencing focused on education and webinars. More features out of the box (whiteboard, breakout rooms, polls) at the cost of even higher server requirements (8+ GB RAM recommended).
• Whereby — managed video with embed API, no self-hosting option but clean developer experience.
• Daily.co — managed WebRTC API, per-minute pricing, strong SDK support.
• mediasoup — another open-source SFU if you want to build a custom video stack from lower-level primitives. More work than JVB but more control.
• LiveKit — newer open-source SFU with a cleaner developer experience, WebRTC and WebSocket support, and a managed cloud option. Worth comparing if you’re building a new video product from scratch.
• Zoom — the incumbent. Easiest for end-users, per-host pricing, closed source, no data sovereignty.

---

Bottom Line

Jitsi Video Bridge is excellent infrastructure that is genuinely unsuitable for most non-technical founders as a direct deployment target. The SFU architecture is the right call, the Apache-2.0 license is the right license, and 8x8’s backing means the project isn’t going anywhere. But “self-host Jitsi” means deploying and debugging a five-component distributed system — Prosody, jicofo, JVB, nginx, and optionally jibri and coturn — where a single misconfigured firewall rule or wrong NAT setting produces a call that silently fails to connect. The Freelancer market prices this expertise at £300-750 for a basic custom deployment. That’s not a scam — it’s accurate. If you’re a developer building a video product, JVB is a strong foundation. If you’re a non-technical founder wanting to cut your Zoom bill, the path is JaaS first, self-hosted Jitsi Meet second (with a professional deployment), and raw JVB configuration last or never.

If getting the full stack deployed and tuned is the blocker, that’s exactly the kind of infrastructure setup upready.dev handles for clients — one-time deployment, you own the server.

---

Sources

1. Freelancer.com — “Jitsi meet, jibri video Bridge expert” (project listing, 40 bids, avg £445). https://www.freelancer.com/projects/jitsi-meet-jibri-video-bridge
2. Cuspera — “Jitsi: Use-Cases, Insights and Reviews | 2026” (513 insights, 4.26/5). https://www.cuspera.com/products/jitsi-x-9882
3. Jitsi Meet Handbook — “Architecture | Jitsi Meet” (official component documentation). https://jitsi.github.io/handbook/docs/architecture/
4. Eldernode Blog — “Tutorial Install Jitsi Meet video conference on Debian 10 | 9” (installation guide with prerequisites). https://blog.eldernode.com/install-jitsi-meet-video-conference-on-debian/
5. pc-freak.net — “Debugging Jitsi Meet Server Problems: A Practical Guide” (April 26, 2025). https://www.pc-freak.net/blog/tag/firewall-checks/

Primary sources:

• GitHub repository: https://github.com/jitsi/jitsi-videobridge (3,070 stars, Apache-2.0)
• Official website: https://jitsi.org/jitsi-videobridge/
• Jitsi as a Service (JaaS): https://jaas.8x8.vc