How to Configure Jitsi Videobridge for a Scaled Multi-Server Setup

Adding Jitsi Videobridge (JVB) servers is the normal way to increase media capacity for one Jitsi Meet deployment. Keep the web, Prosody, and Jicofo services on the existing Meet host, then add independent bridge machines that register with the same Prosody bridge-discovery room. Jicofo can then place new conferences on an available bridge. For this basic design, participants in a conference use one selected bridge; you do not need Octo just because the deployment has several JVB servers.

This guide follows the Jitsi Handbook's Debian/Ubuntu package-based scalable setup, checked October 6, 2026. Exact package dependencies and generated configuration can vary with distribution, Jitsi package version, and whether the server was installed with Docker or another method. Use the matching official installation guide for your existing deployment.

Understand what “multi-server” means in Jitsi

Verified: A single Jitsi Meet installation can use multiple Videobridges. Jicofo monitors the bridges and assigns a new conference to a bridge. The Jitsi Handbook's simplified example places the Meet services on one server and three JVBs on separate servers. Each bridge must be reachable by meeting participants for media and by the Meet infrastructure for signaling.

Common misconception: “I need a load balancer in front of the JVBs.” In the documented multi-bridge design, Jicofo selects a bridge; clients then send media to that bridge. A generic HTTP load balancer in front of UDP media does not replace bridge discovery or conference placement. Action: Add each JVB to the Prosody/Jicofo bridge pool and publish its reachable media address. Do not point every bridge's media traffic at one arbitrary UDP VIP.

Common misconception: “More bridges make one meeting span all servers automatically.” In the basic setup, Jicofo assigns a conference to a bridge. Spreading participants from one conference across regions or bridges is a separate relay topology called Octo (secure relays in current JVB documentation). Action: Start with ordinary bridge pooling if your goal is more concurrent meetings; investigate Octo only when one conference must use bridges in multiple locations or you need that relay behavior.

Plan the bridge pool before installing

Choose one public, stable hostname or address for each JVB. Give every VM a unique operating-system identity and a unique JVB instance nickname when the configuration uses XMPP MUC presence. All bridges should be able to reach the same Prosody service and bridge brewery room. Keep versions aligned: Jicofo will not mix bridges with different versions in the same conference, and the current relay documentation repeats this constraint for Octo.

Depends on your environment: There is no universal participant-per-VM number. Jitsi's own requirements documentation emphasizes network capacity and workload over a single fixed sizing number. Codec, resolution, simulcast, packet rates, concurrent conferences, and provider bandwidth all affect capacity. Action: Establish a baseline on your actual workload, then add one bridge at a time and observe CPU, network throughput, packet loss, and conference quality.

Configure multiple JVB servers step by step

1. Confirm the existing Meet host is healthy

Before adding machines, verify that the existing Meet page loads, Prosody and Jicofo are running, and a test call completes through the current bridge. Record the Jitsi package versions. A broken signaling or certificate setup on the core server will make a new bridge look misconfigured even when its network is sound.

On a Debian/Ubuntu package installation, inspect services with systemctl status prosody jicofo jitsi-videobridge2 and review the service logs. Use the service names present on your installation; containerized deployments expose different commands and log locations.

2. Prepare DNS, routing, and firewall rules

Give each bridge its own public address or a correctly configured one-to-one NAT mapping. The scalable setup guide lists these typical paths: public clients reach the web host on TCP 80/443; JVB servers reach Prosody on TCP 5222; and clients reach each Videobridge on UDP 10000 for media. TCP 80 is generally used for certificate or redirect setup, while a production Meet site should use HTTPS.

• Allow inbound UDP 10000 to every bridge from the participant networks your service supports.
• Allow bridge-to-Prosody TCP 5222 from the JVB hosts, and restrict it to those hosts when your firewall permits.
• Keep the Prosody/XMPP service private to the intended infrastructure where possible.
• Do not expose JVB private HTTP/debug endpoints publicly. If you enable or proxy a public Colibri WebSocket endpoint, follow the current JVB and reverse-proxy documentation for that exact deployment.

Depends on your network: NAT, cloud security groups, IPv6, TURN, and restrictive corporate networks may require additional candidates or paths. The default port list is not proof that media works through your particular firewall. Action: Check packet flow to each public bridge address from an external client network, and test an actual call; a successful XMPP connection alone does not verify UDP media.

3. Install the same Jitsi Videobridge package on each node

Use the Jitsi repository and package instructions that match the Meet host's distribution. On each new Debian/Ubuntu node, install jitsi-videobridge2 and answer the package configuration prompts with the Meet hostname as directed by the official scalable setup. The Handbook says that, for its documented package-based setup, the bridge needs no extra change beyond the default setup after installation.

