jitsi-videobridge: running the SFU behind Jitsi Meet

What jitsi-videobridge does that a mixer does not

A conferencing server can either mix all incoming media into one stream per participant or forward selected streams without decoding them. jitsi-videobridge is the second kind. The README calls it a WebRTC-compatible Selective Forwarding Unit, and the description on the repository says a single server can host up to hundreds of conferences. That number is the point of an SFU: the server never decodes video, so the CPU cost per participant is far lower than a mixing unit, and each endpoint receives only the streams it needs.

The audience is infrastructure operators, not end users. The README states plainly that the bridge is one of the backend components in the Jitsi Meet stack. If you install it alone, you get a service that speaks WebRTC and expects signalling and conference state to come from elsewhere. Teams building their own meeting product on Jitsi, or running self-hosted Jitsi Meet at a size where a single node is not enough, are the people this repository is written for.

How the bridge is put together: jvb, jitsi-media-transform and rtp

The repository layout is the clearest description of the architecture. Three Java modules sit at the top level: jvb, which holds the main entry point and the service itself; jitsi-media-transform, which handles rewriting and adapting media as it passes through; and rtp, which deals with the RTP layer. A config/ directory holds configuration resources, debian/ holds the packaging, and doc/ holds additional documentation that the README points to.

The main class is org.jitsi.videobridge.MainKt, which tells you the codebase is Kotlin compiled to the JVM. The README's local run command passes -Djava.library.path pointing at lib/native/linux-64, so there is native code involved on Linux. Configuration is layered: defaults live in reference.conf, and the values in the application config file override them. The README notes that the reference.conf link points at the ice4j repository rather than this one, which is worth knowing when you go looking for a key and cannot find it in the tree you cloned.

Installing jitsi-videobridge from the Debian packages

The README points at three package channels: stable, testing and nightly, each with its own installation instructions page on jitsi.org. Binary packages for Debian and Ubuntu are the intended path for production, and the application config file is described as usually installed at /etc/jitsi/videobridge/jvb.conf.

On Debian systems there is a second file, /etc/jitsi/videobridge/config, which sets options for the Java virtual machine rather than the application. The README gives two examples verbatim:

# Increase the java heap to 8GB
VIDEOBRIDGE_MAX_MEMORY=8192m
# Change the garbage collector (defaults to G1GC)
VIDEOBRIDGE_GC_TYPE=G1GC

Those keys go in the JVM config file, not in jvb.conf. Putting VIDEOBRIDGE_MAX_MEMORY into jvb.conf will do nothing, because jvb.conf is read by the application after the JVM has already started.

Building the package yourself and running it from Maven

If you need a custom build, the README gives one command from the repository root. It produces an archive under jvb/target:

mvn install

The README states the package lands at jvb/target/jitsi-videobridge-2.1-SNAPSHOT-archive.zip. Note the version string: it is 2.1-SNAPSHOT, while the release tags listed for the project follow the stable/jitsi-meet_<number> pattern with versions like 2.0.11248. The Maven build and the release tags are not labelled the same way, which is a small trap when you try to match a build to a release.

For a local run, the README says to first create ~/.jvb/jvb.conf to configure the environment to connect to and other options. The command it gives is long and uses Maven's exec plugin to launch java directly:

JVB_HOME="/path/to/the/cloned/repo"
JVB_CONFIG_DIR_LOCATION="~/"
JVB_CONFIG_DIR_NAME=".jvb"
JVB_CONFIG_FILE="$JVB_CONFIG_DIR_LOCATION/$JVB_JVB_CONFIG_DIR_NAME/jvb.conf"

mvn compile exec:exec -Dexec.executable=java -Dexec.args="--enable-native-access=ALL-UNNAMED -cp %classpath org.jitsi.videobridge.MainKt -Djava.library.path=$JVB_HOME/lib/native/linux-64 -Djava.util.logging.config.file=$JVB_HOME/lib/logging.properties -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=$JVB_CONFIG_DIR_LOCATION -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=$JVB_CONFIG_DIR_NAME -Dconfig.file=$JVB_CONFIG_FILE"

Read the variable block carefully before running it. The config file path is assembled from JVB_CONFIG_DIR_LOCATION and JVB_CONFIG_DIR_NAME, but the final JVB_CONFIG_FILE line references $JVB_JVB_CONFIG_DIR_NAME, which is not the variable that was set two lines above. The README prints it that way. If you copy the block unchanged, that path component expands to nothing and the config file location will not be what you expect. Set the name you actually used, or edit the last line to match.

Where the documentation is thin and what that costs you

The README is an entry point, not a manual. It defers to the doc/ directory in the source tree and to the Jitsi Meet Handbook, and it says questions belong on the Jitsi Community Forum rather than in GitHub issues, which the project uses only to track actionable items. For an operator that means the forum is your support channel, not the issue tracker.

Several things a first-time deployer would want are absent. There is no upgrade or rollback procedure in the README, no description of how the bridge discovers conferences, and no sizing guidance beyond the claim of hundreds of conferences per server. The configuration reference is a link to reference.conf, and the README's own link for that file points into the ice4j repository. The jvb.conf format itself is shown by example, not specified. None of this is unusual for infrastructure software, but it does mean you should read reference.conf in the tree you actually built before trusting any key you find in a blog post.

This is also the wrong tool if you want a complete, self-contained conferencing server you can point a browser at. The bridge has no user interface and no conference management of its own.

jitsi-videobridge versus Jibri, and versus a mixing MCU

People often reach for this repository when what they actually want is Jibri. The two solve different problems. jitsi-videobridge forwards live participant media between endpoints in a conference. Jibri is the component in the Jitsi family used for recording and streaming a conference to a file or an external service. A bridge does not record anything; if recording is the requirement, the bridge is the wrong component and Jibri is the right one.

The other comparison is against a traditional mixing MCU. A mixer decodes every incoming stream, composites them, and encodes one output per participant. That gives you a single stream to send and works with endpoints that cannot handle multiple simultaneous streams, at the cost of server CPU that grows with resolution and participant count. An SFU forwards streams and lets the endpoints decide what to render. jitsi-videobridge takes the SFU approach, which is why the project can talk about hundreds of conferences on one server. The trade-off moves to the client, which must be able to receive and decode several streams at once, and to the network, which carries more separate flows.

Licence, maintenance and what an upgrade actually involves

The project is Apache-2.0, which is a permissive licence that allows commercial use and modification, but this is not legal advice and you should read LICENSE in the tree for the terms that bind you. The relevant practical question is not the licence text but the release cadence: releases are tagged stable/jitsi-meet_<number>, with 2.0.11248 on 2026-09-14, 2.0.11146 on 2026-08-03 and 2.0.11031 on 2026-06-08. The last push to the repository was on 2026-09-23.

That cadence has a cost. If you run the Debian packages, you track the stable channel and upgrades arrive as package updates, with testing and nightly available if you want to move ahead of stable. If you build from source with mvn install, you own the build and the version string you get is 2.1-SNAPSHOT, which does not map cleanly onto the release tags. The README does not describe a rollback path for either case, so plan your own before you upgrade a production bridge.

Editorial conclusion

Adopt jitsi-videobridge if you are assembling a Jitsi Meet deployment or need an SFU that routes rather than mixes media, and you are comfortable with a Java service configured through jvb.conf and reference.conf. Do not adopt it as a standalone conferencing product: it is one backend component and expects the rest of the stack around it. Before committing, verify which configuration keys your target release accepts against reference.conf, and decide whether you want the Debian package path or the mvn install path, because the two produce different artifacts.

Frequently asked questions

Official sources

1. jitsi/jitsi-videobridge on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases