Jitsi

• Instalação Jitsi Docker
• Repositório Jitsi Docker
• Self-Hosting Guide - Docker Installation
• Scalable setup Jitsi Docker
• Self-Hosting Guide - Docker (2025)
• Configurações Jitsi Docker
• Jitsi Meet Load Balancing
• Load Testing Jitsi Meet
• Self-Hosting Guide - Log Analyser

Instalação Jitsi Docker

Repositório Jitsi Docker

Link: https://github.com/jitsi/docker-jitsi-meet?tab=readme-ov-file

git clone https://github.com/jitsi/docker-jitsi-meet.git

Jitsi-contrib: https://github.com/jitsi-contrib

Jitsi Meet on Docker

Jitsi is a set of Open Source projects that allows you to easily build and deploy secure videoconferencing solutions.

Jitsi Meet is a fully encrypted, 100% Open Source video conferencing solution that you can use all day, every day, for free — with no account needed.

This repository contains the necessary tools to run a Jitsi Meet stack on Docker using Docker Compose.

All our images are published on DockerHub.

Supported architectures

Starting with stable-7439 the published images are available for amd64 and arm64.

Tags

These are the currently published tags for all our images:

Installation

The installation manual is available here.

Kubernetes

If you plan to install the jitsi-meet stack on a Kubernetes cluster you can find tools and tutorials in the project Jitsi on Kubernetes.

TODO

• Builtin TURN server.

Self-Hosting Guide - Docker Installation

Link: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/

Update 04/07/2024

Quick start​

In order to quickly run Jitsi Meet on a machine running Docker and Docker Compose, follow these steps:

1. Download and extract the latest release. DO NOT clone the git repository. See below if you are interested in running test images:

   wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)

2. Unzip the package:

   unzip <filename>

3. Create a .env file by copying and adjusting env.example:

   cp env.example .env

4. Set strong passwords in the security section options of .env file by running the following bash script

   ./gen-passwords.sh

5. Create required CONFIG directories

   • For linux:

   mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}

   • For Windows:

   echo web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri | % { mkdir "~/.jitsi-meet-cfg/$_" }

6. Run docker compose up -d

7. Access the web UI at https://localhost:8443 (or a different port, in case you edited the .env file).

NOTE
HTTP (not HTTPS) is also available (on port 8000, by default), but that's e.g. for a reverse proxy setup; direct access via HTTP instead HTTPS leads to WebRTC errors such as Failed to access your microphone/camera: Cannot use microphone/camera for an unknown reason. Cannot read property 'getUserMedia' of undefined or navigator.mediaDevices is undefined.

If you want to use jigasi too, first configure your env file with SIP credentials and then run Docker Compose as follows:

docker compose -f docker-compose.yml -f jigasi.yml up

If you want to enable document sharing via Etherpad, configure it and run Docker Compose as follows:

docker compose -f docker-compose.yml -f etherpad.yml up

If you want to use jibri too, first configure a host as described in Jitsi Broadcasting Infrastructure configuration section and then run Docker Compose as follows:

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

or to use jigasi too:

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

Updating​

If you want to update, simply run

wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)

again (just like how you initially downloaded Jitsi). Then unzip and overwrite all when being asked:

unzip <filename>

Testing development / unstable builds​

Download the latest code:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet

NOTE

The code in master is designed to work with the unstable images. Do not run it with release images.

Run docker compose up as usual.

Every day a new "unstable" image build is uploaded.

Building your own images​

Download the latest code:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet

The provided Makefile provides a comprehensive way of building the whole stack or individual images.

To build all images:

make

To build a specific image (the web image for example):

make build_web

Once your local build is ready make sure to add JITSI_IMAGE_VERSION=latest to your .env file.

Security note​

This setup used to have default passwords for internal accounts used across components. In order to make the default setup secure by default these have been removed and the respective containers won't start without having a password set.

Strong passwords may be generated as follows: ./gen-passwords.sh This will modify your .env file (a backup is saved in .env.bak) and set strong passwords for each of the required options. Passwords are generated using openssl rand -hex 16 .

DO NOT reuse any of the passwords.

Architecture​

A Jitsi Meet installation can be broken down into the following components:

• A web interface
• An XMPP server
• A conference focus component
• A video router (could be more than one)
• A SIP gateway for audio calls
• A Broadcasting Infrastructure for recording or streaming a conference.

The diagram shows a typical deployment in a host running Docker. This project separates each of the components above into interlinked containers. To this end, several container images are provided.

External Ports​

The following external ports must be opened on a firewall:

• 80/tcp for Web UI HTTP (really just to redirect, after uncommenting ENABLE_HTTP_REDIRECT=1 in .env)
• 443/tcp for Web UI HTTPS
• 10000/udp for RTP media over UDP

Also 20000-20050/udp for jigasi, in case you choose to deploy that to facilitate SIP access.

E.g. on a CentOS/Fedora server this would be done like this (without SIP access):

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --permanent --add-port=10000/udp
sudo firewall-cmd --reload

See the corresponding section in the debian/ubuntu setup guide.

Images​

• base: Debian stable base image with the S6 Overlay for process control and the Jitsi repositories enabled. All other images are based on this one.
• base-java: Same as the above, plus Java (OpenJDK).
• web: Jitsi Meet web UI, served with nginx.
• prosody: Prosody, the XMPP server.
• jicofo: Jicofo, the XMPP focus component.
• jvb: Jitsi Videobridge, the video router.
• jigasi: Jigasi, the SIP (audio only) gateway.
• jibri: Jibri, the broadcasting infrastructure.

