Jitsi Aplicativo de colaboração web conferência Instalação Jitsi Docker Procedimentos de instalação do Jitsi em 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: Tag Description stable Points to the latest stable release stable-NNNN-X A stable release unstable Points to the latest unstable release unstable-YYYY-MM-DD Daily unstable release latest Deprecated, no longer updated (will be removed) 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: 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) Unzip the package: unzip Create a  .env  file by copying and adjusting  env.example : cp env.example .env Set strong passwords in the security section options of  .env  file by running the following bash script ./gen-passwords.sh 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/$_" } Run  docker compose up -d 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 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. Variable Description Example CONFIG Directory where all configuration will be stored /opt/jitsi-meet-cfg TZ System Time Zone Europe/Amsterdam HTTP_PORT Exposed port for HTTP traffic 8000 HTTPS_PORT Exposed port for HTTPS traffic 8443 JVB_ADVERTISE_IPS IP addresses of the Docker host (comma separated), needed for LAN environments 192.168.1.1 PUBLIC_URL Public URL for the web service https://meet.example.com 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: Variable Description Example ENABLE_LETSENCRYPT Enable Let's Encrypt certificate generation 1 LETSENCRYPT_DOMAIN Domain for which to generate the certificate meet.example.com LETSENCRYPT_EMAIL E-Mail for receiving important account notifications (mandatory) alice@atlanta.net 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  .env file, 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) ​ Variable Description Example TOOLBAR_BUTTONS Configure toolbar buttons. Add the buttons name separated with comma(no spaces between comma)   HIDE_PREMEETING_BUTTONS Hide the buttons at pre-join screen. Add the buttons name separated with comma   ENABLE_LOBBY Control whether the lobby feature should be enabled or not 1 ENABLE_AV_MODERATION Control whether the A/V moderation should be enabled or not 1 ENABLE_PREJOIN_PAGE Show a prejoin page before entering a conference 1 ENABLE_WELCOME_PAGE Enable the welcome page 1 ENABLE_CLOSE_PAGE Enable the close page 0 DISABLE_AUDIO_LEVELS Disable measuring of audio levels 0 ENABLE_NOISY_MIC_DETECTION Enable noisy mic detection 1 ENABLE_BREAKOUT_ROOMS Enable breakout rooms 1 Jigasi SIP gateway (audio only) configuration ​ If you want to enable the SIP gateway, these options are required: Variable Description Example JIGASI_SIP_URI SIP URI for incoming / outgoing calls test@sip2sip.info JIGASI_SIP_PASSWORD Password for the specified SIP account JIGASI_SIP_SERVER SIP server (use the SIP account domain if in doubt) sip2sip.info JIGASI_SIP_PORT SIP server port 5060 JIGASI_SIP_TRANSPORT SIP transport UDP Display Dial-In information ​ Variable Description Example DIALIN_NUMBERS_URL URL to the JSON with all Dial-In numbers https://meet.example.com/dialin.json CONFCODE_URL URL to the API for checking/generating Dial-In codes https://jitsi-api.jitsi.net/conferenceMapper 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 are using a release older than 7439 some extra setup is necessary. If you want to enable Jibri these options are required: Variable Description Example ENABLE_RECORDING Enable recording / live streaming 1 Extended Jibri configuration: Variable Description Example JIBRI_RECORDER_USER Internal recorder user for Jibri client connections recorder JIBRI_RECORDER_PASSWORD Internal recorder password for Jibri client connections JIBRI_RECORDING_DIR Directory for recordings inside Jibri container /config/recordings JIBRI_FINALIZE_RECORDING_SCRIPT_PATH The finalizing script. Will run after recording is complete /config/finalize.sh JIBRI_XMPP_USER Internal user for Jibri client connections. jibri JIBRI_STRIP_DOMAIN_JID Prefix domain for strip inside Jibri (please see env.example for details) muc JIBRI_BREWERY_MUC MUC name for the Jibri pool jibribrewery JIBRI_PENDING_TIMEOUT MUC connection timeout 90 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. Variable Description Example ENABLE_AUTH Enable authentication 1 ENABLE_GUESTS Enable guest access 1 AUTH_TYPE Select authentication type (internal, jwt or ldap) internal ENABLE_AUTO_LOGIN Enable auto login 1 JICOFO_AUTH_LIFETIME Select session timeout value for an authenticated user 3 hours 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. Variable Description Example LDAP_URL URL for ldap connection ldaps://ldap.domain.com/ LDAP_BASE LDAP base DN. Can be empty. DC=example,DC=domain,DC=com LDAP_BINDDN LDAP user DN. Do not specify this parameter for the anonymous bind. CN=binduser,OU=users,DC=example,DC=domain,DC=com LDAP_BINDPW LDAP user password. Do not specify this parameter for the anonymous bind. LdapUserPassw0rd LDAP_FILTER LDAP filter. (sAMAccountName=%u) LDAP_AUTH_METHOD LDAP authentication method. bind LDAP_VERSION LDAP protocol version 3 LDAP_USE_TLS Enable LDAP TLS 1 LDAP_TLS_CIPHERS Set TLS ciphers list to allow SECURE256:SECURE128 LDAP_TLS_CHECK_PEER Require and verify LDAP server certificate 1 LDAP_TLS_CACERT_FILE Path to CA cert file. Used when server certificate verification is enabled /etc/ssl/certs/ca-certificates.crt LDAP_TLS_CACERT_DIR Path to CA certs directory. Used when server certificate verification is enabled. /etc/ssl/certs LDAP_START_TLS Enable START_TLS, requires LDAPv3, URL must be ldap:// not ldaps:// 0 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. Variable Description Example JWT_APP_ID Application identifier my_jitsi_app_id JWT_APP_SECRET Application secret known only to your token my_jitsi_app_secret JWT_ACCEPTED_ISSUERS (Optional) Set asap_accepted_issuers as a comma separated list my_web_client,my_app_client JWT_ACCEPTED_AUDIENCES (Optional) Set asap_accepted_audiences as a comma separated list my_server1,my_server2 JWT_ASAP_KEYSERVER (Optional) Set asap_keyserver to a url where public keys can be found https://example.com/asap> JWT_ALLOW_EMPTY (Optional) Allow anonymous users with no JWT while validating JWTs when provided 0 JWT_AUTH_TYPE (Optional) Controls which module is used for processing incoming JWTs token JWT_TOKEN_AUTH_MODULE (Optional) Controls which module is used for validating JWTs token_verification 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 . Variable Description Example MATRIX_UVS_URL Base URL to the matrix user verification service (without ending slash) https://uvs.example.com:3000> MATRIX_UVS_ISSUER (optional) The issuer of the auth token to be passed through. Must match what is being set as  iss  in the JWT. issuer (default) MATRIX_UVS_AUTH_TOKEN (optional) user verification service auth token, if authentication enabled changeme MATRIX_UVS_SYNC_POWER_LEVELS (optional) Make Matrix room moderators owners of the Prosody room. 1 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 . Variable Description Example MATRIX_UVS_URL Base URL to the matrix user verification service (without ending slash) https://uvs.example.com:3000> MATRIX_UVS_ISSUER (optional) The issuer of the auth token to be passed through. Must match what is being set as  iss  in the JWT. It allows all issuers ( * ) by default. my_issuer MATRIX_UVS_AUTH_TOKEN (optional) user verification service auth token, if authentication enabled my_matrix_secret MATRIX_UVS_SYNC_POWER_LEVELS (optional) Make Matrix room moderators owners of the Prosody room. 1 MATRIX_LOBBY_BYPASS (optional) Allow Matrix room members to bypass Jitsi lobby check. 1 JWT_APP_ID Application identifier my_jitsi_app_id JWT_APP_SECRET Application secret known only to your token my_jitsi_app_secret JWT_ALLOW_EMPTY (Optional) Allow anonymous users with no JWT while validating JWTs when provided 0 External authentication ​ Variable Description Example TOKEN_AUTH_URL Authenticate using external service or just focus external auth window if there is one already. https://auth.meet.example.com/{room}> 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: Variable Description Example ETHERPAD_URL_BASE Set etherpad-lite URL http://etherpad.meet.jitsi:9001> Transcription configuration ​ If you want to enable the Transcribing function, these options are required: Variable Description Example ENABLE_TRANSCRIPTIONS Enable Jigasi transcription in a conference 1 GC_PROJECT_ID project_id  from Google Cloud Credentials   GC_PRIVATE_KEY_ID private_key_id  from Google Cloud Credentials   GC_PRIVATE_KEY private_key  from Google Cloud Credentials   GC_CLIENT_EMAIL client_email  from Google Cloud Credentials   GC_CLIENT_ID client_id  from Google Cloud Credentials   GC_CLIENT_CERT_URL client_x509_cert_url  from Google Cloud Credentials   JIGASI_TRANSCRIBER_RECORD_AUDIO Jigasi will record audio when transcriber is on true JIGASI_TRANSCRIBER_SEND_TXT Jigasi will send transcribed text to the chat when transcriber is on true JIGASI_TRANSCRIBER_ADVERTISE_URL Jigasi will post an url to the chat with transcription file true 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 ​ Variable Description Default value JVB_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1> JICOFO_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1> JIGASI_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1> SENTRY_ENVIRONMENT Optional environment info to filter events production SENTRY_RELEASE Optional release info to filter events 1.0.0 TURN server configuration ​ Configure external TURN servers. Variable Description Default value TURN_CREDENTIALS Credentials for TURN servers   TURN_HOST TURN server hostnames as a comma separated list (UDP or TCP transport)   TURN_PORT TURN server port (UDP or TCP transport) 443 TURN_TRANSPORT TURN server protocols as a comma separated list (UDP or TCP or both) tcp TURNS_HOST TURN server hostnames as a comma separated list (TLS transport)   TURNS_PORT TURN server port (TLS transport) 443 Advanced configuration ​ These configuration options are already set and generally don't need to be changed. Variable Description Default value XMPP_DOMAIN Internal XMPP domain meet.jitsi XMPP_AUTH_DOMAIN Internal XMPP domain for authenticated services auth.meet.jitsi XMPP_SERVER Internal XMPP server name xmpp.meet.jitsi xmpp.meet.jitsi XMPP_BOSH_URL_BASE Internal XMPP server URL for BOSH module http://xmpp.meet.jitsi:5280> XMPP_MUC_DOMAIN XMPP domain for the MUC muc.meet.jitsi XMPP_INTERNAL_MUC_DOMAIN XMPP domain for the internal MUC internal-muc.meet.jitsi XMPP_GUEST_DOMAIN XMPP domain for unauthenticated users guest.meet.jitsi XMPP_RECORDER_DOMAIN Domain for the jibri recorder recorder.meet.jitsi XMPP_MODULES Custom Prosody modules for XMPP_DOMAIN (comma separated) info,alert XMPP_MUC_MODULES Custom Prosody modules for MUC component (comma separated) info,alert XMPP_INTERNAL_MUC_MODULES Custom Prosody modules for internal MUC component (comma separated) info,alert GLOBAL_MODULES Custom prosody modules to load in global configuration (comma separated) statistics,alert GLOBAL_CONFIG Custom configuration string with escaped newlines foo = bar;\nkey = val; RESTART_POLICY Container restart policy defaults to  unless-stopped DISABLE_HTTPS Handle TLS connections outside of this setup 0 ENABLE_HTTP_REDIRECT Redirect HTTP traffic to HTTPS 0 LOG_LEVEL Controls which logs are output from prosody and associated modules info ENABLE_HSTS Send a  strict-transport-security  header to force browsers to use a secure and trusted connection. Recommended for production use. 1 ENABLE_IPV6 Provides means to disable IPv6 in environments that don't support it 1 ENABLE_COLIBRI_WEBSOCKET_UNSAFE_REGEX Enabled older unsafe regex for JVB colibri-ws URLs. WARNING: Enable with caution, this regex allows connections to arbitrary internal IP addresses and is not recommended for production use. Unsafe regex is defined as  [a-zA-Z0-9-\._]+ 0 COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME DNS name to look up JVB IP address, used for default value of  COLIBRI_WEBSOCKET_REGEX jvb COLIBRI_WEBSOCKET_REGEX Overrides the colibri regex used for proxying to JVB. Recommended to override in production with values matching possible JVB IP ranges defaults to  dig $COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME  unless  DISABLE_COLIBRI_WEBSOCKET_JVB_LOOKUP  is set to true DISABLE_COLIBRI_WEBSOCKET_JVB_LOOKUP Controls whether to run  dig $COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME  when defining COLIBRI_WEBSOCKET_REGEX 0 Advanced Prosody options ​ Variable Description Default value PROSODY_RESERVATION_ENABLED Enable Prosody's reservation REST API false PROSODY_RESERVATION_REST_BASE_URL Base URL of Prosody's reservation REST API   PROSODY_AUTH_TYPE Select authentication type for Prosody (internal, jwt or ldap) AUTH_TYPE Advanced Jicofo options ​ Variable Description Default value JICOFO_COMPONENT_SECRET XMPP component password for Jicofo s3cr37 JICOFO_AUTH_USER XMPP user for Jicofo client connections focus JICOFO_AUTH_PASSWORD XMPP password for Jicofo client connections JICOFO_ENABLE_AUTH Enable authentication in Jicofo ENABLE_AUTH JICOFO_AUTH_TYPE Select authentication type for Jicofo (internal, jwt or ldap) AUTH_TYPE JICOFO_AUTH_LIFETIME Select session timeout value for an authenticated user 24 hours JICOFO_ENABLE_HEALTH_CHECKS Enable health checks inside Jicofo, allowing the use of the REST api to check Jicofo's status false Advanced JVB options ​ Variable Description Default value JVB_AUTH_USER XMPP user for JVB MUC client connections jvb JVB_AUTH_PASSWORD XMPP password for JVB MUC client connections JVB_STUN_SERVERS STUN servers used to discover the server's public IP stun.l.google.com:19302, stun1.l.google.com:19302, stun2.l.google.com:19302 JVB_PORT UDP port for media used by Jitsi Videobridge 10000 JVB_COLIBRI_PORT COLIBRI REST API port of JVB exposed to localhost 8080 JVB_BREWERY_MUC MUC name for the JVB pool jvbbrewery COLIBRI_REST_ENABLED Enable the COLIBRI REST API true SHUTDOWN_REST_ENABLED Enable the shutdown REST API true Advanced Jigasi options ​ Variable Description Default value JIGASI_ENABLE_SDES_SRTP Enable SDES srtp 0 JIGASI_SIP_KEEP_ALIVE_METHOD Keepalive method OPTIONS JIGASI_HEALTH_CHECK_SIP_URI Health-check extension   JIGASI_HEALTH_CHECK_INTERVAL Health-check interval 300000 JIGASI_XMPP_USER XMPP user for Jigasi MUC client connections jigasi JIGASI_XMPP_PASSWORD XMPP password for Jigasi MUC client connections JIGASI_BREWERY_MUC MUC name for the Jigasi pool jigasibrewery JIGASI_PORT_MIN Minimum port for media used by Jigasi 20000 JIGASI_PORT_MAX Maximum port for media used by Jigasi 20050 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  from command line, where   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   written to  /var/log/jitsi/  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  : services: : image: ... ... logging: driver: file-log-driver options: fpath: "/jitsi/.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: ProxyTimeout 900 ProxyPass "wss://localhost:8443/xmpp-websocket" ProxyPass "wss://localhost:8443/colibri-ws/" ProxyPass "http://localhost:8443/http-bind" 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: 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) Unzip the package: unzip Create a  .env  file by copying and adjusting  env.example : cp env.example .env Set strong passwords in the security section options of  .env  file by running the following bash script ./gen-passwords.sh 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/$_" Run  docker compose up -d Access the web UI at  https://localhost:8443  (or a different port, in case you edited the  .env file).ote 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 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. Variable Description Example CONFIG Directory where all configuration will be stored /opt/jitsi-meet-cfg TZ System Time Zone Europe/Amsterdam HTTP_PORT Exposed port for HTTP traffic 8000 HTTPS_PORT Exposed port for HTTPS traffic 8443 JVB_ADVERTISE_IPS IP addresses of the Docker host (comma separated), needed for LAN environments 192.168.1.1 PUBLIC_URL Public URL for the web service https://meet.example.com 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: Variable Description Example ENABLE_LETSENCRYPT Enable Let's Encrypt certificate generation 1 LETSENCRYPT_DOMAIN Domain for which to generate the certificate meet.example.com LETSENCRYPT_EMAIL E-Mail for receiving important account notifications (mandatory) alice@atlanta.net 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  .env file, 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) ​ Variable Description Example TOOLBAR_BUTTONS Configure toolbar buttons. Add the buttons name separated with comma(no spaces between comma)   HIDE_PREMEETING_BUTTONS Hide the buttons at pre-join screen. Add the buttons name separated with comma   ENABLE_LOBBY Control whether the lobby feature should be enabled or not 1 ENABLE_AV_MODERATION Control whether the A/V moderation should be enabled or not 1 ENABLE_PREJOIN_PAGE Show a prejoin page before entering a conference 1 ENABLE_WELCOME_PAGE Enable the welcome page 1 ENABLE_CLOSE_PAGE Enable the close page 0 DISABLE_AUDIO_LEVELS Disable measuring of audio levels 0 ENABLE_NOISY_MIC_DETECTION Enable noisy mic detection 1 ENABLE_BREAKOUT_ROOMS Enable breakout rooms 1 Jigasi SIP gateway (audio only) configuration ​ If you want to enable the SIP gateway, these options are required: Variable Description Example JIGASI_SIP_URI SIP URI for incoming / outgoing calls test@sip2sip.info JIGASI_SIP_PASSWORD Password for the specified SIP account JIGASI_SIP_SERVER SIP server (use the SIP account domain if in doubt) sip2sip.info JIGASI_SIP_PORT SIP server port 5060 JIGASI_SIP_TRANSPORT SIP transport UDP Display Dial-In information ​ Variable Description Example DIALIN_NUMBERS_URL URL to the JSON with all Dial-In numbers https://meet.example.com/dialin.json CONFCODE_URL URL to the API for checking/generating Dial-In codes https://jitsi-api.jitsi.net/conferenceMapper 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 Note 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: Variable Description Example ENABLE_RECORDING Enable recording / live streaming 1 Extended Jibri configuration: Variable Description Example JIBRI_RECORDER_USER Internal recorder user for Jibri client connections recorder JIBRI_RECORDER_PASSWORD Internal recorder password for Jibri client connections JIBRI_RECORDING_DIR Directory for recordings inside Jibri container /config/recordings JIBRI_FINALIZE_RECORDING_SCRIPT_PATH The finalizing script. Will run after recording is complete /config/finalize.sh JIBRI_XMPP_USER Internal user for Jibri client connections. jibri JIBRI_STRIP_DOMAIN_JID Prefix domain for strip inside Jibri (please see env.example for details) muc JIBRI_BREWERY_MUC MUC name for the Jibri pool jibribrewery JIBRI_PENDING_TIMEOUT MUC connection timeout 90 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. Variable Description Example ENABLE_AUTH Enable authentication 1 ENABLE_GUESTS Enable guest access 1 AUTH_TYPE Select authentication type (internal, jwt or ldap) internal ENABLE_AUTO_LOGIN Enable auto login 1 JICOFO_AUTH_LIFETIME Select session timeout value for an authenticated user 3 hours 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. Variable Description Example LDAP_URL URL for ldap connection ldaps://ldap.domain.com/ LDAP_BASE LDAP base DN. Can be empty. DC=example,DC=domain,DC=com LDAP_BINDDN LDAP user DN. Do not specify this parameter for the anonymous bind. CN=binduser,OU=users,DC=example,DC=domain,DC=com LDAP_BINDPW LDAP user password. Do not specify this parameter for the anonymous bind. LdapUserPassw0rd LDAP_FILTER LDAP filter. (sAMAccountName=%u) LDAP_AUTH_METHOD LDAP authentication method. bind LDAP_VERSION LDAP protocol version 3 LDAP_USE_TLS Enable LDAP TLS 1 LDAP_TLS_CIPHERS Set TLS ciphers list to allow SECURE256:SECURE128 LDAP_TLS_CHECK_PEER Require and verify LDAP server certificate 1 LDAP_TLS_CACERT_FILE Path to CA cert file. Used when server certificate verification is enabled /etc/ssl/certs/ca-certificates.crt LDAP_TLS_CACERT_DIR Path to CA certs directory. Used when server certificate verification is enabled. /etc/ssl/certs LDAP_START_TLS Enable START_TLS, requires LDAPv3, URL must be ldap:// not ldaps:// 0 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. Variable Description Example JWT_APP_ID Application identifier my_jitsi_app_id JWT_APP_SECRET Application secret known only to your token my_jitsi_app_secret JWT_ACCEPTED_ISSUERS (Optional) Set asap_accepted_issuers as a comma separated list my_web_client,my_app_client JWT_ACCEPTED_AUDIENCES (Optional) Set asap_accepted_audiences as a comma separated list my_server1,my_server2 JWT_ASAP_KEYSERVER (Optional) Set asap_keyserver to a url where public keys can be found https://example.com/asap> JWT_ALLOW_EMPTY (Optional) Allow anonymous users with no JWT while validating JWTs when provided 0 JWT_AUTH_TYPE (Optional) Controls which module is used for processing incoming JWTs token JWT_TOKEN_AUTH_MODULE (Optional) Controls which module is used for validating JWTs token_verification 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 . Variable Description Example MATRIX_UVS_URL Base URL to the matrix user verification service (without ending slash) https://uvs.example.com:3000 MATRIX_UVS_ISSUER (optional) The issuer of the auth token to be passed through. Must match what is being set as  iss  in the JWT. issuer (default) MATRIX_UVS_AUTH_TOKEN (optional) user verification service auth token, if authentication enabled changeme MATRIX_UVS_SYNC_POWER_LEVELS (optional) Make Matrix room moderators owners of the Prosody room. 1 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 . Variable Description Example MATRIX_UVS_URL Base URL to the matrix user verification service (without ending slash) https://uvs.example.com:3000 MATRIX_UVS_ISSUER (optional) The issuer of the auth token to be passed through. Must match what is being set as  iss  in the JWT. It allows all issuers ( * ) by default. my_issuer MATRIX_UVS_AUTH_TOKEN (optional) user verification service auth token, if authentication enabled my_matrix_secret MATRIX_UVS_SYNC_POWER_LEVELS (optional) Make Matrix room moderators owners of the Prosody room. 1 MATRIX_LOBBY_BYPASS (optional) Allow Matrix room members to bypass Jitsi lobby check. 1 JWT_APP_ID Application identifier my_jitsi_app_id JWT_APP_SECRET Application secret known only to your token my_jitsi_app_secret JWT_ALLOW_EMPTY (Optional) Allow anonymous users with no JWT while validating JWTs when provided 0 External authentication ​ Variable Description Example TOKEN_AUTH_URL Authenticate using external service or just focus external auth window if there is one already. https://auth.meet.example.com/{room}> 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: Variable Description Example ETHERPAD_URL_BASE Set etherpad-lite URL http://etherpad.meet.jitsi:9001 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. Variable Description Example ENABLE_TRANSCRIPTIONS Enable Jigasi transcription in a conference 1 In addition, the following are options are used to configure the various transcription backends and features: Variable Description Default GC_PROJECT_ID project_id  from Google Cloud Credentials   GC_PRIVATE_KEY_ID private_key_id  from Google Cloud Credentials   GC_PRIVATE_KEY private_key  from Google Cloud Credentials   GC_CLIENT_EMAIL client_email  from Google Cloud Credentials   GC_CLIENT_ID client_id  from Google Cloud Credentials   GC_CLIENT_CERT_URL client_x509_cert_url  from Google Cloud Credentials   JIGASI_TRANSCRIBER_ADVERTISE_URL Jigasi will post an url to the chat with transcription file true JIGASI_TRANSCRIBER_CUSTOM_SERVICE Jigasi will use this class for custom transcriptions instead of google cloud   JIGASI_TRANSCRIBER_CUSTOM_TRANSLATION_SERVICE Jigasi will use this class for custom transctions instead of google cloud   JIGASI_TRANSCRIBER_ENABLE_SAVING Jigasi will save results to a transcription file true JIGASI_TRANSCRIBER_FILTER_SILENCE Jigasi will filter silent audio and not forward to backends   JIGASI_TRANSCRIBER_LIBRETRANSLATE_URL URL for libretranslate services   JIGASI_TRANSCRIBER_OCI_COMPARTMENT OCI compartment for use with Oracle Cloud Speech AI services   JIGASI_TRANSCRIBER_OCI_REGION OCI region name for use with Oracle Cloud Speech AI services   JIGASI_TRANSCRIBER_RECORD_AUDIO Jigasi will record audio when transcriber is on true JIGASI_TRANSCRIBER_REMOTE_CONFIG_URL URL to control transcriber custom service based on conference details   JIGASI_TRANSCRIBER_SEND_TXT Jigasi will send transcribed text to the chat when transcriber is on true JIGASI_TRANSCRIBER_USER Jigasi XMPP user   JIGASI_TRANSCRIBER_VOSK_URL URL for use with vosk backend   JIGASI_TRANSCRIBER_WHISPER_URL URL for use with whisper backend   JIGASI_TRANSCRIBER_WHISPER_PRIVATE_KEY_NAME Private Key ID of the private key to use with whisper   JIGASI_TRANSCRIBER_WHISPER_PRIVATE_KEY Private Key material to use with whisper, without newlines or START/END delimiters   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 ​ Variable Description Default value JVB_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1 JICOFO_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1 JIGASI_SENTRY_DSN Sentry Data Source Name (Endpoint for Sentry project) https://public:private@host:port/1 SENTRY_ENVIRONMENT Optional environment info to filter events production SENTRY_RELEASE Optional release info to filter events 1.0.0 TURN server configuration ​ Configure external TURN servers. Variable Description Default value TURN_CREDENTIALS Credentials for TURN servers   TURN_HOST TURN server hostnames as a comma separated list (UDP or TCP transport)   TURN_PORT TURN server port (UDP or TCP transport) 443 TURN_TRANSPORT TURN server protocols as a comma separated list (UDP or TCP or both) tcp TURNS_HOST TURN server hostnames as a comma separated list (TLS transport)   TURNS_PORT TURN server port (TLS transport) 443 TURN_TLL TURN max allocation duration (sec) 86400 Advanced configuration ​ These configuration options are already set and generally don't need to be changed. Variable Description Default value XMPP_DOMAIN Internal XMPP domain meet.jitsi XMPP_AUTH_DOMAIN Internal XMPP domain for authenticated services auth.meet.jitsi XMPP_SERVER Internal XMPP server name xmpp.meet.jitsi xmpp.meet.jitsi XMPP_BOSH_URL_BASE Internal XMPP server URL for BOSH module http://xmpp.meet.jitsi:5280 XMPP_MUC_DOMAIN XMPP domain for the MUC muc.meet.jitsi XMPP_INTERNAL_MUC_DOMAIN XMPP domain for the internal MUC internal-muc.meet.jitsi XMPP_GUEST_DOMAIN XMPP domain for unauthenticated users guest.meet.jitsi XMPP_RECORDER_DOMAIN Domain for the jibri recorder recorder.meet.jitsi XMPP_MODULES Custom Prosody modules for XMPP_DOMAIN (comma separated) info,alert XMPP_MUC_MODULES Custom Prosody modules for MUC component (comma separated) info,alert XMPP_INTERNAL_MUC_MODULES Custom Prosody modules for internal MUC component (comma separated) info,alert GLOBAL_MODULES Custom prosody modules to load in global configuration (comma separated) statistics,alert GLOBAL_CONFIG Custom configuration string with escaped newlines foo = bar;\nkey = val; RESTART_POLICY Container restart policy defaults to  unless-stopped DISABLE_HTTPS Handle TLS connections outside of this setup 0 ENABLE_HTTP_REDIRECT Redirect HTTP traffic to HTTPS 0 LOG_LEVEL Controls which logs are output from prosody and associated modules info ENABLE_HSTS Send a  strict-transport-security  header to force browsers to use a secure and trusted connection. Recommended for production use. 1 ENABLE_IPV6 Provides means to disable IPv6 in environments that don't support it 1 ENABLE_COLIBRI_WEBSOCKET_UNSAFE_REGEX Enabled older unsafe regex for JVB colibri-ws URLs. WARNING: Enable with caution, this regex allows connections to arbitrary internal IP addresses and is not recommended for production use. Unsafe regex is defined as  [a-zA-Z0-9-\._]+ 0 COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME DNS name to look up JVB IP address, used for default value of  COLIBRI_WEBSOCKET_REGEX jvb COLIBRI_WEBSOCKET_REGEX Overrides the colibri regex used for proxying to JVB. Recommended to override in production with values matching possible JVB IP ranges defaults to  dig $COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME  unless  DISABLE_COLIBRI_WEBSOCKET_JVB_LOOKUP  is set to true DISABLE_COLIBRI_WEBSOCKET_JVB_LOOKUP Controls whether to run  dig $COLIBRI_WEBSOCKET_JVB_LOOKUP_NAME  when defining COLIBRI_WEBSOCKET_REGEX 0 Advanced Prosody options ​ Variable Description Default value PROSODY_RESERVATION_ENABLED Enable Prosody's reservation REST API false PROSODY_RESERVATION_REST_BASE_URL Base URL of Prosody's reservation REST API   PROSODY_AUTH_TYPE Select authentication type for Prosody (internal, jwt or ldap) AUTH_TYPE PROSODY_ENABLE_METRICS Enables the http_openmetrics module which exposes Prometheus metrics at  /metrics false PROSODY_METRICS_ALLOWED_CIDR CIDR block permitted to access metrics 172.16.0.0/12 Advanced Jicofo options ​ Variable Description Default value JICOFO_COMPONENT_SECRET XMPP component password for Jicofo s3cr37 JICOFO_AUTH_USER XMPP user for Jicofo client connections focus JICOFO_AUTH_PASSWORD XMPP password for Jicofo client connections JICOFO_ENABLE_AUTH Enable authentication in Jicofo ENABLE_AUTH JICOFO_AUTH_TYPE Select authentication type for Jicofo (internal, jwt or ldap) AUTH_TYPE JICOFO_AUTH_LIFETIME Select session timeout value for an authenticated user 24 hours JICOFO_ENABLE_HEALTH_CHECKS Enable health checks inside Jicofo, allowing the use of the REST api to check Jicofo's status false Advanced JVB options ​ Variable Description Default value JVB_AUTH_USER XMPP user for JVB MUC client connections jvb JVB_AUTH_PASSWORD XMPP password for JVB MUC client connections JVB_STUN_SERVERS STUN servers used to discover the server's public IP stun.l.google.com:19302, stun1.l.google.com:19302, stun2.l.google.com:19302 JVB_PORT UDP port for media used by Jitsi Videobridge 10000 JVB_COLIBRI_PORT COLIBRI REST API port of JVB exposed to localhost 8080 JVB_BREWERY_MUC MUC name for the JVB pool jvbbrewery COLIBRI_REST_ENABLED Enable the COLIBRI REST API true SHUTDOWN_REST_ENABLED Enable the shutdown REST API true Advanced Jigasi options ​ Variable Description Default value JIGASI_ENABLE_SDES_SRTP Enable SDES srtp 0 JIGASI_SIP_KEEP_ALIVE_METHOD Keepalive method OPTIONS JIGASI_HEALTH_CHECK_SIP_URI Health-check extension   JIGASI_HEALTH_CHECK_INTERVAL Health-check interval 300000 JIGASI_XMPP_USER XMPP user for Jigasi MUC client connections jigasi JIGASI_XMPP_PASSWORD XMPP password for Jigasi MUC client connections JIGASI_BREWERY_MUC MUC name for the Jigasi pool jigasibrewery JIGASI_PORT_MIN Minimum port for media used by Jigasi 20000 JIGASI_PORT_MAX Maximum port for media used by Jigasi 20050 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. 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 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: run  docker compose logs -t -f  from command line, where   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   written to  /var/log/jitsi/  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  : services: : image: ... ... logging: driver: file-log-driver options: fpath: "/jitsi/.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 . Note 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: 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 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: 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/ 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 Last updated on  Mar 7, 2025 Configurações Jitsi Docker Procedimentos de configurações e customizações. Jitsi Meet Load Balancing Link: https://meetrix.io/blog/webrtc/jitsi/jitsi-meet-load-balancing.html Setup multi server, load balanced videobriges One of the amazing features in Jitsi Meet is the inbuilt horizontal scalability. When you want to cater large number of concurrent users, you can spin up multiple video bridges to handle the load. If we setup mulple video bridges and connect them to the same shard, Jicofo, the conference manager selects the least loaded Videobridge for the next new conference. Run Prosody on all interfaces By default prosody runs only on local interface (127.0.0.0), to allow the xmpp connections from external servers, we have to run prosody on all interfaces. To do that, add the following line at the beginning of  /etc/prosody/prosody.cfg.lua component_interface = "0.0.0.0" Allow inbound traffic for port 5222 Open inbound traffic from JVB server on port  5222  (TCP) of Prosody server. But DO NOT open this publicly. Install JVB on a seperate server Install a Jitsi Video Bridge on a different server. Copy JVB configurations from Jitsi Meet server Replace  /etc/jitsi/videbridge/config  and  /etc/jitsi/video-bridge/sip-communicator.properties  of JVB server with the same files from the original Jitsi Meet server Update JVB config file In  /etc/jitsi/videbridge/config  set the  XMPP_HOST  to the ip address/domain of the prosody server # 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= # 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= # 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" In  /etc/jitsi/video-bridge/sip-communicator.properties  file update the following properties : The ip address of the prosody server. Better if you can use the private IP address if that can be accessed from JVB server. : This should be a unique string used by Jicofo to identify each JVB 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= 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= org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.example.com org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME= org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true You can add the following line at the beginning of  /usr/share/jitsi/jvb/jvb.sh  to generate a unique nickname for the JVB at each startup. This might be useful if you are using an auto-scaling mechanism. 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 Looking for commercial support for Jitsi Meet ?  Please contact us via  hello@meetrix.io Updated:   October 19, 2020 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. Jitsi Meet Load Testing with Torture 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. Jitsi Meet Load Testing with Torture Overwhelmed with managing Jitsi Infrastructure? Outsource full-time, high-cost Jitsi infrastructure management and maintenance Talk to an expert Minimal setup with docker-compose 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) Install the latest version of  Docker Compose 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 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. docker-compose exec torture /bin/bash Change   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= Running the test with large number of nodes You can scale the number of nodes with  docker-compose up --scale node=  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: A Docker Compose setup file ( log-analyser.yml ) for configuring Loki and OpenTelemetry Collector. A Docker Compose setup file ( grafana.yml ) for configuring Grafana. A unified Docker Compose command that initiates all services concurrently. Instructions on configuring Grafana with Loki as a log data source for enhanced visualization and analysis. Getting Started ​ Prerequisites ​ Before you begin, ensure you have the following installed on your system: Docker Docker Compose Setup ​ To set up the project, follow these steps: Clone the repository: Clone the Jitsi Meet repository that contains the necessary Docker Compose files. git clone https://github.com/jitsi/docker-jitsi-meet.git cd docker-jitsi-meet Update Jitsi Meet Docker Compose Configuration: To enable log collection and analysis, you need to modify the  docker-compose.yml  file for Jitsi Meet components. Add the following configuration to each Jitsi service within the  docker-compose.yml  file: logging: driver: "json-file" options: labels: "service" This configuration ensures that logs are collected in JSON format and tagged with service labels, which is essential for Loki to properly ingest and index the logs. Start the Docker containers: Use the following command to start all required services, including the Jitsi Meet components, Grafana, Loki, and OpenTelemetry: docker-compose -f docker-compose.yml -f log-analyser.yml -f grafana.yml up -d Explanation: The command combines multiple Docker Compose files to launch the entire stack: docker-compose.yml  launches the Jitsi Meet components. log-analyser.yml  sets up the log analysis tools, including Loki and OpenTelemetry. grafana.yml  initializes Grafana for log visualization. Logs generated by the Jitsi Meet components are automatically forwarded to Loki via the OpenTelemetry Collector, making them available for analysis in Grafana. Note:  If you only want to use Grafana for log visualization without the log analysis tools, you can run  grafana.yml  independently. However, for the complete log analysis setup, both  log-analyser.yml  and  grafana.yml  are required. Access Grafana ​ After starting the services, follow these steps to access Grafana: Open Grafana in your web browser: Navigate to  http://localhost:3000  to access the Grafana interface. Log in to Grafana: Use the default login credentials provided below: Username:   admin Password:   admin (It is recommended to change these credentials after the first login for security purposes.) 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: Jicofo Dashboard:  Visualizes logs related to Jitsi Conference Focus (Jicofo), which handles media and signaling in Jitsi Meet. JVB Dashboard:  Focuses on Jitsi Videobridge (JVB) logs, showing details on video streaming and performance metrics. Prosody Dashboard:  Monitors Prosody, the XMPP server used by Jitsi Meet for signaling. Web Dashboard:  Displays logs and metrics related to the web frontend of Jitsi Meet. Jitsi All Dashboard:  A comprehensive dashboard that aggregates logs from all Jitsi Meet components. 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: Access the Explore section: In Grafana, navigate to the  Explore  tab from the left sidebar. This section allows you to run queries on your logs in real-time. Select the Loki Data Source: In the Explore section, ensure that the  Data Source  is set to  Loki . This is essential because Loki is the backend that stores and manages the log data collected from Jitsi Meet components. Using LogQL for Filtering: LogQL enables you to create complex queries to filter specific logs. For example, the following LogQL query filters logs for the  jitsi-jicofo  component and parses them: {exporter="OTLP"} | json | attributes_attrs_service="jitsi-jicofo" Explanation: {exporter="OTLP"} : Selects logs that are exported via OpenTelemetry. | json : Parses the log data as JSON, making attributes accessible for filtering. attributes_attrs_service="jitsi-jicofo" : Filters logs where the  attributes_attrs_service  field equals  "jitsi-jicofo" . You can modify the query to filter logs from other components or adjust the criteria according to your needs. For more details and advanced usage of LogQL, you can refer to the official  LogQL documentation  from Grafana. 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: Parse Logs:  View detailed logs collected from various components. Visualize Logs:  Analyze log data through various charts, graphs, and panels to gain insights into system performance and issues. 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: Create a New Dashboard: Go to the Grafana home page, click on the "+" icon on the left sidebar, and select "Dashboard." Add panels to visualize different metrics or logs by selecting the appropriate data source (Loki) and using LogQL queries. Customize Existing Dashboards: Navigate to an existing dashboard and click on the "Edit" button (pencil icon) on any panel. Adjust the LogQL query, visualization type, and panel settings to match your requirements. Save and Share Dashboards: After customizing, save the dashboard. You can also export it as a JSON file to share with others or for backup. To export the dashboard: Click on the dashboard title to open the options menu. Select  "Dashboard settings"  >  "JSON Model" . Click  "Download JSON"  to save the file locally. Contribute to Jitsi Meet Dashboards: If you've created or customized a dashboard that could benefit the wider Jitsi community, you can contribute by updating the relevant dashboard JSON file. Here’s how to do it: Export the JSON file of your customized dashboard as described above. Locate the corresponding Jitsi component dashboard JSON file in the repository (e.g.,  jicofo-dashboard.json ,  jvb-dashboard.json ). Update the existing JSON file with your changes. Submit a pull request to the repository with the updated JSON file and a brief description of the changes you made. This helps improve the pre-configured dashboards and makes your contributions available to all users. Grafana Provisioning: The Jitsi Meet Log Analyser uses Grafana provisioning to manage dashboards. When you update a dashboard JSON file in the repository, it will be automatically provisioned in Grafana when the stack is deployed. This ensures that everyone using the repository gets the latest version of the dashboards without needing to manually import them. 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: Grafana Not Starting: Check if the Grafana container is running with  docker ps  and inspect logs using  docker logs grafana  for any errors. No Logs in Grafana Dashboards: Ensure that Jitsi Meet components are generating logs. Clear browser cache, reload Grafana. Ensure OpenTelemetry, Loki, and Grafana containers are all running with  docker ps , and inspect each container's logs for issues using  docker logs . OpenTelemetry Collector Not Forwarding Logs: Check OpenTelemetry's logs with  docker logs otel , ensure it's connected to the correct endpoints, and verify the log format is correct. Authentication Failures in Grafana: Restart Grafana with  docker restart grafana otel . If still unsuccessful, delete the data volume with  docker-compose down -v  and restart to reset to default credentials (admin/admin). Slow Queries: If LogQL queries are slow, try optimizing the query in Grafana. Permission Issues: If you encounter permission issues, make sure that Docker has the necessary access rights to the directories where logs are stored. Docker Network Issues: Verify Docker network connections, IP range, and restart the network if necessary. OpenTelemetry Collector Not Forwarding Logs: Check OpenTelemetry logs, verify configuration, and ensure log format compatibility. Docker Containers Failing to Start: Use  docker-compose logs  to view detailed startup errors, and check for common issues like incorrect configurations. 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