Jitsi Videobridge SFU Deployment Guide: JVB 2.0 & Octo

Overview

If you run your own video meetings, the piece that does the heavy lifting is the Jitsi Videobridge SFU. It receives video and audio from each person and forwards it to everyone else in the call, without mixing or re-encoding it. That is why Jitsi can handle many users on modest hardware. In this guide, I will walk you through how JVB works, how to deploy it, and how to use Octo to spread one meeting across several bridges and regions.

One quick note on names. People say “JVB 2.0” for the newer, rewritten videobridge, and “Octo” for the feature that connects bridges to each other. In newer Jitsi releases, the Octo feature has been reworked and is often called “relays” or “cascaded bridges” in the docs. The idea is the same. I will point out where the names and settings differ so you do not get lost.

What Is Jitsi Videobridge and Why Does It Matter?

Jitsi Videobridge (JVB) is an open-source media server written in Java. It is part of the Jitsi Meet stack. Its job is simple: take the streams that come in and send them out to the right people.

There are three common ways to build a video call system:

• Mesh: Everyone sends video to everyone else. It works for two or three people, then falls apart fast.
• MCU: A server mixes all videos into one stream. It uses a lot of CPU and adds delay.
• SFU: A server forwards streams without mixing. It is light on CPU and scales well.

JVB is an SFU. Each person uploads one stream (or a few quality levels of it), and the bridge decides who gets what. If someone has a slow connection, the bridge sends them a lower quality version. If a call has 50 people, the bridge does not send all 50 videos to everyone. It sends only the few that matter, like the active speaker.

How the Jitsi Videobridge SFU Fits Into the Full Stack

Before you deploy anything, you need to know who talks to whom. A Jitsi Meet install has four main parts:

• Jitsi Meet: The web app people open in their browser.
• Prosody: The XMPP server that handles signaling (who joined, who left, and so on).
• Jicofo: The conference focus. It creates the meeting and picks which bridge will host it.
• Jitsi Videobridge: The media server that carries audio and video.

Here is the flow in plain words. A user opens your Jitsi URL. The browser connects to Prosody. Jicofo sees the new meeting and asks, “Which bridge should host this?” It looks at the list of bridges that are online, picks one, and tells the browser where to send media. From then on, the video travels between the browser and the bridge.

The bridges join a special XMPP room, often called the brewery room (usually JvbBrewery). This is how Jicofo knows which bridges exist. When a new bridge joins the room, Jicofo can start using it right away. That is the whole trick behind adding more capacity.

What Is Octo and Why Would You Need It?

By default, one meeting lives on one bridge. That is fine for most cases. But two problems show up as you grow:

• One huge meeting. If a single call has hundreds of people, one bridge may run out of CPU or network bandwidth.
• People in different regions. If half your users are in Mumbai and half are in Frankfurt, and the bridge is in Frankfurt, the Mumbai users get higher delay.

Octo solves both. It lets one meeting use several bridges at once. Each user connects to a bridge near them. The bridges then pass media between each other. So the person in Mumbai connects to a bridge in Mumbai, the person in Frankfurt connects to a bridge in Frankfurt, and the two bridges swap the streams behind the scenes.

Think of it like a post office network. You drop your letter at the nearest branch, and the branches send it to each other. You never have to travel to the far branch yourself.

A few things to know about Octo:

• It helps with delay and capacity, but it adds some complexity.
• Bridges talk to each other over UDP, so your network rules must allow it.
• Bridges in the same meeting need to reach each other. Cloud regions with private links or public IPs both work, as long as ports are open.

Planning Your Jitsi Videobridge Deployment

Do a little planning before you install. It saves a lot of pain later.

Decide How Many Bridges You Need

A rough starting point: a modern 4-core or 8-core server can handle a few hundred participants in typical calls. Real numbers depend on how many people have cameras on, the video quality, and how many are watching each other. Run a load test on your own setup instead of trusting anyone’s rule of thumb, including mine.

Pick Your Server Specs

• CPU: Plenty of cores. The bridge is busy with encryption and packet handling.
• Network: This is often the real limit. A 1 Gbps link is a good start.
• RAM: 8 GB is usually enough for a bridge on its own.
• Public IP: Each bridge should have one. Avoid running behind heavy NAT if you can.

Split Your Servers by Job

For anything beyond a small setup, do not put everything on one machine. A common layout is:

• One server for Jitsi Meet, Prosody, and Jicofo (the “core” server)
• Two or more separate servers running only JVB

That way, a busy bridge does not slow down signaling.

Ports and Firewall Rules You Must Open

Most “video does not work” problems come from closed ports. Here are the main ones:

For older Octo setups, bridges also used UDP port 4096 to talk to each other. In newer versions with relays, bridge-to-bridge traffic goes through the normal media setup, so check the docs for your version before opening ports.

A tip: keep port 8080 closed to the public internet. It is meant for your own monitoring tools, not for everyone.

Step-by-Step: Installing Jitsi Videobridge

Below is a simple path on Debian or Ubuntu. Always check the official Jitsi handbook for the newest steps, since package names and defaults can change.

Step 1: Install the Core Stack First

On your main server, install Jitsi Meet using the official quick install. This gives you Prosody, Jicofo, the web app, and one bridge. Get a domain name, point it at the server, and set up a TLS certificate. Make sure a test meeting works with two devices before you go further.

Step 2: Prepare Your Extra Bridge Server

On a fresh server, add the Jitsi package repository and install only the bridge package:

sudo apt update
sudo apt install jitsi-videobridge2

The installer will ask for your main domain. Enter the hostname of your core server.

Step 3: Connect the Bridge to Prosody

Open the bridge config file, usually at /etc/jitsi/videobridge/jvb.conf. The important section looks like this:

videobridge {
  apis {
    xmpp-client {
      configs {
        xmpp-server-1 {
          hostname = "your-core-server.example.com"
          domain = "auth.your-domain.example.com"
          username = "jvb"
          password = "YOUR_JVB_PASSWORD"
          muc_jids = "JvbBrewery@internal.auth.your-domain.example.com"
          muc_nickname = "jvb-2"
        }
      }
    }
  }
}

Two things trip people up here:

• The password must match the one Prosody has for the jvb user.
• The muc_nickname must be different on every bridge. If two bridges use the same nickname, one will kick the other out of the brewery room.

Step 4: Set the Public and Private IP

If your server sits behind NAT (common on cloud providers), the bridge must know its public address. Otherwise, it tells browsers to connect to a private IP that they cannot reach. You set a local and a public address so the bridge can advertise the right one. In many installs this is done through the NAT harvester settings in sip-communicator.properties:

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=10.0.0.5
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=203.0.113.10

Replace these with your real private and public IPs.

Step 5: Restart and Check

sudo systemctl restart jitsi-videobridge2
sudo systemctl status jitsi-videobridge2

Then look at the logs for a line that shows the bridge joined the brewery room. On your core server, Jicofo logs should show a new bridge appearing.

How to Enable Octo for Multi-Bridge Meetings

Now the fun part. Octo needs settings on both the bridges and on Jicofo. The exact key names depend on your version, so treat the following as the general idea and compare it with the handbook for your release.

On Each Bridge

You turn on the bridge-to-bridge feature and tell each bridge which region it is in. For the older Octo style, it looked like this:

videobridge {
  octo {
    enabled = true
    bind-address = "10.0.0.5"
    public-address = "203.0.113.10"
    bind-port = 4096
    region = "asia-south"
  }
}

In newer releases that use relays, the block is called relay and the setup is a bit simpler, but you still give each bridge a region name. Use the same region names in every place. A typo like asia-south on one bridge and asia_south on another will quietly break region matching.

On Jicofo

Jicofo needs to know that it may spread one meeting across bridges, and how to pick them. A region-based strategy is common. It tries to place each user on a bridge in or near their own region.

You also need to tell Jicofo where each user is. The browser sends its region through the Jitsi Meet config (often set as deploymentInfo.userRegion in config.js). Many people set this using a small script on the web server that looks up the user’s location from their IP, then writes the right value.

Test It

Open a meeting from two devices in different regions if you can. Or use a VPN to fake it. Then check the bridge stats. Each bridge should show participants, and the meeting should show up on more than one bridge. If everyone lands on the same bridge, look at your region settings first.

Bridge Selection: How Jicofo Picks a Bridge

Jicofo has a few strategies for choosing a bridge:

• Single bridge: Put everyone in a meeting on the least-loaded bridge. Simple and reliable.
• Split bridge: Spread users across bridges so no single bridge gets too busy.
• Region-based: Prefer bridges close to the user. Best for global teams.

