Héberger Jitsi Meet soi-même pour les appels vidéo

Zoom et Google Meet plafonnent tous les deux les appels gratuits par durée ou nombre de participants, et les paliers payants facturent par hôte, par mois, que vous les utilisiez ce mois-là ou non. Jitsi Meet est une visioconférence à code source ouvert qui fait le même travail de base (appels dans le navigateur avec partage d’écran, sans installation) comme logiciel auto-hébergé : quatre conteneurs, un domaine, et aucune facture par minute ou par siège une fois que ça tourne. Ce guide le met en place à partir d’un serveur vide avec les images officielles, Caddy gérant le HTTPS devant, et explique l’élément unique (un seul port UDP) qui détermine si les appels se connectent vraiment une fois que plus d’une personne se trouve sur un réseau différent.

À la fin, vous aurez une instance Jitsi Meet fonctionnelle sur votre propre domaine, vous comprendrez pourquoi ce port UDP compte, et vous connaîtrez l’état honnête du raccourci en un clic de Railyard pour cette application en particulier.

Ce qu’il vous faut

• Un serveur avec une vraie marge de manœuvre. Un appel de test entre deux personnes sur un réseau local tient sur un Hetzner CX23 (2 vCPU, 4 Go de RAM, 5,99 € par mois avant taxes), mais des réunions d’équipe soutenues veulent plus : un CX33 (4 vCPU, 8 Go de RAM, 8,99 € par mois) est une base plus sûre une fois que plusieurs personnes en dépendent réellement au quotidien.
• Un domaine avec un enregistrement DNS A pointé vers le serveur (ce guide utilise meet.example.com).
• L’adresse IPv4 publique du serveur, connue à l’avance, pas seulement assignée (vous en aurez besoin pour la traversée NAT à l’étape 3).
• Un accès SSH et environ 20 minutes.

Étape 1 : provisionner le serveur et installer Docker

Créez le serveur sous Ubuntu 24.04, pointez le DNS vers lui, et installez Docker :

ssh root@203.0.113.30
apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

docker --version
docker compose version

Étape 2 : obtenir les répertoires de configuration officiels

La documentation de Jitsi dirige vers le téléchargement d’une version étiquetée plutôt que de cloner le dépôt directement, puisque le fichier compose sur la branche par défaut peut être en avance sur ce que les images publiées supportent réellement. Ce guide utilise la version actuelle, stable-11248-1 :

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

Ces répertoires contiennent la configuration générée par Jitsi lui-même et persistent entre les mises à jour ; les perdre signifie régénérer les mots de passe et toute personnalisation.

Étape 3 : écrire le fichier d’environnement

CONFIG=~/.jitsi-meet-cfg
HTTP_PORT=8000
HTTPS_PORT=8443
JVB_PORT=10000
PUBLIC_URL=https://meet.example.com
DISABLE_HTTPS=1
ENABLE_LETSENCRYPT=0
ENABLE_HTTP_REDIRECT=0
XMPP_DOMAIN=meet.jitsi
XMPP_AUTH_DOMAIN=auth.meet.jitsi
XMPP_MUC_DOMAIN=muc.meet.jitsi
XMPP_INTERNAL_MUC_DOMAIN=internal-muc.meet.jitsi
XMPP_GUEST_DOMAIN=guest.meet.jitsi
XMPP_SERVER=xmpp.meet.jitsi
JICOFO_COMPONENT_SECRET=
JICOFO_AUTH_PASSWORD=
JVB_AUTH_PASSWORD=
JVB_ADVERTISE_IPS=203.0.113.30
ENABLE_GUESTS=1
TZ=Etc/UTC

Générez les trois secrets vides avec :

for v in JICOFO_COMPONENT_SECRET JICOFO_AUTH_PASSWORD JVB_AUTH_PASSWORD; do
  echo "$v=$(openssl rand -hex 16)"
done