Do not install a full second Jitsi Meet stack on every bridge unless you intentionally want independent Meet deployments. For a bridge pool, keep the web, Prosody, and Jicofo role on the core host and add JVB services to the other machines. Use the same supported JVB release across the pool; stage upgrades so you do not leave a mixed-version pool for longer than necessary.

4. Verify bridge registration and identity

In the package-based setup, first let the official package configuration generate the expected settings. The JVBs need to connect to Prosody and announce bridge presence to the same brewery MUC that Jicofo monitors. If you are using the current XMPP-client configuration path, JVB documentation shows the relevant pieces under videobridge.stats and videobridge.apis.xmpp-client.configs; Jicofo must join the corresponding brewery using jicofo.bridge.brewery-jid.

A typical modern configuration has this shape; replace all example values with values from your installation and protect the shared secret:

videobridge {
  stats {
    enabled = true
    transports = [{ type = "muc" }]
  }
  apis {
    xmpp-client {
      configs {
        xmpp-server-1 {
          hostname = "meet.example.com"
          domain = "auth.meet.example.com"
          username = "jvb"
          password = "REPLACE_WITH_SECRET"
          muc_jids = "JvbBrewery@internal.auth.meet.example.com"
          muc_nickname = "bridge-01"
        }
      }
    }
  }
}

Use a different muc_nickname on each bridge (for example, bridge-02 and bridge-03). The JVB project warns that nicknames must be unique across instances. The exact configuration filename and whether this explicit block is needed depend on your package and existing setup; avoid layering a hand-written modern configuration over generated legacy package settings without checking the installed version's documentation.

5. Start the service and check logs

Restart or start JVB on each new host, then check that it stays active and connects to Prosody. The scalable setup guide recommends checking the Prosody and Jicofo logs to confirm bridge connections and that Jicofo discovers the bridges. If one does not appear, check in this order: DNS resolution and TCP 5222 reachability; XMPP credentials and domain; exact brewery MUC spelling; duplicate nickname; then JVB/Jicofo version compatibility.

6. Run an external media test on every bridge

Start several new test meetings and confirm that Jicofo places them across the available pool over time. One meeting landing on one bridge is expected; it does not show that balancing failed. Use Jicofo's debug interface, if enabled and access-restricted, to inspect available bridges and active conferences. The JVB documentation gives curl http://localhost:8888/debug as a local debug example; bind or firewall diagnostic interfaces so they remain private.

Test with clients outside the server network. Confirm that audio and video work, then inspect the selected bridge address and UDP flow. If a bridge appears in Jicofo but calls fail only when that bridge is selected, investigate its public address, NAT mapping, UDP firewall, and advertised candidates. Keep one bridge out of rotation during maintenance only through a supported drain or deployment procedure for your installed version; restarting an active bridge can interrupt meetings assigned to it.

When should you enable Octo?

Octo is the right topic when a single conference should use multiple bridges, often because participants are spread across regions. It is not a prerequisite for adding JVBs for ordinary capacity. Current JVB relay docs require relay configuration on each participating bridge, Colibri WebSockets for bridge-to-bridge connections, and a suitable Jicofo bridge selection strategy. Region-aware behavior also depends on supplying accurate client region information to the served Meet configuration.

A relay configuration includes a unique relay-id and a region for each bridge, while Jicofo enables Octo and selects a strategy such as RegionBasedBridgeSelectionStrategy. Relay WebSocket endpoints also need to be routed through any proxy correctly. These settings change across releases and topologies, so follow the current relay guide and validate the exact proxy paths before rollout.

Action: Leave Octo disabled for a simple one-region bridge pool. If you have a multi-region requirement, test with the documented split strategy in a staging environment, inspect Jicofo's bridge selector and conference state, and then configure client regions and region-based selection. Do not set region labels until you know how clients will receive the matching region metadata.

What to monitor as you scale

• Network: outbound and inbound throughput, packet drops, jitter, and whether UDP 10000 is reachable from real client networks.
• Host pressure: CPU, memory, JVM health, and sustained packet rate. Size with representative meetings rather than an assumed universal call count.
• Pool membership: bridge presence in Jicofo, version consistency, and whether newly created conferences can land on every node.
• Participant experience: audio continuity, video freezes, reconnects, and quality under the expected peak concurrency.

If users report problems only on one JVB, compare that node's network path and configuration with a working peer before increasing the whole cluster. If all bridges degrade together, the bottleneck may be shared bandwidth, the core signaling services, or the participant network. Scaling works when new bridges are independently reachable, correctly registered, and measurably reduce load during realistic tests.

Official references

• Jitsi Handbook: DevOps Guide (scalable setup)
• Jitsi Handbook: Requirements
• Jitsi Videobridge: MUC configuration
• Jitsi Videobridge: Relay (Octo) setup
• Jitsi Videobridge: HTTP and REST interfaces