Videokonferenzen über Zoom oder Microsoft Teams sind bequem – aber die Daten fließen durch fremde Rechenzentren, oft außerhalb der EU. Wer für KMU, Behörden oder Schulen eine DSGVO-konforme Alternative sucht, findet in Jitsi Meet ein vollständig quelloffenes Videokonferenzsystem (Apache 2.0, 29.000+ GitHub-Stars), das per Docker Compose auf einem beliebigen Linux-Server läuft. Teilnehmer treten einem Meeting einfach per URL im Browser bei – keine App-Installation, kein Konto, keine monatlichen Gebühren. Alle Audio-, Video- und Chat-Daten bleiben ausschließlich auf deinem eigenen Server.

Voraussetzungen

Linux-Server oder VM (Ubuntu 22.04/24.04 empfohlen) mit mindestens 2 CPU-Kernen und 4 GB RAM für bis zu 20 Teilnehmer
Docker Engine >= 20.10 und Docker Compose Plugin v2 (Befehl: docker compose ohne Bindestrich) – siehe Docker und Docker Compose auf Linux installieren
Öffentliche IP-Adresse (statisch empfohlen) und ein Domainname mit DNS-A-Record auf den Server – Pflicht für Let's Encrypt und mobile Apps
Firewall-Freigaben: Port 80/tcp, 443/tcp und 10000/udp müssen zum Server durchgeleitet werden
Root- oder sudo-Zugriff auf den Host sowie Internetzugang für Image-Download und ACME-Challenge

Schritt 1: Projektverzeichnis und Konfigurationsordner anlegen

Lege zunächst das Projektverzeichnis an und lade das offizielle Release-Archiv von GitHub herunter. Das Archiv enthält compose.yaml, env.example und das Passwort-Skript gen-passwords.sh.

sudo mkdir -p /opt/jitsi-meet
cd /opt/jitsi-meet

# Aktuelles Stable-Release herunterladen (Stand: stable-11031)
wget -q https://github.com/jitsi/docker-jitsi-meet/archive/refs/tags/stable-11031.tar.gz
tar xzf stable-11031.tar.gz --strip-components=1
rm stable-11031.tar.gz

Jitsi schreibt beim ersten Start Konfigurationsdateien in ein Verzeichnis, das vorher manuell existieren muss. Fehlt die Struktur, crasht der web-Container sofort.

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

Verifizieren: Prüfe, ob alle Verzeichnisse angelegt wurden:

ls ~/.jitsi-meet-cfg/
# Erwartete Ausgabe: jicofo  jvb  prosody  transcripts  web

Schritt 2: .env-Datei anlegen und Passwörter generieren

Kopiere die Beispiel-Konfiguration und passe die wichtigsten Werte an. Anschließend generiert gen-passwords.sh kryptografisch sichere Passwörter für die internen XMPP-Verbindungen und schreibt sie direkt in die .env. Dieser Schritt ist kein optionaler Komfort, sondern Pflicht – leere Passwörter führen zu Startfehlern oder unsicheren Verbindungen.

cp env.example .env

Öffne .env mit einem Editor und passe mindestens diese Werte an:

# Öffentliche URL – MUSS korrekt gesetzt sein, sonst funktionieren mobile Apps nicht
PUBLIC_URL=https://meet.example.com

# HTTP/HTTPS-Ports (Defaults 8000/8443 – bei Let's Encrypt auf 80/443 ändern)
HTTP_PORT=80
HTTPS_PORT=443

# Zeitzone
TZ=Europe/Berlin

# Image-Tag – NICHT "latest" verwenden (deprecated), stable oder versioniert
JITSI_IMAGE_VERSION=stable

# Restart-Policy
RESTART_POLICY=unless-stopped

# Konfigurationsverzeichnis
CONFIG=~/.jitsi-meet-cfg

# Öffentliche IP des Docker-Hosts – PFLICHT bei NAT/Router!
JVB_ADVERTISE_IPS=1.2.3.4