Design considerations​

Jitsi Meet uses XMPP for signaling, thus the need for the XMPP server. The setup provided by these containers does not expose the XMPP server to the outside world. Instead, it's kept completely sealed, and routing of XMPP traffic only happens on a user-defined network.

The XMPP server can be exposed to the outside world, but that's out of the scope of this project.

Configuration​

The configuration is performed via environment variables contained in a .env file. You can copy the provided env.example file as a reference.

NOTE

The mobile apps won't work with self-signed certificates (the default). See below for instructions on how to obtain a proper certificate with Let's Encrypt.

TLS Configuration​

Let's Encrypt configuration​

If you want to expose your Jitsi Meet instance to the outside traffic directly, but don't own a proper TLS certificate, you are in luck because Let's Encrypt support is built right in. Here are the required options:

In addition, you will need to set HTTP_PORT to 80 and HTTPS_PORT to 443 and PUBLIC_URL to your domain. You might also consider to redirect HTTP traffic to HTTPS by setting ENABLE_HTTP_REDIRECT=1.

Let's Encrypt rate limit warning: Let's Encrypt has a limit to how many times you can submit a request for a new certificate for your domain name. At the time of writing, the current limit is five new (duplicate) certificates for the same domain name every seven days. Because of this, it is recommended that you disable the Let's Encrypt environment variables from .env if you plan on deleting the .jitsi-meet-cfg folder. Otherwise, you might want to consider moving the .jitsi-meet-cfg folder to a different location so you have a safe place to find the certificate that already Let's Encrypt issued. Or do initial testing with Let's Encrypt disabled, then re-enable Let's Encrypt once you are done testing.

NOTE

When you move away from LETSENCRYPT_USE_STAGING, you will have to manually clear the certificates from .jitsi-meet-cfg/web.

For more information on Let's Encrypt's rate limits, visit: https://letsencrypt.org/docs/rate-limits/

Using existing TLS certificate and key​

If you own a proper TLS certificate and don't need a Let's Encrypt certificate, you can configure Jitsi Meet container to use it.

Unlike Let's Encrypt certificates, this is not configured through the .envfile, but by telling Jitsi Meet's web service to mount the following two volumes:

• mount /path/to/your/cert.key file to /config/keys/cert.key mount point
• mount /path/to/your/cert.fullchain file to the /config/keys/cert.crt mount point.

Doing it in docker-compose.yml file should look like this:

services:
    web:
        ...
        volumes:
            ...
            - /path/to/your/cert.fullchain:/config/keys/cert.crt
            - /path/to/your/cert.key:/config/keys/cert.key

Features configuration (config.js)​

Jigasi SIP gateway (audio only) configuration​

If you want to enable the SIP gateway, these options are required:

Display Dial-In information​

The JSON with the Dial-In numbers should look like this:

{"message":"Dial-In numbers:","numbers":{"DE": ["+49-721-0000-0000"]},"numbersEnabled":true}

Recording / live streaming configuration with Jibri​

If you want to enable Jibri these options are required:

Extended Jibri configuration:

Jitsi Meet configuration​

Jitsi-Meet uses two configuration files for changing default settings within the web interface: config.js and interface_config.js. The files are located within the CONFIG/web/ directory configured within your environment file.

These files are re-created on every container restart. If you'd like to provide your own settings, create your own config files: custom-config.js and custom-interface_config.js.

It's enough to provide your relevant settings only, the docker scripts will append your custom files to the default ones!

Authentication​

Authentication can be controlled with the environment variables below. If guest access is enabled, unauthenticated users will need to wait until a user authenticates before they can join a room. If guest access is not enabled, every user will need to authenticate before they can join.

If authentication is enabled, once an authenticated user logged in, it is always logged in before the session timeout. You can set ENABLE_AUTO_LOGIN=0 to disable this default auto login feature or you can set JICOFO_AUTH_LIFETIME to limit the session lifetime.

Internal authentication​

The default authentication mode (internal) uses XMPP credentials to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to internal, then configure the settings you can see below.

Internal users must be created with the prosodyctl utility in the prosody container. In order to do that, first, execute a shell in the corresponding container:

docker compose exec prosody /bin/bash

Once in the container, run the following command to create a user:

prosodyctl --config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword

Note that the command produces no output.

To delete a user, run the following command in the container:

prosodyctl --config /config/prosody.cfg.lua unregister TheDesiredUsername meet.jitsi

To list all users, run the following command in the container:

find /config/data/meet%2ejitsi/accounts -type f -exec basename {} .dat \;

Authentication using LDAP​

You can use LDAP to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to ldap, then configure the settings you can see below.

Authentication using JWT tokens​

You can use JWT tokens to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to jwt, then configure the settings you can see below.

This can be tested using the jwt.io debugger. Use the following sample payload:

{
  "context": {
    "user": {
      "avatar": "https://robohash.org/john-doe",
      "name": "John Doe",
      "email": "jdoe@example.com"
    }
  },
  "aud": "my_jitsi_app_id",
  "iss": "my_jitsi_app_id",
  "sub": "meet.jitsi",
  "room": "*"
}

Authentication using Matrix​

For more information see the documentation of the "Prosody Auth Matrix User Verification" here.

Authentication using Hybrid Matrix Token​

You can use Hybrid Matrix Token to authenticate users. It supports Matrix and JWT Token authentications on the same setup. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to hybrid_matrix_token, then configure the settings you can see below.

