Deploying Jibri in a Private LAN

Recording works fine on a public Jitsi Meet server and then falls over the moment you move the same setup onto an internal network. The meeting itself is fine. Press record, Jibri goes to PENDING, and thirty seconds later the button flips back off with no explanation in the UI.

Nearly always it is the certificate. Jibri is not a headless API client, it is a real Chrome session driven by Selenium plus an XMPP client, and both halves refuse a certificate your browser would merely warn you about.

This page covers only the parts that are different on a private LAN. For the install itself, work through How to Set Up Jibri for Jitsi Meet Recording and Streaming on Ubuntu 22.04 first, then come back and apply the changes below.

What actually breaks on a LAN

Three assumptions in a default Jitsi install stop holding when there is no public domain:

Everything else, the brewery MUC, the recorder account, the ALSA loopback module, is identical to a public deployment.

Pointing Jibri at the internal address

By default Jibri works out which page to open from the room JID it is asked to record. On a LAN that produces a hostname nothing can resolve. Set base-url on the XMPP environment and Jibri joins that address instead:

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

jibri {
  api {
    xmpp {
      environments = [
        {
          name = "internal environment"
          xmpp-server-hosts = [ "10.0.10.5" ]
          xmpp-domain = "meet.internal.example.com"

          // The address Jibri's Chrome will actually open
          base-url = "https://meet.internal.example.com"

          control-muc {
            domain = "internal.auth.meet.internal.example.com"
            room-name = "JibriBrewery"
            nickname = "jibri-01"
          }

          control-login {
            domain = "auth.meet.internal.example.com"
            username = "jibri"
            password = "JibrisPass"
          }

          call-login {
            domain = "recorder.meet.internal.example.com"
            username = "recorder"
            password = "RecordersPass"
          }

          strip-from-room-domain = "conference."
          usage-timeout = 0
          trust-all-xmpp-certs = true
        }
      ]
    }
  }
}

Note that xmpp-server-hosts takes the internal IP of the Prosody machine while xmpp-domain stays a hostname. That split is deliberate. Jibri connects to the IP, then presents the domain during the XMPP handshake, so the domain has to match what Prosody is configured for even though nothing on the public internet resolves it.

Getting past the self-signed certificate

This is the part that costs people an afternoon. There are two separate certificate checks in Jibri and fixing one does nothing for the other.

The XMPP connection

Jibri's XMPP client validates Prosody's certificate. One line per environment turns that off:

trust-all-xmpp-certs = true

If this is wrong you get an authentication or TLS failure in /var/log/jitsi/jibri/log.0.txt and Jibri never appears in the brewery at all. The symptom is a recording button that is greyed out or reports no available recorder, because Jicofo has nobody to hand the job to.

The Chrome session

The second check happens when Jibri opens the meeting. Chrome hits the same self-signed certificate and shows its interstitial, so ffmpeg captures a warning page. Add the flag to the Chrome flag list:

jibri {
  chrome {
    flags = [
      "--use-fake-ui-for-media-stream",
      "--start-maximized",
      "--kiosk",
      "--enabled",
      "--autoplay-policy=no-user-gesture-required",
      "--ignore-certificate-errors"
    ]
  }
}

The list replaces the defaults rather than adding to them, so keep the five original flags and append yours. Dropping --use-fake-ui-for-media-stream in particular will leave Chrome sitting on a camera permission prompt forever.

Then restart and watch it join:

sudo systemctl restart jibri
sudo journalctl -u jibri -f

A healthy start logs the brewery join within a few seconds. If the log stops after the Selenium session opens, it is still Chrome, not XMPP.

Jicofo and private-address ICE

Jicofo has a setting that decides whether private addresses are allowed as ICE candidates for Jibri. On a LAN, private addresses are the only ones there are:

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

It defaults to true, so on a clean install you do not need to add it. Check it anyway if you inherited a config from a public deployment where somebody turned it off, because the failure it produces looks like a Jibri problem rather than a Jicofo one: the recorder joins the room, ICE never connects, and the session dies at the 30 second timeout.

Steps you can now skip

Most LAN guides for Jibri were written around 2020 and a good half of what they tell you to do is now either unnecessary or actively wrong. If you are following one, here is what has changed.

The Jibri launcher still passes --config /etc/jitsi/jibri/config.json for backwards compatibility, which is why the old file sometimes appears to still work. jibri.conf is the file that is actually read for everything in this article. Editing only config.json on a current build gets you silence.

What a LAN deployment costs you

Worth being clear about the trade before you commit to it.

• Browsers will complain. Every participant gets a certificate warning and has to click through it, unless you distribute an internal CA to every machine.
• The mobile apps are the hard limit. Android stopped trusting user-installed CAs for app traffic in Android 7, so even a device-installed root certificate usually will not get the Jitsi Meet app to connect. Plan for browser-only access, or use a publicly trusted certificate.
• Live streaming still needs the internet. RTMP goes out to YouTube or wherever you are sending it. File recording is genuinely offline-capable, streaming is not.
• Recordings pile up locally. With no S3 bucket to finalize into, recordings-directory fills the disk. Set a finalize script that moves files onto a network share and prunes them.

There is a middle path that avoids most of this: keep the deployment internal, but get a real certificate for an internal hostname through DNS-01 validation. The server never has to be reachable from outside, the mobile apps work, and nobody clicks through a warning. It is worth the extra half hour.

Related Articles

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

Step-by-step Jibri setup for Jitsi Meet recording and live streaming on Ubuntu 22.04: Prosody and Jicofo configuration, jibri.conf, S3 uploads, Docker, and troubleshooting.

By Hiruna Kumara • Meetrix.io

Setup Jitsi Meet with Recordings - Developer Guide

A comprehensive guide to setting up Jitsi Meet with recording capabilities on AWS, including detailed steps for deployment, configuration, and management.

By Hiruna Kumara • Meetrix.io

Fix Jicofo Configuration Errors in Jitsi Meet

A jicofo configuration error is nearly always one of four values: xmpp-domain, the auth domain, the brewery MUC JID, or jvb.conf. Here is how to tell which one.

By Hiruna Kumara • Meetrix.io

What Ports You Should Open to Run Jitsi Meet

The Jitsi ports you have to open in your firewall or EC2 security group, which of them can stay private, and why TCP 4443 is no longer on the list.

By Buddhika Jayawardhana • Meetrix.io

Jitsi Meet and Firewalls: Getting Media Over TCP

How to get Jitsi Meet media through a corporate firewall that blocks UDP, and why two of the four classic TCP options stopped working when the videobridge TCP harvester was removed.

By Buddhika Jayawardhana • Meetrix.io

Jitsi Architecture: A Deep Dive into Its Core Components

How the Jitsi Meet architecture fits together: Nginx, Jicofo, Prosody, the Jitsi Videobridge (JVB), Jigasi, Jibri, and the React frontend, and how the Jitsi Videobridge architecture routes media between participants.

By Hiruna Kumara • Meetrix.io