How to Set Up Jibri for Jitsi Meet Recording and Streaming on Ubuntu 22.04

What is Jibri?

Jibri (Jitsi Broadcasting Infrastructure) is the component that gives a self-hosted Jitsi Meet server its recording and live streaming buttons. It works in a fairly blunt but reliable way: it joins the conference as a hidden participant, renders the meeting in a Chrome instance running on a virtual framebuffer, and captures that screen with ffmpeg. The output either lands on disk as a file recording or gets pushed to an RTMP endpoint such as YouTube Live.

Because it captures a full Chrome session, one Jibri instance handles exactly one recording at a time, and it wants its own machine (or VM) with nothing else competing for the display and audio devices. That is the main thing to plan around before you start.

This guide walks through the full setup on Ubuntu 22.04: preparing your existing Jitsi Meet server (Prosody, Jicofo, and the web config), then installing and configuring Jibri itself, and finally shipping the finished recordings to S3.

Prerequisites

If you have not deployed Jitsi Meet yet, set that up first - our Jitsi Meet on AWS guide covers it end to end.

How Jitsi Meet recording works behind the scenes

Three services on your existing Jitsi server need small changes so Jibri can join meetings without showing up as a participant:

• Prosody - the XMPP server every Jitsi component talks through. It gets a hidden MUC (chat room service) where Jibri instances wait for work, plus a hidden virtual host for the account Jibri uses inside meetings.
• Jicofo - the conference focus. It gets told where that hidden MUC (the "brewery") lives, so it can grab an idle Jibri when someone presses record.
• Jitsi Meet web config - gets the recording and streaming buttons enabled, and learns to hide the recorder account from the participant list.

Step 1 - Configure Prosody

Open your Prosody host config on the Jitsi server:

sudo nano /etc/prosody/conf.avail/meet.example.com.cfg.lua

Make sure the conference MUC component is present (it normally is on any working Jitsi install):

Component "conference.meet.example.com" "muc"
    modules_enabled = { "muc_mam" }

Then add the internal MUC component and the recorder virtual host at the end of the file. The internal MUC is where Jibri instances register themselves; the recorder host holds the account Jibri uses for the hidden Chrome session:

-- internal muc component, meant to enable pools of jibri and jigasi clients
Component "internal.auth.meet.example.com" "muc"
    modules_enabled = {
        "ping";
    }
    storage = "memory"
    muc_room_cache_size = 1000

VirtualHost "recorder.meet.example.com"
    modules_enabled = {
        "ping";
    }
    authentication = "internal_plain"

Reload Prosody and create the two accounts Jibri will authenticate with - one for control traffic, one for joining the call:

sudo systemctl reload prosody
sudo prosodyctl register jibri auth.meet.example.com JibriPassword
sudo prosodyctl register recorder recorder.meet.example.com RecorderPassword

Step 2 - Configure Jicofo

Point Jicofo at the brewery MUC so it knows where to find idle Jibri instances. On current Jitsi packages this lives in jicofo.conf:

sudo nano /etc/jitsi/jicofo/jicofo.conf

Add a jibri block inside the top-level jicofo block:

jicofo {
  jibri {
    brewery-jid = "JibriBrewery@internal.auth.meet.example.com"
    pending-timeout = 90 seconds
  }
}

Restart Jicofo:

sudo systemctl restart jicofo

Step 3 - Enable recording in the Jitsi Meet config

Edit the web config for your deployment:

sudo nano /etc/jitsi/meet/meet.example.com-config.js

Set the following properties:

fileRecordingsEnabled: true,   // enables the "Start recording" button
liveStreamingEnabled: true,    // enables "Start live stream" (RTMP/YouTube)
hiddenDomain: 'recorder.meet.example.com',

hiddenDomain is what keeps the recorder account invisible - anyone logged in from that domain joins silently and never appears in the participant list.

Step 4 - Install Jibri on the Ubuntu 22.04 machine

Everything from here on happens on the dedicated Jibri machine, not the Jitsi server.

ALSA loopback module