Start with the simplest one that meets your needs. If all your users are in one country, you may not need Octo at all. Adding more bridges and letting Jicofo balance them is often enough. Turn on multi-bridge meetings only when you actually see a need, such as very large calls or users spread across continents.

Tuning the Jitsi Videobridge SFU for Better Quality

Once the bridge is running, a few settings can make calls feel better.

Use Last-N

Last-N limits how many video streams a user receives. Instead of getting 100 videos, a user might get the 20 most recent speakers. This saves a lot of bandwidth and CPU, and most people never notice.

Keep Simulcast On

Simulcast means each sender uploads a few versions of their video at different quality. The bridge then picks the right one for each viewer. It is on by default in most setups, so just do not turn it off.

Watch Your Network Limits

Cloud servers often have a bandwidth cap that is lower than the number on the sales page. If calls get choppy under load and CPU looks fine, check the network graph. That is usually where the limit hides.

Allow the TCP Fallback Carefully

Some users sit behind strict firewalls that block UDP. For them, media has to go over TCP or through a TURN server. Set up a TURN server (like coturn) on port 443 so those users can still join. It costs extra bandwidth, but it saves you from support tickets.

Monitoring and Health Checks

A bridge you cannot see is a bridge you cannot trust. Do these basics:

• Enable the REST API on the bridge and use the health endpoint to check that it is alive. Keep it on a private network.
• Export stats to Prometheus and view them in Grafana. Track participants, conferences, packet loss, and CPU.
• Set alerts for high CPU, high packet loss, and a bridge that drops out of the brewery room.

Also learn how to drain a bridge. When you need to update or restart one, you can put it in graceful shutdown mode. It stops taking new meetings and waits for the current ones to end. This way, you never kick people out of a call for maintenance.

Common Problems and Quick Fixes

Video works for two people but not three. Two-person calls can go peer-to-peer, so they may work even when the bridge is broken. Check that UDP 10000 is open and that the public IP is set correctly.

Bridge does not show up in Jicofo. Check the password, the domain name, and the brewery room name. Then look at the Prosody and bridge logs together.

Users in one region have high delay. Your region names may not match, or the user region is not being set in config.js. Test by printing the value in the browser console.

One bridge gets all the load. Your selection strategy may be set to single bridge, or the other bridges are not healthy. Check the bridge list in Jicofo.

Octo bridges cannot see each other. Check the firewall between them. Test with a simple UDP tool from one bridge to the other. Also make sure that the addresses you set are ones the other bridge can actually reach.

Audio works but video freezes. This is often a bandwidth issue. Check for packet loss and look at your provider’s network limit.

Security Tips for Your Deployment

• Turn on authentication for creating meetings if it is a private service.
• Use strong, unique passwords for the jvb user and other XMPP accounts.
• Keep the REST API port private.
• Keep your packages updated. Jitsi releases fixes often.
• Use a firewall that only opens the ports you need.

Should You Use Octo or Just Add More Bridges?

This is the question I would ask before anything else. Here is a simple way to decide.

Just add more bridges if:

• Your users are mostly in one region.
• Most meetings are small or medium.
• You want a simple setup that is easy to fix.

Use Octo if:

• You host very large meetings that do not fit on one bridge.
• Your users are spread across continents and delay matters.
• You have the time to test, monitor, and debug a more complex network.

More parts mean more things that can break. Start simple and add complexity only when your numbers tell you to.

Conclusion

The Jitsi Videobridge SFU is a strong, flexible way to run your own video calls. It forwards streams instead of mixing them, so it uses fewer resources and scales well. A basic deployment needs a core server for signaling and one or more bridges for media. When one bridge is not enough, or your users are spread across the world, Octo lets one meeting use several bridges at once.

To recap the key points:

• Understand how Prosody, Jicofo, and JVB work together.
• Open the right ports, especially UDP 10000.
• Set the public and private IPs correctly on each bridge.
• Give every bridge a unique nickname and a clear region name.
• Start with simple bridge scaling and move to Octo only when you need it.
• Monitor everything and test under real load.

Ready to try it? Spin up one extra bridge on a test server this week, connect it to your brewery room, and watch Jicofo start using it. Once that works, you have the base skills for everything else in this guide. And if you get stuck, share your logs in the Jitsi community forum. It is friendly and full of people who have solved the same problem.