# Let's Encrypt aktivieren
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com

# Passwörter – werden gleich von gen-passwords.sh gefüllt
JICOFO_AUTH_PASSWORD=
JVB_AUTH_PASSWORD=

Jetzt Passwörter generieren:

chmod +x gen-passwords.sh
./gen-passwords.sh

Das Skript ruft intern openssl rand -hex 16 auf, setzt die Passwörter in der .env und legt ein Backup unter .env.bak an.

Verifizieren: Kontrolliere, dass die Passwörter nicht mehr leer sind:

grep -E "JICOFO_AUTH_PASSWORD|JVB_AUTH_PASSWORD" .env
# Erwartet: beide Werte mit zufälligem Hex-String gefüllt, z. B.:
# JICOFO_AUTH_PASSWORD=a3f7c9d2e1b04f8a...

Schritt 3: compose.yaml prüfen

Die mitgelieferte compose.yaml enthält alle vier Pflicht-Services. Hier die relevanten Eckdaten auf einen Blick:

Service	Image	Funktion	Port
web	jitsi/web:stable	Nginx + Meet-UI (Frontend)	80/tcp, 443/tcp
prosody	jitsi/prosody:stable	XMPP-Server (intern)	–
jicofo	jitsi/jicofo:stable	Konferenz-Koordinator (Focus)	–
jvb	jitsi/jvb:stable	Videobridge, Medien-Router	10000/udp

Umgebungsvariable	Zweck	Pflicht?
PUBLIC_URL	Öffentliche URL des Servers	Ja (Produktion)
JVB_ADVERTISE_IPS	Öffentliche IP bei NAT	Ja (bei NAT)
JICOFO_AUTH_PASSWORD	XMPP-Auth für Jicofo	Ja
JVB_AUTH_PASSWORD	XMPP-Auth für Videobridge	Ja
ENABLE_LETSENCRYPT	Let's-Encrypt-Integration	Empfohlen
DISABLE_HTTPS	Hinter externem Reverse Proxy	Situativ

Die compose.yaml liest alle Werte aus der .env und verwendet das interne Docker-Netzwerk meet.jitsi. Prosody ist nach außen nicht erreichbar und kommuniziert ausschließlich mit den anderen Containern im internen Bridge-Netzwerk – sicheres Default-Design. Für den Einstieg reicht die mitgelieferte Datei unverändert. Bei Bedarf an Docker Compose Grundlagen findest du eine ausführliche Erklärung in der Anleitung Docker Compose: Multi-Container-Stacks aufbauen.

Verifizieren: Prüfe, ob die Syntax der compose.yaml valide ist:

docker compose config --quiet && echo "OK"
# Erwartete Ausgabe: OK

Schritt 4: Stack starten

Starte alle vier Container im Hintergrund. Docker lädt die Images beim ersten Start herunter – je nach Verbindung kann das einige Minuten dauern.

docker compose up -d

Beobachte anschließend den Start-Prozess:

docker compose logs -f

Warte, bis keine neuen Zeilen mehr erscheinen und breche mit Ctrl+C ab.

Verifizieren: Alle vier Container müssen den Status Up haben:

docker compose ps
# Erwartete Ausgabe (gekürzt):
# NAME                   STATUS          PORTS
# jitsi-meet-web-1       Up              0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp
# jitsi-meet-prosody-1   Up
# jitsi-meet-jicofo-1    Up
# jitsi-meet-jvb-1       Up              0.0.0.0:10000->10000/udp

Prüfe zusätzlich, ob der web-Container antwortet:

curl -I http://localhost:80
# Erwartet: HTTP/1.1 301 Moved Permanently (Weiterleitung auf HTTPS)

Schritt 5: HTTPS und erstes Meeting im Browser testen