Jibri captures audio through the ALSA loopback kernel module. On Ubuntu 22.04 it ships in the extra modules package:

sudo apt update
sudo apt install linux-modules-extra-$(uname -r)
echo "snd_aloop" | sudo tee -a /etc/modules
sudo modprobe snd_aloop
lsmod | grep snd_aloop

If the last command prints a snd_aloop line, audio capture is ready. On cloud images the package name can differ - AWS instances want linux-modules-extra-aws for example.

ffmpeg and supporting packages

The ffmpeg build in the Ubuntu 22.04 repos already includes x11 capture support, so the stock package is fine:

sudo apt install ffmpeg wget gnupg curl unzip alsa-utils icewm xdotool \
  xserver-xorg-input-void xserver-xorg-video-dummy

Google Chrome and ChromeDriver

Install Chrome from Google's repository:

curl -fsSL https://dl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /usr/share/keyrings/google-chrome.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/google-chrome.gpg] http://dl.google.com/linux/chrome/deb/ stable main" | sudo tee /etc/apt/sources.list.d/google-chrome.list
sudo apt update
sudo apt install google-chrome-stable

ChromeDriver must match the installed Chrome version. Google now distributes it through the Chrome for Testing endpoints (the old chromedriver.storage.googleapis.com URL stopped updating at Chrome 114, which is a common trap in older guides):

CHROME_VERSION=$(google-chrome --version | awk '{print $3}')
wget -N "https://storage.googleapis.com/chrome-for-testing-public/${CHROME_VERSION}/linux64/chromedriver-linux64.zip"
unzip chromedriver-linux64.zip
sudo mv -f chromedriver-linux64/chromedriver /usr/local/bin/chromedriver
sudo chmod 0755 /usr/local/bin/chromedriver
chromedriver --version

Silence Chrome's "automated software" warning bar, which would otherwise appear in every recording:

sudo mkdir -p /etc/opt/chrome/policies/managed
echo '{ "CommandLineFlagSecurityWarningsEnabled": false }' | sudo tee /etc/opt/chrome/policies/managed/managed_policies.json

Install the Jibri package

Add the Jitsi repository and install Jibri along with Java 11, which current Jibri builds require:

curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jitsi-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install openjdk-11-jre-headless jibri

Give the jibri user access to the audio and video devices:

sudo usermod -aG adm,audio,video,plugdev jibri

Step 5 - Configure jibri.conf

Modern Jibri reads a HOCON config at /etc/jitsi/jibri/jibri.conf (the JSON config.json you may remember from older guides is deprecated). Open it:

sudo nano /etc/jitsi/jibri/jibri.conf

Use this as the full config, swapping in your domain and the two passwords from Step 1:

jibri {
  recording {
    recordings-directory = "/srv/recordings"
    finalize-script = "/srv/finalize_recording.sh"
  }
  api {
    xmpp {
      environments = [
        {
          name = "prod environment"
          xmpp-server-hosts = ["meet.example.com"]
          xmpp-domain = "meet.example.com"

          control-muc {
            domain = "internal.auth.meet.example.com"
            room-name = "JibriBrewery"
            nickname = "jibri-instance-1"
          }
          control-login {
            domain = "auth.meet.example.com"
            username = "jibri"
            password = "JibriPassword"
          }
          call-login {
            domain = "recorder.meet.example.com"
            username = "recorder"
            password = "RecorderPassword"
          }

          strip-from-room-domain = "conference."
          usage-timeout = 0

          // set to true if your Jitsi server uses a self-signed certificate
          trust-all-xmpp-certs = false
        }
      ]
    }
  }
}

Two details worth calling out. room-name = "JibriBrewery" must match the brewery-jid you set in Jicofo. And trust-all-xmpp-certs = true replaces the old hack of patching JibriSelenium.kt and recompiling the jar just to accept a self-signed certificate - do not follow guides that still recommend rebuilding Jibri for that.

Create the recordings directory and hand it to the jibri user:

sudo mkdir -p /srv/recordings
sudo chown jibri:jibri /srv/recordings