Collez chaque valeur dans .env à la place du vide. DISABLE_HTTPS=1 et ENABLE_LETSENCRYPT=0 comptent particulièrement ici parce que c’est Caddy qui gère le HTTPS, pas l’option intégrée du conteneur web, qui se disputerait autrement le port 443 avec Caddy. JVB_ADVERTISE_IPS est le réglage que la plupart des guides d’auto-hébergement Jitsi enterrent : c’est l’IP publique du serveur, communiquée explicitement à la vidéobridge pour qu’elle puisse annoncer une adresse joignable aux participants derrière un NAT plutôt que seulement son adresse de réseau Docker privée.

Étape 4 : écrire le fichier Docker Compose

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config
    depends_on:
      - web

  web:
    image: ghcr.io/jitsi/web:stable-11248-1
    restart: unless-stopped
    volumes:
      - ${CONFIG}/web:/config
      - ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts
    env_file:
      - .env
    depends_on:
      - jvb

  prosody:
    image: ghcr.io/jitsi/prosody:stable-11248-1
    restart: unless-stopped
    expose:
      - "5222"
      - "5269"
      - "5347"
      - "5280"
    volumes:
      - ${CONFIG}/prosody/config:/config
      - ${CONFIG}/prosody/prosody-plugins-custom:/prosody-plugins-custom
    env_file:
      - .env

  jicofo:
    image: ghcr.io/jitsi/jicofo:stable-11248-1
    restart: unless-stopped
    volumes:
      - ${CONFIG}/jicofo:/config
    env_file:
      - .env
    depends_on:
      - prosody

  jvb:
    image: ghcr.io/jitsi/jvb:stable-11248-1
    restart: unless-stopped
    ports:
      - "${JVB_PORT:-10000}:${JVB_PORT:-10000}/udp"
    volumes:
      - ${CONFIG}/jvb:/config
    env_file:
      - .env
    depends_on:
      - prosody

volumes:
  caddy-data:
  caddy-config:

Le service jvb est celui avec un vrai port d’hôte publié directement, 10000/udp, plutôt que caché derrière Caddy. Ce n’est pas une simplification ; le HTTPS peut passer par un proxy, mais le flux audio et vidéo réel ne le peut pas, puisque WebRTC a besoin d’un chemin UDP direct. Validez avant de démarrer :

docker compose config

Étape 5 : écrire le Caddyfile

meet.example.com {
    reverse_proxy web:8000
}

Étape 6 : démarrer et ouvrir le pare-feu

docker compose up -d
docker compose ps

Vous devriez voir les cinq services (caddy, web, prosody, jicofo, jvb) comme running. Ouvrez le port UDP explicitement si le serveur a un pare-feu actif :

ufw allow 10000/udp
ufw allow 80/tcp
ufw allow 443/tcp

Visitez https://meet.example.com ; vous devriez voir la page d’accueil de Jitsi Meet avec un certificat valide. Démarrez une réunion et rejoignez-la depuis deux réseaux différents, pas deux onglets sur la même machine, puisque tester sur le même réseau ne révélera pas un problème de NAT ou de pare-feu sur le port UDP.

Le raccourci : faites-le avec Railyard, honnêtement

Railyard a un gabarit de pile Jitsi Meet qui provisionne les quatre conteneurs applicatifs (web, prosody, jicofo, jvb) ensemble : choisissez Jitsi Meet dans le catalogue de gabarits. Ça vaut la peine d’être direct sur où ça en est aujourd’hui : le manifeste de déploiement de Railyard n’a pas encore de façon de publier un port UDP ou d’annoncer l’IP publique d’un serveur à un conteneur, comme le fait JVB_ADVERTISE_IPS et le mappage de port UDP de l’hôte à l’étape 4. Les conteneurs démarrent et l’interface web se charge, mais les appels entre participants sur des réseaux différents n’auront pas de chemin média fonctionnel tant que ça n’est pas résolu. Si vous avez besoin que Jitsi Meet gère réellement des appels aujourd’hui, les étapes 1 à 6 ci-dessus sont le vrai chemin ; le gabarit Railyard est suivi comme une lacune connue plutôt que dissimulé.

Dépannage