Rufe im Browser https://meet.example.com auf (ersetze durch deine Domain). Der integrierte Let's-Encrypt-Client im web-Container hat beim ersten Start automatisch ein TLS-Zertifikat angefordert, sofern DNS-A-Record und Ports 80/443 korrekt konfiguriert sind.

Du siehst die Jitsi-Meet-Startseite mit dem Eingabefeld für den Raumnamen. Gib einen beliebigen Raumnamen ein und klicke auf „Go". Der Browser fragt nach Kamera- und Mikrofonberechtigung – erteile sie. Du landest in der Konferenz. Für einen ersten Funktionstest öffne denselben Link in einem zweiten Browser-Tab oder auf einem anderen Gerät.

Hinweis zu WebRTC: Kamera- und Mikrofon-APIs funktionieren im Browser ausschließlich über HTTPS. Ein Aufruf per http:// führt zur Fehlermeldung „Your browser does not support WebRTC" oder einem verweigerten Kamerazugriff – auch wenn technisch WebRTC unterstützt wird.

Verifizieren: Teste das TLS-Zertifikat:

curl -sv https://meet.example.com 2>&1 | grep -E "SSL|subject|issuer"
# Erwartet: Zertifikat ausgestellt von Let's Encrypt (R10/R11 o. ä.), kein Fehler

Teste mit drei Teilnehmern (dritter Tab oder Gerät), ob Audio und Video weiterhin funktionieren – ab dem dritten Teilnehmer schaltet Jitsi vom Peer-to-Peer-Modus auf die Videobridge (jvb) um. Wenn hier kein Audio/Video mehr ankommt, ist JVB_ADVERTISE_IPS falsch gesetzt oder Port 10000/UDP ist durch die Firewall geblockt.

Schritt 6: Betrieb hinter einem Reverse Proxy

Wenn du bereits einen Nginx Proxy Manager, Traefik oder Caddy als Reverse Proxy betreibst (empfehlenswert für Multidienst-Server), sind einige Anpassungen notwendig. Siehe dazu auch Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten.

Setze in der .env folgende Werte:

# HTTPS-Terminierung übernimmt der Reverse Proxy
DISABLE_HTTPS=1
# Internen HTTP-Port auf einen freien Wert legen (kein Konflikt mit Proxy)
HTTP_PORT=8000
HTTPS_PORT=8443
# Let's Encrypt im Container deaktivieren (Proxy übernimmt Zertifikate)
ENABLE_LETSENCRYPT=0

Kritisch: Port 10000/UDP kann nicht über einen HTTP-Reverse-Proxy geleitet werden – UDP ist kein HTTP. Dieser Port muss weiterhin direkt am Docker-Host exponiert und zur jvb durch die Firewall weitergeleitet sein, unabhängig vom Proxy-Setup. Der Proxy übernimmt nur den HTTPS-Traffic auf Port 443.

Starte den Stack nach der Änderung neu:

docker compose up -d --force-recreate

Verifizieren:

docker compose ps
# web-Container darf jetzt nur noch Port 8000 exponieren
# jvb-Container muss weiterhin Port 10000/udp exponieren

Schritt 7: Authentifizierung aktivieren (optional)

Standardmäßig kann jeder, der die URL kennt, einen Raum betreten und eröffnen. Für geschäftliche Umgebungen empfiehlt sich die interne Authentifizierung: Nur registrierte Nutzer dürfen Räume eröffnen, Gäste können mit einem eingeladenen Link beitreten.

# In .env ergänzen:
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Nach einem Neustart (docker compose up -d) kannst du Nutzer mit folgendem Befehl im prosody-Container anlegen:

docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua register nutzer meet.jitsi geheimespasswort

Verifizieren: Rufe die Meeting-URL auf – ohne Anmeldung sollte die Konferenz nicht startbar sein. Nach dem Login mit den Zugangsdaten öffnet sich der Raum normal.

Schritt 8: Update und Backup

Um auf eine neue Version zu aktualisieren, ändere JITSI_IMAGE_VERSION in der .env auf den neuen Tag (z. B. stable-11031) und führe aus:

docker compose pull
docker compose up -d

Sichere vor jedem Update die .env (enthält alle Passwörter) und das Konfigurationsverzeichnis:

cp .env .env.backup-$(date +%Y%m%d)
tar czf ~/jitsi-cfg-backup-$(date +%Y%m%d).tar.gz ~/.jitsi-meet-cfg/

Eine systematische Backup-Strategie für Self-Hosted-Dienste beschreibt die Anleitung 3-2-1-Backup-Strategie umsetzen. Wie du Docker Compose Stacks zusätzlich mit Secrets und Healthchecks absicherst, zeigt Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only.

Verifizieren:

docker compose ps
# Alle Container zeigen Up – ggf. mit neuem Image-Digest
docker compose images
# Zeigt die aktuell verwendeten Image-Tags

Troubleshooting / Typische Fehler

Audio/Video funktioniert nur bei 2 Teilnehmern, bricht bei 3+ ab: JVB_ADVERTISE_IPS ist nicht gesetzt oder zeigt auf die Docker-interne IP statt auf die öffentliche Host-IP. Außerdem prüfen, ob Port 10000/UDP in der Firewall und im Router freigegeben ist. Lösung: JVB_ADVERTISE_IPS=x.x.x.x in .env korrekt setzen, dann docker compose up -d --force-recreate jvb.
„Your browser does not support WebRTC" / Kamerazugriff verweigert: Jitsi wird per HTTP statt HTTPS aufgerufen. Browser sperren Kamera-/Mikrofon-APIs ohne HTTPS. Lösung: ENABLE_LETSENCRYPT=1 setzen oder eigenes Zertifikat einbinden.
„Meeting Has Been Oops'd" / Konferenz lässt sich nicht betreten: Prosody startet nicht korrekt wegen leerer XMPP-Passwörter. Lösung: ./gen-passwords.sh erneut ausführen, dann docker compose down && docker compose up -d.
Let's-Encrypt-Zertifikat schlägt fehl: Port 80 oder 443 ist durch einen anderen Dienst belegt, oder LETSENCRYPT_DOMAIN stimmt nicht mit dem DNS-A-Record überein. Lösung: DNS prüfen, Port-Konflikt lösen. Beachte das Rate-Limit von Let's Encrypt (max. 5 Zertifikate pro Woche und Domain).
Seite nach docker compose up nicht erreichbar, Container crasht sofort: Konfigurationsverzeichnisse unter ~/.jitsi-meet-cfg/ fehlen. Lösung: mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb} ausführen, dann Stack neu starten.
Konfigurationsänderungen werden nicht übernommen: Jitsi schreibt Config-Dateien beim ersten Start. Wenn das Konfigurationsverzeichnis bereits Dateien enthält, werden diese nicht überschrieben. Lösung: ~/.jitsi-meet-cfg vollständig löschen, Verzeichnisstruktur neu anlegen, Stack neu starten.
Mobile Apps können keine Verbindung aufbauen: PUBLIC_URL zeigt auf localhost oder eine interne IP. Mobile Apps benötigen eine echte öffentliche URL mit gültigem TLS-Zertifikat (kein Self-Signed). Lösung: PUBLIC_URL=https://meet.example.com korrekt setzen.
SELinux-Fehler auf RHEL/Fedora/Rocky Linux: Volume-Mounts ohne :Z-Flag – SELinux blockiert Schreibzugriff. Lösung: alle Volume-Mounts mit :Z versehen (im offiziellen compose.yaml bereits so vorgesehen).

Häufige Fragen

Brauche ich eine Datenbank wie PostgreSQL oder MySQL?

Nein. Der Jitsi-Meet-Docker-Stack benötigt keine externe Datenbank. Prosody, der XMPP-Server, verwaltet den Konferenzzustand selbst in Dateien. Redis wird nur in bestimmten Hochverfügbarkeitsszenarien mit mehreren Videobridge-Instanzen benötigt – für den Standard-Einzelserver-Betrieb ist es nicht erforderlich.