Step 6 - Start Jibri and run a test recording

Restart the Jitsi-side services once more, then enable and start Jibri:

# on the Jitsi server
sudo systemctl restart prosody jicofo jitsi-videobridge2

# on the Jibri machine
sudo systemctl enable --now jibri
sudo journalctl -u jibri -f

In the journal you want to see Jibri connect to both XMPP hosts and join the brewery. Then open a meeting on your Jitsi instance, press Start recording, talk for half a minute, stop it, and check /srv/recordings on the Jibri machine for an mp4.

Uploading recordings to S3

The finalize-script runs after every recording completes, which makes it the natural place to ship files off the box. A minimal S3 uploader (requires the AWS CLI and an instance role or credentials with write access to the bucket):

#!/bin/bash
RECORDINGS_DIR=$1

aws s3 cp --recursive ${RECORDINGS_DIR} s3://your-recordings-bucket

if [ -d "$RECORDINGS_DIR" ]; then
    rm -r ${RECORDINGS_DIR}
fi

exit 0

Save it as /srv/finalize_recording.sh and make it executable:

sudo chmod +x /srv/finalize_recording.sh && sudo chown jibri:jibri /srv/finalize_recording.sh

For Dropbox instead of S3, Jitsi Meet has a built-in integration: create a Dropbox app, then add its key under dropbox: in your meet.example.com-config.js with the redirect URI https://meet.example.com/static/oauth.html. Users then pick Dropbox when they start a recording.

Running Jibri with Docker

If your Jitsi deployment runs on docker-jitsi-meet, skip the manual install above - the project ships a ready Jibri container. Set the Jibri variables in your .env (they map to the same Prosody accounts from Step 1) and start the stack with the overlay file:

docker compose -f docker-compose.yml -f jibri.yml up -d

The host still needs the snd_aloop module loaded, since the container captures audio through the host kernel.

Troubleshooting common Jibri failures

• "Recording failed to start" in the meeting UI: Jicofo cannot find a Jibri in the brewery. Check that brewery-jid in jicofo.conf and control-muc in jibri.conf use the same room and domain, and watch journalctl -u jibri -f for XMPP login errors (wrong password from Step 1 is the classic cause).
• Recording starts, then dies within seconds: usually a Chrome vs ChromeDriver version mismatch (re-run the ChromeDriver install after any Chrome update) or a certificate problem - set trust-all-xmpp-certs = true when testing with self-signed certs.
• Video records but audio is missing:snd_aloop is not loaded. Run lsmod | grep snd_aloop, and remember cloud kernels need their own extra-modules package (e.g. linux-modules-extra-aws).
• Second recording refuses to start: that is by design - one Jibri handles one session. Add more Jibri machines with unique nickname values pointed at the same brewery.

Skip the manual setup: Jitsi Meet with recording, pre-configured

Everything above is what we automate in our Marketplace images. If you would rather launch a Jitsi Meet server where Jibri, the hidden domains, and the recording pipeline are already wired up and supported, these deploy in a few minutes:

Jitsi Meet on AWS Marketplace

Pre-configured Jitsi Meet AMIs supported by Meetrix, sized from 50 to 500 concurrent users, with recording variants that include Jibri out of the box.

100-user server with recording250-user server with recordingBrowse all Meetrix products

Jitsi Meet on Google Cloud Marketplace

The same Jitsi Meet stack published for Google Cloud - every size from 50 to 500 users is also available in a recording variant with Jibri included.

100-user server with recording250-user server with recordingBrowse all Meetrix products

There is also a full walkthrough of the AWS recording AMI in our Jitsi Meet with recordings developer guide.

Conclusion

A working Jibri setup comes down to four things lining up: the hidden MUC and recorder host in Prosody, the brewery JID in Jicofo, matching credentials in jibri.conf, and a Jibri machine whose Chrome, ChromeDriver, and ALSA loopback are all healthy. Once those agree, the record button in Jitsi Meet just works, and scaling to more concurrent recordings is only a matter of cloning the Jibri machine.