La page se charge mais les appels ne se connectent jamais entre deux réseaux différents. C’est presque toujours JVB_ADVERTISE_IPS non défini, ou défini à l’adresse privée du serveur plutôt qu’à sa publique, combiné au port UDP pas réellement ouvert sur le pare-feu. Confirmez les deux ; un appel entre deux onglets de navigateur sur la même machine fonctionnera même avec ça brisé, c’est pourquoi ce n’est pas un test valide.

Le HTTPS ne se charge pas, ou Caddy journalise un conflit de port. Vérifiez que DISABLE_HTTPS=1 et ENABLE_LETSENCRYPT=0 sont bien définis dans .env ; sans eux, le nginx intégré du conteneur web essaie aussi de lier le port 443.

Un participant a l’audio mais pas la vidéo, ou l’inverse. Habituellement un réseau restrictif du côté de ce participant (pare-feu d’entreprise, wifi d’hôtel) plutôt que le serveur ; demandez-leur d’essayer depuis un autre réseau avant de supposer que le serveur est mal configuré.

Manque de mémoire avec plus d’une poignée de participants. La vidéobridge de Jitsi route le média pour chaque participant, et c’est un vrai travail de CPU et de mémoire qui grandit avec le nombre de personnes, pas un coût fixe. docker stats jvb pendant qu’un appel tourne montre si c’est la contrainte ; un CX33 ou plus a plus de marge qu’un CX23.

Les changements dans .env ne prennent pas effet. La plupart des variables d’environnement de Jitsi ne sont lues qu’une fois, au démarrage d’un conteneur ; docker compose up -d après un changement de .env ne recrée pas toujours un conteneur déjà en marche sans changement. Forcez-le avec docker compose up -d --force-recreate.

FAQ

Puis-je enregistrer les réunions ? Oui, via Jibri, un composant d’enregistrement séparé que ce guide ne configure pas ; il a besoin de son propre conteneur et de plus de ressources serveur, et vaut la peine d’être ajouté seulement une fois la configuration de base ci-dessus confirmée fonctionnelle.

Combien de personnes un serveur peut-il gérer ? Ça dépend plus de la qualité vidéo et de la taille du serveur que d’un nombre fixe ; un CX33 gère confortablement les réunions régulières d’une petite équipe, et le CPU du conteneur jvb est ce qu’il faut surveiller à mesure que le nombre de participants augmente.

Ai-je besoin de TURN pour que ça fonctionne ? La plupart du temps, non, puisque JVB_ADVERTISE_IPS plus un port UDP ouvert couvre le cas commun. Un serveur TURN aide spécifiquement quand un participant est derrière un pare-feu qui bloque entièrement l’UDP direct, ce qui représente une tranche plus petite des réseaux réels qu’avant.

Jitsi Meet est-il vraiment gratuit à faire tourner ? Le logiciel l’est ; le serveur et sa bande passante sont le vrai coût, et les appels vidéo utilisent considérablement plus de bande passante qu’une application web typique, ce qui vaut la peine d’être pris en compte si un fournisseur mesure de près le trafic sortant.

Comment est l’expérience mobile ? Jitsi a des applications natives iOS et Android qui fonctionnent avec n’importe quel serveur auto-hébergé ; pointez-les vers https://meet.example.com comme la version navigateur.

Puis-je faire tourner ça derrière un routeur NAT à la maison plutôt qu’un serveur infonuagique ? Oui, avec une étape de plus : redirigez à la fois le port UDP média et le TCP 443 du routeur vers la machine qui fait tourner Docker, et réglez JVB_ADVERTISE_IPS à l’IP publique du routeur lui-même plutôt qu’à l’adresse locale de la machine, puisque c’est ce que la vidéobridge doit communiquer aux participants distants.

Jitsi Meet est l’une des histoires d’auto-hébergement les plus honnêtes ici précisément parce que la seule chose qui compte vraiment, qu’un appel se connecte entre deux réseaux, se résume à un port UDP et une adresse IP bien réglés, pas un mystère. Réglez ces deux choses correctement et le reste tient en quatre conteneurs et un proxy inverse, faisant tourner des appels sans que personne ne compte les minutes.