Kann ich Jitsi hinter meinem bestehenden Nginx oder Traefik betreiben?

Ja, aber mit einer wichtigen Einschränkung: DISABLE_HTTPS=1 in der .env setzen und HTTP_PORT auf einen freien internen Port legen. Der Proxy muss WebSocket-Verbindungen durchreichen (HTTP-Upgrade-Header). Port 10000/UDP muss zwingend direkt am Docker-Host exponiert bleiben – ein HTTP-Proxy kann UDP physisch nicht weiterleiten.

Wie sichere ich das Meeting ab, damit nicht jeder beitreten kann?

ENABLE_AUTH=1 und AUTH_TYPE=internal in der .env setzen. Dann können nur registrierte Nutzer Räume eröffnen. Mit ENABLE_GUESTS=1 dürfen eingeladene Gäste ohne Account beitreten, sofern ein authentifizierter Nutzer den Raum bereits geöffnet hat – ein sinnvoller Kompromiss für KMU-Umgebungen.

Werden Gespräche aufgezeichnet?

Nicht standardmäßig. Aufzeichnung und Livestreaming erfordern den optionalen Jibri-Container (separate jibri.yml-Erweiterung) und das Kernel-Modul snd-aloop auf dem Linux-Host (modprobe snd-aloop). Ohne Jibri findet keine serverseitige Aufzeichnung statt.

Wie aktualisiere ich auf eine neue Version?

JITSI_IMAGE_VERSION in der .env auf den neuen Tag ändern (z. B. stable-11031), dann docker compose pull && docker compose up -d ausführen. Die Konfigurationsverzeichnisse bleiben dabei erhalten. Vorher immer ein Backup von ~/.jitsi-meet-cfg und .env erstellen.

Läuft Jitsi Meet auf ARM-Servern (Raspberry Pi, Apple M-Chip)?

Ja, seit Release stable-7439 gibt es offizielle Multi-Arch-Images für amd64 und arm64. Ein Raspberry Pi 4 oder 5 mit 4 GB RAM ist für kleine Meetings mit bis zu zehn Teilnehmern geeignet. Für größere Gruppen ist ein vollwertiger VPS empfehlenswert.

Was ist der Unterschied zwischen „stable" und einem versionierten Tag wie „stable-11031"?

Der Tag stable zeigt immer auf das aktuellste stabile Release und zieht beim nächsten docker compose pull automatisch Updates. Der versionierte Tag stable-11031 ist eingefroren – ideal für reproduzierbare Deployments, erfordert aber manuelle Updates. Der Tag latest ist seit mehreren Releases offiziell deprecated und wird nicht mehr aktualisiert; er sollte in keiner Produktionsumgebung verwendet werden.

Fazit

Jitsi Meet ist eine der ausgereiftesten Open-Source-Videokonferenzlösungen und mit Docker Compose in unter 30 Minuten produktionsbereit. Der Vier-Container-Stack kommt ohne externe Datenbank aus, hat Let's Encrypt direkt integriert und erfüllt DSGVO-Anforderungen ohne Aufwand, weil alle Daten den eigenen Server nie verlassen. Der einzige echte Stolperstein ist die UDP-Weiterleitung für die Videobridge: Port 10000/udp muss immer direkt zum jvb-Container – daran scheitern die meisten Erstinstallationen. Wer diesen Punkt kennt und JVB_ADVERTISE_IPS korrekt setzt, bekommt ein stabiles, skalierbares Videokonferenzsystem, das Zoom und Teams in puncto Datenschutz deutlich überlegen ist.

Weiterführende Anleitungen und Quellen

Offizielle Dokumentation: Jitsi Meet Handbook – Self-Hosting Guide Docker · Quellcode und Releases: github.com/jitsi/docker-jitsi-meet