For more information see the documentation of the "Hybrid Matrix Token" here.

External authentication​

Shared document editing using Etherpad​

You can collaboratively edit a document via Etherpad. In order to enable it, set the config options below and run Docker Compose with the additional config file etherpad.yml.

Here are the required options:

Transcription configuration​

If you want to enable the Transcribing function, these options are required:

For setting the Google Cloud Credentials please read https://cloud.google.com/text-to-speech/docs/quickstart-protocol> section "Before you begin" paragraph 1 to 5.

Sentry logging configuration​

TURN server configuration​

Configure external TURN servers.

Advanced configuration​

These configuration options are already set and generally don't need to be changed.

Advanced Prosody options​

Advanced Jicofo options​

Advanced JVB options​

Advanced Jigasi options​

Running behind NAT or on a LAN environment​

When running running in a LAN environment, or on the public Internet via NAT, the JVB_ADVERTISE_IPS env variable should be set. This variable allows to control which IP addresses the JVB will advertise for WebRTC media traffic.

NOTE

This variable used to be called DOCKER_HOST_ADDRESS but it got renamed for clarity and to support a list of IPs.

If your users are coming in over the Internet (and not over LAN), this will likely be your public IP address. If this is not set up correctly, calls will crash when more than two users join a meeting.

The public IP address is attempted to be discovered via STUN. STUN servers can be specified with the JVB_STUN_SERVERS option.

NOTE

Due to a bug in the docker version currently in the Debian repos (20.10.5), Docker does not listen on IPv6 ports, so for that combination you will have to manually obtain the latest version.

Split horizon​

If you are running in a split horizon environemt (LAN internal clients connect to a local IP and other clients connect to a public IP) you can specify multiple advertised IPs by separating them with commas:

JVB_ADVERTISE_IPS=192.168.1.1,1.2.3.4

Offline / airgapped installation​

If your setup does not have access to the Internet you'll need to disable STUN on the JVB since discovering its own IP address will fail, but that is not necessary on that type of environment.

JVB_DISABLE_STUN=true

Accessing server logs​

The default bahavior of docker-jitsi-meet is to log to stdout.

While the logs are sent to stdout, they are not lost: unless configured to drop all logs, Docker keeps them available for future retrieval and processing.

If you need to access the container's logs you have multiple options. Here are the main ones:

• run docker compose logs -t -f <service_name> from command line, where <service_name> is one of web, prosody,jvb, jicofo. This command will output the logs for the selected service to stdout with timestamps.
• use a standard docker logging driver to redirect the logs to the desired target (for instance syslog or splunk).
• search docker hub for a third party docker logging driver plugin
• or write your own driver plugin if you have a very specific need.

For instance, if you want to have all logs related to a <service_name> written to /var/log/jitsi/<service_name> as json output, you could use docker-file-log-driver and configure it by adding the following block in your docker-compose.yml file, at the same level as the image block of the selected <service_name>:

services:
    <service_name>:
        image: ...
        ...
        logging:
            driver: file-log-driver
            options:
                fpath: "/jitsi/<service_name>.log"

If you want to only display the message part of the log in json format, simply execute the following command (for instance if fpath was set to /jitsi/jvb.log) which uses jq to extract the relevant part of the logs:

sudo cat /var/log/jitsi/jvb.log | jq -r '.msg' | jq -r '.message'

Build Instructions​

Building your images allows you to edit the configuration files of each image individually, providing more customization for your deployment.

The docker images can be built by running the make command in the main repository folder. If you need to overwrite existing images from the remote source, use FORCE_REBUILD=1 make.

If you are on the unstable branch, build the images with FORCE_REBUILD=1 JITSI_RELEASE=unstable make.

You are now able to run docker compose up as usual.

Running behind a reverse proxy​

By default this setup is using WebSocket connections for 2 core components:

• Signalling (XMPP)
• Bridge channel (colibri)

Due to the hop-by-hop nature of WebSockets the reverse proxy must properly terminate and forward WebSocket connections. There 2 routes require such treatment:

• /xmpp-websocket
• /colibri-ws

With nginx, these routes can be forwarded using the following config snippet:

location /xmpp-websocket {
    proxy_pass https://localhost:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}
location /colibri-ws {
    proxy_pass https://localhost:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

In addition we need a route for /http-bind as XMPP over BOSH is still used by mobile clients:

location /http-bind {
    proxy_pass https://localhost:8443;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

With apache, mod_proxy and mod_proxy_wstunnel need to be enabled and these routes can be forwarded using the following config snippet:

<IfModule mod_proxy.c>
    <IfModule mod_proxy_wstunnel.c>
        ProxyTimeout 900
        <Location "/xmpp-websocket">
            ProxyPass "wss://localhost:8443/xmpp-websocket"
        </Location>
        <Location "/colibri-ws/">
            ProxyPass "wss://localhost:8443/colibri-ws/"
        </Location>
        <Location "/http-bind">
            ProxyPass "http://localhost:8443/http-bind"
        </Location>
    </IfModule>
</IfModule>

where https://localhost:8443/ is the url of the web service's ingress.

Disabling WebSocket connections

NOTE

This is not the recommended setup.

If using WebSockets is not an option, these environment variables can be set to fallback to HTTP polling and WebRTC datachannels:

ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0

Scalable setup Jitsi Docker

Link: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-scalable

A single server Jitsi installation is good for a limited size of concurrent conferences. The first limiting factor is the videobridge component, that handles the actual video and audio traffic. It is easy to scale the video bridges horizontally by adding as many as needed. In a cloud based environment, additionally the bridges can be scaled up or down as needed.

DANGER

The Youtube Tutorial on Scaling is outdated and describes an old configuration method. The current default Jitsi Meet install is already configured for horizontal scalability.

NOTE

Building a scalable infrastructure is not a task for beginning Jitsi Administrators. The instructions assume that you have installed a single node version successfully, and that you are comfortable installing, configuring and debugging Linux software. This is not a step-by-step guide, but will show you, which packages to install and which configurations to change. It is highly recommended to use configuration management tools like Ansible or Puppet to manage the installation and configuration.

Architecture (Single Jitsi-Meet, multiple videobridges)​

A first step is to split the functions of the central jitsi-meet instance (with nginx, prosody and jicofo) and videobridges.

A simplified diagram (with open network ports) of an installation with one Jitsi-Meet instance and three videobridges that are load balanced looks as follows. Each box is a server/VM.

               +                                       +
               |                                       |
               |                                       |
               v                                       v
          80, 443 TCP                          443 TCP, 10000 UDP
       +--------------+                     +---------------------+
       |  nginx       |  5222 TCP           |                     |
       |  Jitsi Meet  |<-------------------+|  jitsi-videobridge  |
       |  prosody     |         |           |                     |
       |  jicofo      |         |           +---------------------+
       +--------------+         |
                                |           +---------------------+
                                |           |                     |
                                +----------+|  jitsi-videobridge  |
                                |           |                     |
                                |           +---------------------+
                                |
                                |           +---------------------+
                                |           |                     |
                                +----------+|  jitsi-videobridge  |
                                            |                     |
                                            +---------------------+

Machine Sizing​

The Jitsi-Meet server will generally not have that much load (unless you have many) conferences going at the same time. A 4 CPU, 8 GB machine will probably be fine.

The videobridges will have more load. 4 or 8 CPU with 8 GB RAM seems to be a good configuration.

Installation of Jitsi-Meet​

Assuming that the installation will run under the following FQDN: meet.example.com and you have SSL cert and key in /etc/ssl/meet.example.com.{crt,key}

Set the following DebConf variables prior to installing the packages. (We are not installing the jitsi-meet package which would handle that for us)

Install the debconf-utils package

$ cat << EOF | sudo debconf-set-selections
jitsi-videobridge   jitsi-videobridge/jvb-hostname  string  meet.example.com
jitsi-meet  jitsi-meet/jvb-serve    boolean false
jitsi-meet-prosody  jitsi-videobridge/jvb-hostname  string  meet.example.com
jitsi-meet-web-config   jitsi-meet/cert-choice  select  I want to use my own certificate
jitsi-meet-web-config   jitsi-meet/cert-path-crt    string  /etc/ssl/meet.example.com.crt
jitsi-meet-web-config   jitsi-meet/cert-path-key    string  /etc/ssl/meet.example.com.key
jitsi-meet-web-config   jitsi-meet/jaas-choice  boolean false
EOF

To enable integration with Jitsi Meet Components for telephony support, set the jitsi-meet/jaas-choice option above to true.

On the jitsi-meet server, install the following packages:

• nginx
• prosody
• jicofo
• jitsi-meet-web
• jitsi-meet-prosody
• jitsi-meet-web-config

Installation of Videobridge(s)​

For simplicities sake, set the same debconf variables as above and install

• jitsi-videobridge2

Configuration of jitsi-meet​

Firewall​

Open the following ports:

Open to world:

• 80 TCP
• 443 TCP

Open to the videobridges only

• 5222 TCP (for Prosody)

NGINX​

Create the /etc/nginx/sites-available/meet.example.com.conf as usual

Jitsi-Meet​

Adapt /usr/share/jitsi-meet/config.js and /usr/share/jitsi-meet/interface-config.js to your specific needs

Jicofo​

No changes necessary from the default install.

Configuration of the Videobridge​

Firewall​

Open the following ports:

Open to world:

• 10000 UDP (for media)

jitsi-videobridge2​

No changes necessary from the default setup.

Testing​

After restarting all services (prosody, jicofo and all the jitsi-videobridge2) you can see in /var/log/prosody/prosody.log and /var/log/jitsi/jicofo.log that the videobridges connect to Prososy and that Jicofo picks them up.

When a new conference starts, Jicofo picks a videobridge and schedules the conference on it.

Self-Hosting Guide - Docker (2025)

Link: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/   Last updated on Mar 7, 2025

Quick start​

In order to quickly run Jitsi Meet on a machine running Docker and Docker Compose, follow these steps:

HTTP (não HTTPS) também está disponível (na porta 8000, por padrão), mas isso é, por exemplo, para uma configuração de proxy reverso; acesso direto via HTTP em vez de HTTPS leva a erros WebRTC, como Falha ao acessar seu microfone/câmera: Não é possível usar o microfone/câmera por um motivo desconhecido. Não é possível ler a propriedade 'getUserMedia' de undefined ou navigator.mediaDevices é undefined.

IMPORTANT: When deploying Jitsi Meet for real use you must set the PUBLIC_URL env variable to the real domain where your setup is running.

If you want to use jigasi too, first configure your env file with SIP credentials and then run Docker Compose as follows:

docker compose -f docker-compose.yml -f jigasi.yml up

If you want to enable document sharing via Etherpad, configure it and run Docker Compose as follows:

docker compose -f docker-compose.yml -f etherpad.yml up

If you want to use jibri too, first configure a host as described in Jitsi Broadcasting Infrastructure configuration section and then run Docker Compose as follows:

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

or to use jigasi too:

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

To include a transcriber component, run Docker Compose as follows:

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

Or for them all together:

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

For the log analysis project, you will need both log-analyser.yml and grafana.yml files. This project allows you to analyze docker logs in grafana. If you want to run the log analyzer, run the Docker files as follows:

docker-compose -f docker-compose.yml -f log-analyser.yml -f grafana.yml up -d

Follow this document for detailed information on log analysis.

Updating​

If you want to update, simply run

wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)

again (just like how you initially downloaded Jitsi). Then unzip and overwrite all when being asked:

unzip <filename>

Testing development / unstable builds​

Download the latest code:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet

The code in master is designed to work with the unstable images. Do not run it with release images.

Run docker compose up as usual.

Every day a new "unstable" image build is uploaded.

Building your own images​

Download the latest code:

git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet

The provided Makefile provides a comprehensive way of building the whole stack or individual images.

To build all images:

make

To build a specific image (the web image for example):

make build_web

Once your local build is ready make sure to add JITSI_IMAGE_VERSION=latest to your .env file.

Security note​

This setup used to have default passwords for internal accounts used across components. In order to make the default setup secure by default these have been removed and the respective containers won't start without having a password set.

Strong passwords may be generated as follows: ./gen-passwords.sh This will modify your .env file (a backup is saved in .env.bak) and set strong passwords for each of the required options. Passwords are generated using openssl rand -hex 16 .

DO NOT reuse any of the passwords.

Architecture​

A Jitsi Meet installation can be broken down into the following components:

The diagram shows a typical deployment in a host running Docker. This project separates each of the components above into interlinked containers. To this end, several container images are provided.

External Ports​

The following external ports must be opened on a firewall:

Also 20000-20050/udp for jigasi, in case you choose to deploy that to facilitate SIP access.

E.g. on a CentOS/Fedora server this would be done like this (without SIP access):

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --permanent --add-port=10000/udp
sudo firewall-cmd --reload

See the corresponding section in the debian/ubuntu setup guide.

Images​

Design considerations​

Jitsi Meet uses XMPP for signaling, thus the need for the XMPP server. The setup provided by these containers does not expose the XMPP server to the outside world. Instead, it's kept completely sealed, and routing of XMPP traffic only happens on a user-defined network.

The XMPP server can be exposed to the outside world, but that's out of the scope of this project.

Configuration​

The configuration is performed via environment variables contained in a .env file. You can copy the provided env.example file as a reference.

The mobile apps won't work with self-signed certificates (the default). See below for instructions on how to obtain a proper certificate with Let's Encrypt.

TLS Configuration​

Let's Encrypt configuration​

If you want to expose your Jitsi Meet instance to the outside traffic directly, but don't own a proper TLS certificate, you are in luck because Let's Encrypt support is built right in. Here are the required options:

In addition, you will need to set HTTP_PORT to 80 and HTTPS_PORT to 443 and PUBLIC_URL to your domain. You might also consider to redirect HTTP traffic to HTTPS by setting ENABLE_HTTP_REDIRECT=1.

Let's Encrypt rate limit warning: Let's Encrypt has a limit to how many times you can submit a request for a new certificate for your domain name. At the time of writing, the current limit is five new (duplicate) certificates for the same domain name every seven days. Because of this, it is recommended that you disable the Let's Encrypt environment variables from .env if you plan on deleting the .jitsi-meet-cfg folder. Otherwise, you might want to consider moving the .jitsi-meet-cfg folder to a different location so you have a safe place to find the certificate that already Let's Encrypt issued. Or do initial testing with Let's Encrypt disabled, then re-enable Let's Encrypt once you are done testing.

When you move away from LETSENCRYPT_USE_STAGING, you will have to manually clear the certificates from .jitsi-meet-cfg/web.

For more information on Let's Encrypt's rate limits, visit: https://letsencrypt.org/docs/rate-limits/

Using existing TLS certificate and key​

If you own a proper TLS certificate and don't need a Let's Encrypt certificate, you can configure Jitsi Meet container to use it.

Unlike Let's Encrypt certificates, this is not configured through the .envfile, but by telling Jitsi Meet's web service to mount the following two volumes:

Doing it in docker-compose.yml file should look like this:

services:
    web:
        ...
        volumes:
            ...
            - /path/to/your/cert.fullchain:/config/keys/cert.crt
            - /path/to/your/cert.key:/config/keys/cert.key

Features configuration (config.js)​

Jigasi SIP gateway (audio only) configuration​

If you want to enable the SIP gateway, these options are required:

Display Dial-In information​

The JSON with the Dial-In numbers should look like this:

{"message":"Dial-In numbers:","numbers":{"DE": ["+49-721-0000-0000"]},"numbersEnabled":true}

Recording / live streaming configuration with Jibri

Details:

​If you are using a release older than 7439 some extra setup is necessary.Before running Jibri on releases older than 7439, you need to set up an ALSA loopback device on the host. This will not work on a non-Linux host. 

For CentOS 7, the module is already compiled with the kernel, so just run:

# configure 5 capture/playback interfaces
echo "options snd-aloop enable=1,1,1,1,1 index=0,1,2,3,4" > /etc/modprobe.d/alsa-loopback.conf
# setup autoload the module
echo "snd_aloop" > /etc/modules-load.d/snd_aloop.conf
# load the module
modprobe snd-aloop
# check that the module is loaded
lsmod | grep snd_aloop

For Ubuntu:

# install the module
apt update && apt install linux-image-extra-virtual
# configure 5 capture/playback interfaces
echo "options snd-aloop enable=1,1,1,1,1 index=0,1,2,3,4" > /etc/modprobe.d/alsa-loopback.conf
# setup autoload the module
echo "snd-aloop" >> /etc/modules
# check that the module is loaded
lsmod | grep snd_aloop

If you are running on AWS you may need to reboot your machine to use the generic kernel instead of the "aws" kernel. If after reboot, your machine is still using the "aws" kernel, you'll need to manually update the grub file. So just run:

# open the grub file in editor
nano /etc/default/grub
# Modify the value of GRUB_DEFAULT from "0" to "1>2"
# Save and exit from file

# Update grub
update-grub
# Reboot the machine
reboot now

For using multiple Jibri instances, you have to select different loopback interfaces for each instance manually.

Default the first instance has:

...
slave.pcm "hw:Loopback,0,0"
...
slave.pcm "hw:Loopback,0,1"
...
slave.pcm "hw:Loopback,1,1"
...
slave.pcm "hw:Loopback,1,0"
...

To setup the second instance, run container with changed /home/jibri/.asoundrc:

...
slave.pcm "hw:Loopback_1,0,0"
...
slave.pcm "hw:Loopback_1,0,1"
...
slave.pcm "hw:Loopback_1,1,1"
...
slave.pcm "hw:Loopback_1,1,0"
...

Also you can use numbering id for set loopback interface. The third instance will have .asoundrc that looks like:

...
slave.pcm "hw:2,0,0"
...
slave.pcm "hw:2,0,1"
...
slave.pcm "hw:2,1,1"
...
slave.pcm "hw:2,1,0"
...

If you want to enable Jibri these options are required:

Extended Jibri configuration:

Jitsi Meet configuration​

Jitsi-Meet uses two configuration files for changing default settings within the web interface: config.js and interface_config.js. The files are located within the CONFIG/web/ directory configured within your environment file.

These files are re-created on every container restart. If you'd like to provide your own settings, create your own config files: custom-config.js and custom-interface_config.js.

It's enough to provide your relevant settings only, the docker scripts will append your custom files to the default ones!

Authentication​

Authentication can be controlled with the environment variables below. If guest access is enabled, unauthenticated users will need to wait until a user authenticates before they can join a room. If guest access is not enabled, every user will need to authenticate before they can join.

If authentication is enabled, once an authenticated user logged in, it is always logged in before the session timeout. You can set ENABLE_AUTO_LOGIN=0 to disable this default auto login feature or you can set JICOFO_AUTH_LIFETIME to limit the session lifetime.

Internal authentication​

The default authentication mode (internal) uses XMPP credentials to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to internal, then configure the settings you can see below.

Internal users must be created with the prosodyctl utility in the prosody container. In order to do that, first, execute a shell in the corresponding container:

docker compose exec prosody /bin/bash

Once in the container, run the following command to create a user:

prosodyctl --config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword

Note that the command produces no output.

To delete a user, run the following command in the container:

prosodyctl --config /config/prosody.cfg.lua unregister TheDesiredUsername meet.jitsi

To list all users, run the following command in the container:

find /config/data/meet%2ejitsi/accounts -type f -exec basename {} .dat \;

Authentication using LDAP​

You can use LDAP to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to ldap, then configure the settings you can see below.

Authentication using JWT tokens​

You can use JWT tokens to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to jwt, then configure the settings you can see below.

This can be tested using the jwt.io debugger. Use the following sample payload:

{
  "context": {
    "user": {
      "avatar": "https://robohash.org/john-doe",
      "name": "John Doe",
      "email": "jdoe@example.com"
    }
  },
  "aud": "my_jitsi_app_id",
  "iss": "my_jitsi_app_id",
  "sub": "meet.jitsi",
  "room": "*"
}

Authentication using Matrix​

For more information see the documentation of the "Prosody Auth Matrix User Verification" here.

Authentication using Hybrid Matrix Token​

You can use Hybrid Matrix Token to authenticate users. It supports Matrix and JWT Token authentications on the same setup. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to hybrid_matrix_token, then configure the settings you can see below.

For more information see the documentation of the "Hybrid Matrix Token" here.

External authentication​

Shared document editing using Etherpad​

You can collaboratively edit a document via Etherpad. In order to enable it, set the config options below and run Docker Compose with the additional config file etherpad.yml.

Here are the required options:

Transcription configuration​

If you want to enable the Transcribing function, set the config options below and run Docker Compose with the additional config file transcriber.yml.

In addition, the following are options are used to configure the various transcription backends and features:

For setting the Google Cloud Credentials please read https://cloud.google.com/text-to-speech/docs/quickstart-protocol > section "Before you begin" paragraph 1 to 5.

Sentry logging configuration​

TURN server configuration​

Configure external TURN servers.

Advanced configuration​

These configuration options are already set and generally don't need to be changed.

Advanced Prosody options​

Advanced Jicofo options​

Advanced JVB options​

Advanced Jigasi options​

Running behind NAT or on a LAN environment​

When running running in a LAN environment, or on the public Internet via NAT, the JVB_ADVERTISE_IPS env variable should be set. This variable allows to control which IP addresses the JVB will advertise for WebRTC media traffic. It is necessary to set it regardless of the use of a reverse proxy, since it's the IP address that will receive the media (audio / video) and not HTTP traffic, hence it's oblivious to the reverse proxy.

This variable used to be called DOCKER_HOST_ADDRESS but it got renamed for clarity and to support a list of IPs.

If your users are coming in over the Internet (and not over LAN), this will likely be your public IP address. If this is not set up correctly, calls will crash when more than two users join a meeting.

The public IP address is attempted to be discovered via STUN. STUN servers can be specified with the JVB_STUN_SERVERS option.

Due to a bug in the docker version currently in the Debian repos (20.10.5), Docker does not listen on IPv6 ports, so for that combination you will have to manually obtain the latest version.

Split horizon​

If you are running in a split horizon environemt (LAN internal clients connect to a local IP and other clients connect to a public IP) you can specify multiple advertised IPs by separating them with commas:

JVB_ADVERTISE_IPS=192.168.1.1,1.2.3.4

Offline / airgapped installation​

If your setup does not have access to the Internet you'll need to disable STUN on the JVB since discovering its own IP address will fail, but that is not necessary on that type of environment.

JVB_DISABLE_STUN=true

Adjust UDP buffers​

If you are experiencing issues with UDP traffic, like synchronization issues, skipping frames and similar, or if you expect a high traffic and big conferences, you might want to adjust the UDP buffer sizes. You need to do that on the host system, that hosts the jvb container. To do so you can get this sysctl config file and save it in /etc/sysctl.d and load it via: sysctl --system.

Accessing server logs​

The default bahavior of docker-jitsi-meet is to log to stdout.

While the logs are sent to stdout, they are not lost: unless configured to drop all logs, Docker keeps them available for future retrieval and processing.

If you need to access the container's logs you have multiple options. Here are the main ones:

For instance, if you want to have all logs related to a <service_name> written to /var/log/jitsi/<service_name> as json output, you could use docker-file-log-driver and configure it by adding the following block in your docker-compose.yml file, at the same level as the image block of the selected <service_name>:

services:
    <service_name>:
        image: ...
        ...
        logging:
            driver: file-log-driver
            options:
                fpath: "/jitsi/<service_name>.log"

If you want to only display the message part of the log in json format, simply execute the following command (for instance if fpath was set to /jitsi/jvb.log) which uses jq to extract the relevant part of the logs:

sudo cat /var/log/jitsi/jvb.log | jq -r '.msg' | jq -r '.message'

Build Instructions​

Building your images allows you to edit the configuration files of each image individually, providing more customization for your deployment.

The docker images can be built by running the make command in the main repository folder. If you need to overwrite existing images from the remote source, use FORCE_REBUILD=1 make.

If you are on the unstable branch, build the images with FORCE_REBUILD=1 JITSI_RELEASE=unstable make.

You are now able to run docker compose up as usual.

Running behind a reverse proxy​

When running behing a reverse proxy from the same host, the communication between the proxy and Jitsi Meet is often in HTTP and not HTTPS since we generally don't have valid certificates for localhost.

Jitsi Meet does not currently work well when deployed in a subdirectory.

Disable HTTPS​

HTTPS can be disabled in the Docker Compose configuration (since HTTPS will probably not work on localhost):

DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETS_ENCRYPT=0

Do not expose the Jitsi Meet's ports publicly​

By default, the HTTP_PORT and HTTPS_PORT are binding to any ip address, so are publicly open unless a firewall blocks them. When using a reverse proxy, this is not necessary. This can be changed by updating the web container's ports configuration:

            - '127.0.0.1:${HTTP_PORT}:80'
            - '127.0.0.1:${HTTPS_PORT}:443'

instead of

            - '${HTTP_PORT}:80'
            - '${HTTPS_PORT}:443'

Reverse proxy configuration​

By default this setup is using WebSocket connections for 2 core components:

Due to the hop-by-hop nature of WebSockets the reverse proxy must properly terminate and forward WebSocket connections. There 2 routes require such treatment:

The other HTTP requests must be handled by the web container.

In the following configuration examples, http://localhost:8000/ is the url of the web service's ingress (8000 corresponds to HTTP_PORT).

nginx​

With nginx, these routes can be forwarded using the following config snippet:

location /xmpp-websocket {
    proxy_pass http://localhost:8000/xmpp-websocket;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

location /colibri-ws {
    proxy_pass http://localhost:8000/colibri-ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

location / {
    proxy_pass http://localhost:8000/;
    proxy_http_version 1.1;
}

Apache​

With Apache, mod_proxy, mod_proxy_http and mod_proxy_wstunnel need to be enabled.

The reverse proxy can be configured using the following config snippet:

<IfModule mod_proxy.c>
    <IfModule mod_proxy_wstunnel.c>
        ProxyTimeout 900
        ProxyPass /xmpp-websocket ws://localhost:8000/xmpp-websocket
        ProxyPass /colibri-ws/ ws://localhost:8000/colibri-ws/
        ProxyPass / http://localhost:8000/
        ProxyPassReverse / http://localhost:8000/
    </IfModule>
</IfModule>

Disabling WebSocket connections​

This is not the recommended setup.

If using WebSockets is not an option, these environment variables can be set to fallback to HTTP polling and WebRTC datachannels:

ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0

Configurações Jitsi Docker

Jitsi Meet Load Balancing

Link: https://meetrix.io/blog/webrtc/jitsi/jitsi-meet-load-balancing.html

Setup multi server, load balanced videobriges

component_interface = "0.0.0.0"

# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=example.com

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=<XMPP_HOST>

# sets the port of the XMPP server (default: 5275)
JVB_PORT=5347

# sets the shared secret used to authenticate to the XMPP server
JVB_SECRET=<JVB_SECRET>

# extra options to pass to the JVB daemon
JVB_OPTS="--apis=rest,xmpp"


# adds java system props that are passed to jvb (default are for home and logging config file)
JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties"

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=<XMPP_HOST>
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.example.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=<JVB_SECRET>
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.example.com
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=<JVB_NICKNAME>
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

sed -i "s/org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=.*/org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=$(cat /proc/sys/kernel/random/uuid)/g" /etc/jitsi/videobridge/sip-communicator.properties

Load Testing Jitsi Meet

Link: https://meetrix.io/blog/webrtc/jitsi/jitsi-meet-load-testing.html

Make sure your Jitsi Meet infrastructure is ready for production

By deploying a horizontally scalable Jitsi Meet setup, you can scale your Jitsi Meet conferencing infrastructure to cater thousands of concurrent users. But, before you go live you might want to make sure that your infrastructure is capable of handling the desired number of concurrent users. Jitsi Meet Torture is a tool that can be used to run tests against a Jitsi Instance and it is capable of load testing Jitsi Meet.

Selenium Grid

To simulate hundrads of concurrent users, we need to deploy Jitsi Meet Torture agains a selenium grid setup. There would be a selenium hub which accepts commands from Jitsi Meet Torture and pass them to selenium nodes. You can have hundrads of selenium nodes to simulate users.

Overwhelmed with managing
Jitsi Infrastructure?

Outsource full-time, high-cost Jitsi infrastructure management and maintenance

Talk to an expert

Minimal setup with docker-compose

1. Install Docker. You can use following scripts on Ubuntu 18.04

   sudo apt-get update
   
   sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common
   
   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
   
   sudo add-apt-repository -y \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
   
   sudo apt-get -y update
   sudo apt-get -y install docker-ce
   
   sudo usermod -a -G docker $(whoami)
   

2. Install the latest version of Docker Compose

3. Create a docker-compose.yml file with following content.

   version: "3.3"
   services:
     torture:
       image: meetrix/jitsi-meet-torture
     hub:
       image: selenium/hub:3.141.59
     node:
       build: ./node
       image: meetrix/jitsi-meet-torture-selenium-node
       volumes:
         - /dev/shm:/dev/shm
       depends_on:
         - hub
       environment:
         HUB_HOST: hub
   

4. Please note that node are configured to run only one chrome instance at a time. Run the setup with docker-compose up -d --scale node=2 to run two nodes.

5. docker-compose exec torture /bin/bash

6. Change <YOUR_JITSI_MEET_INSTANCE_URL> to your Jitsi Meet installation (for example https://meet.example.com) in following script and run to perform the test.

./scripts/malleus.sh --conferences=1 --participants=2 --senders=2 --audio-senders=2 --duration=300 --room-name-prefix=test --hub-url=http://hub:4444/wd/hub --instance-url=<YOUR_JITSI_MEET_INSTANCE_URL>

Running the test with large number of nodes

You can scale the number of nodes with docker-compose up --scale node=<NUMBER> or you can create a VM using same docker images for selenium hub and selenium-node. Then you can use an autoscaling mechanism (Such as Autoscaling groups on AWS) to scale the number of nodes.

Looking for commercial support for Jitsi Meet ? Please contact us via hello@meetrix.io

Updated: June 19, 2020

Self-Hosting Guide - Log Analyser

Link: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-log-analyser      Last updated on Mar 7, 2025

Welcome to the Jitsi Meet Log Analyser project! This integration leverages Grafana Loki and OpenTelemetry to enable effective log management and analysis for Jitsi Meet components.

Overview​

This project offers a streamlined setup for collecting, parsing, and visualizing log data generated by Jitsi Meet components. The integration includes:

Getting Started​

Prerequisites​

Before you begin, ensure you have the following installed on your system:

Setup​

To set up the project, follow these steps:

Access Grafana​

After starting the services, follow these steps to access Grafana:

Pre-configured Dashboards​

Grafana comes with several pre-configured dashboards specifically designed for monitoring different Jitsi Meet components. These dashboards will be automatically available once you log in to Grafana.

Important❗️: For data to appear in these dashboards, logs need to be generated by the Jitsi Meet components. Here are the available dashboards:

Filtering Logs with LogQL​

Beyond the pre-configured dashboards, you can explore and filter logs in Grafana's "Explore" section using LogQL, a powerful query language designed for Loki. Here’s how you can filter and analyze logs:

Usage​

Once the setup is complete, you can start exploring your log data in Grafana. The pre-configured dashboards provide an insightful visualization of the logs collected from Jitsi Meet components. Use these dashboards to:

Customizing Dashboards​

While the pre-configured dashboards provide a solid starting point, you may want to customize them or create new dashboards to suit your specific needs. Here's how you can do that:

By following these steps, you can not only customize your own monitoring setup but also contribute improvements back to the Jitsi community.

Troubleshooting​

If you encounter issues while setting up or using the Jitsi Meet Log Analyser, here are some common problems and their solutions:

Acknowledgements​

We appreciate your interest in the Jitsi Meet Log Analyser project! If you encounter any issues or have questions, feel free to reach out to the project maintainers or contribute to the repository.

Last updated on Mar 7, 2025