Rocket.Chat mit Docker Compose selbst hosten

Was Sie aufbauen

Ein privater Team-Chat, den Sie vollständig selbst verwalten: Rocket.Chat läuft unter Docker Compose auf Ihrem eigenen VPS, TLS wird am Reverse Proxy terminiert, und jede Nachricht liegt in einer MongoDB-Datenbank, die Sie sichern und verschieben können. Rocket.Chat ist eine ausgereifte Open-Source-Alternative zu Slack und Teams mit Kanälen, Direktnachrichten, Threads, Dateifreigaben sowie Sprach- und Videoanrufen. Die Anwendung läuft vollständig auf Hardware, die Sie mieten und kontrollieren. Sie ist jedoch nicht die einzige überzeugende Option. Falls Sie noch auswählen, stellt Mattermost, Rocket.Chat, Synapse und Zulip im Vergleich die Lösungen anhand der Punkten gegenüber, die später Probleme verursachen: RAM, Datenbank, mobile Push-Benachrichtigungen, SSO und Upgrades. Die Anwendung besteht aus einem einzelnen Container, der innerhalb weniger Minuten startet. Die eigentlichen Probleme entstehen in der daneben laufenden Datenbank. Deshalb behandelt dieser Leitfaden größtenteils MongoDB und insbesondere eine Anforderung, die beim ersten Mal viele überrascht: Rocket.Chat läuft nicht mit einer eigenständigen MongoDB. Es benötigt ein Replica Set, auch wenn dieses „Set“ aus einem einzelnen Knoten besteht.

Voraussetzungen und die RAM-Berechnung, die Ihnen niemand verrät

Dimensionieren Sie den Server realistisch. Die Untergrenze für ein kleines Team liegt bei 2 vCPU und 4 GB RAM. Der Node.js-Prozess von Rocket.Chat benötigt für sich allein etwa 1 bis 1,5 GB. Der WiredTiger-Cache von MongoDB belegt standardmäßig den größeren Wert aus 50 % von (Gesamt-RAM minus 1 GB) oder 0,256 GB. Diese Standardeinstellung geht davon aus, dass mongod den Server exklusiv nutzt: Sie wird basierend auf dem gesamten RAM berechnet und berücksichtigt nicht, was Node bereits belegt. Auf einem 4-GB-System sind das 1,5 GB, auf einem 2-GB-System etwa 0,5 GB – zusätzlich zum Heap von Node, dem Speicherbedarf von mongod außerhalb des Caches und dem Betriebssystem. Auf einem 2-GB-VPS starten beide Dienste zwar, kollidieren aber sofort, sobald echte Last entsteht: MongoDB vergrößert den Cache, Node vergrößert den Heap, dem Kernel gehen die Pages aus und der Out-of-Memory-Killer beendet den größten Prozess, meist mongod. Der Container gibt Killed aus, Docker startet ihn neu und Sie erhalten einen Chat-Server, der unter Last, die er eigentlich bewältigen sollte, alle paar Minuten abstürzt. 2 GB reichen aus, um das System mit zwei Personen zu testen; für ein Team-Server ist das nicht geeignet. Beginnen Sie mit 4 GB und planen Sie 8 GB ein, wenn Sie Dutzende gleichzeitige Benutzer, Videoanrufe oder einen wachsenden Upload-Verlauf erwarten. Kalkulieren Sie auch den Bedarf für weitere Dienste auf dem Server ein: Wenn Sie einen Notion-ähnlichen AFFiNE-Workspace auf demselben VPS betreiben, kommen vier weitere Container hinzu, die um denselben Speicher konkurrieren. Deren RAM-Bedarf muss also zusätzlich zu dem von Rocket.Chat bereitgestellt werden.

Sie benötigen zudem drei Dinge, bevor Sie beginnen. Einen Domainnamen mit einem A-Record, der auf die öffentliche IP des VPS zeigt; die Echtzeitfunktionen und mobilen Clients von Rocket.Chat benötigen einen stabilen Hostnamen, keine reine IP-Adresse. Die Ports 80 und 443 müssen offen sein, sowohl in der Server-Firewall als auch in der Netzwerk-Firewall Ihres Anbieters, die bei den meisten Anbietern über ein separates Panel gesteuert wird. Sowie ein frisches Ubuntu 24.04 KVM-VPS mit root- oder sudo-Zugriff. Falls Sie noch entscheiden, ob ein Chat-Server der richtige erste Dienst für Ihr Self-Hosting ist, erläutert der Leitfaden zu den lohnenswerten Self-Hosting-Diensten im Jahr 2026 die Vor- und Nachteile.

Installation der Docker Engine und des Compose-Plugins

Verwenden Sie das offizielle apt-Repository von Docker, nicht das docker.io-Paket aus den Ubuntu-Quellen und nicht die veraltete, eigenständige docker-compose-Python-Binärdatei. Das moderne Compose ist ein Docker-Plugin, das Sie als docker compose aufrufen – mit einem Leerzeichen, nicht mit einem Bindestrich. Das alte docker-compose v1 ist abgekündigt und verarbeitet die unten aufgeführten Healthcheck- und Abhängigkeitssyntaxen fehlerhaft.

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Bestätigen Sie, dass beide Komponenten vorhanden sind:

sudo docker version
sudo docker compose version

docker compose version Die Ausgabe einer Versionszeile ist der entscheidende Test. Aktuelle Releases geben Docker Compose version v5.x aus (v5.6.0, veröffentlicht am 2. Oktober 2026, war der Stand vom 2026-10-10); eine ältere Installation gibt möglicherweise noch v2.x aus, was von Docker ebenfalls unterstützt wird. Docker beschreibt Compose v5 als funktional identisch mit v2; die Nummerierung auf v5 dient dazu, Verwechslungen mit den veralteten Compose-Dateiformaten v2 und v3 zu vermeiden. Beide Versionen sind für diese Anleitung geeignet. Wenn ein Fehler mit docker: 'compose' is not a docker command auftritt, wurde das Plugin nicht installiert. Dies führt später zu schwer nachvollziehbaren Fehlern; beheben Sie das Problem daher an dieser Stelle.

Die Compose-Datei: MongoDB als Single-Node Replica Set

Dies ist der Punkt, an dem häufig Fehler unterlaufen, lesen Sie ihn daher aufmerksam. Rocket.Chat verwendet MongoDB-Change Streams, um neue Nachrichten in Echtzeit an verbundene Clients zu übertragen. Diese Change Streams sind ausschließlich in einem Replica Set verfügbar. Verbinden Sie Rocket.Chat mit einer einfachen, eigenständigen mongod, wird die Verbindung zwar hergestellt, das Öffnen eines Change Streams schlägt jedoch fehl, was zu einer endlosen Neustartschleife führt. Die Lösung ist simpel: Sie betreiben einen gewöhnlichen MongoDB-Container, starten diesen jedoch mit --replSet und initialisieren anschließend ein Set mit einem einzigen Mitglied.

Erstellen Sie ein Arbeitsverzeichnis und eine compose.yml:

services:
  mongodb:
    image: mongo:8.0
    restart: always
    command: ["mongod", "--replSet", "rs0", "--bind_ip_all", "--oplogSize", "128"]
    volumes:
      - mongodb_data:/data/db
      - mongodb_config:/data/configdb
    healthcheck:
      test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 10s
      retries: 12

  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:8.5.1
    restart: always
    depends_on:
      mongodb:
        condition: service_healthy
    environment:
      MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
      MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
      ROOT_URL: "https://chat.example.com"
      PORT: "3000"
    ports:
      - "127.0.0.1:3000:3000"

volumes:
  mongodb_data:
  mongodb_config:

Einige Entscheidungen hier sind bewusst getroffen. Der Rocket.Chat-Port wird auf 127.0.0.1:3000 veröffentlicht, nicht auf 0.0.0.0. Da die Anwendung selbst kein TLS unterstützt, sollte nur der Reverse Proxy auf demselben Host darauf zugreifen können; eine Bindung an alle Schnittstellen würde eine unverschlüsselte Anmeldeseite direkt im öffentlichen Internet exponieren. MongoDB wird gar nicht auf dem Host veröffentlicht; es ist nur über das interne Netzwerk von Compose unter dem Namen mongodb erreichbar, was exakt dem Hostnamen entspricht, den die MONGO_URL verwendet. MONGO_URL enthält ?replicaSet=rs0, womit das Set explizit benannt wird; MongoDB empfiehlt diese Einstellung für ein konsistentes Verhalten über verschiedene Treiber hinweg. Das Weglassen führt nicht zwangsläufig zu Fehlern: directConnection verwendet standardmäßig false, sodass der Treiber das Replica Set weiterhin erkennt und Operationen an den Primary sendet – vorausgesetzt, das Set wurde mit einem Hostnamen initialisiert, den Rocket.Chat auflösen kann, worum sich der nächste Abschnitt kümmert. MONGO_OPLOG_URL verweist auf die local-Datenbank, in der das Oplog liegt; modernes Rocket.Chat bevorzugt Change Streams, aber die Konfiguration schadet nicht und stellt die Kompatibilität mit älteren Codepfaden sicher. Der depends_on verwendet condition: service_healthy, sodass Compose wartet, bis MongoDB auf einen ping antwortet, bevor Rocket.Chat überhaupt gestartet wird; genau dazu dient der Healthcheck.

Verwenden Sie für beide Images feste Versions-Tags, wie mongo:8.0 und ein explizites Rocket.Chat-Release wie 8.5.1 in diesem Beispiel. Verwenden Sie niemals :latest, da dies ein unbeaufsichtigtes docker pull in ein versehentliches, nicht migrierbares Upgrade verwandelt. Prüfen Sie das aktuelle stabile Rocket.Chat-Release und die unterstützten MongoDB-Versionen, bevor Sie die Version festlegen. Rocket.Chat veröffentlicht für jedes Release ein maschinenlesbares Info-Dokument: mongo:8.0 ist für 8.5.1 die einzige unterstützte Engine, wie curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' mit der Rückgabe von compatibleMongoVersions: ["8.0"] bestätigt. Zusätzlich gibt es ein lts-Flag, das anzeigt, ob es sich bei dem Release um einen Long-Term-Support-Build handelt, der sich für einen Server eignet, den Sie nicht ständig manuell warten möchten. Nicht jedes Projekt veröffentlicht ein versioniertes Image; in diesem Fall erfolgt die Fixierung über die Quelle: Self-Hosting des openGym Workout-Trackers bedeutet hier, einen spezifischen Git-Tag auszuchecken und daraus zu bauen, anstatt einem sich ändernden Branch zu folgen.

Replikatsatz initialisieren

Starten Sie den Stack:

sudo docker compose up -d

Rocket.Chat stürzt sofort ab, und Docker startet den Container immer wieder neu. Das ist erwartetes Verhalten, weil der Replikatsatz noch nicht existiert. Erstellen Sie ihn einmalig manuell:

sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'

Das korrekte Ergebnis ist { ok: 1 }. Innerhalb weniger Sekunden wählt sich der einzelne Knoten selbst zum Primary. Prüfen Sie dies mit:

sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'

Sie sollten PRIMARY sehen. Das wichtigste Detail auf dieser gesamten Seite ist das Argument host: "mongodb:27017". Wenn Sie ein einfaches rs.initiate() ohne Mitgliederliste ausführen, gibt MongoDB den Replikatsatz unter dem internen Hostnamen des Containers bekannt, einem zufälligen Hash wie a1b2c3d4e5f6. Rocket.Chat kann diesen Namen aus seinem eigenen Container heraus nicht auflösen. Der MongoDB-Treiber schlägt deshalb bei der DNS-Auflösung fehl und protokolliert endlos MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Initialisieren Sie den Replikatsatz immer mit dem expliziten Dienstnamen, der zu Ihrem MONGO_URL passt.

Erster Start: Den Startvorgang überwachen

Sobald der Replica Set den Status primary hat, verbindet sich Rocket.Chat beim nächsten Neustart sauber und beginnt mit den Migrationen für den ersten Start. Überwachen Sie die Logs:

sudo docker compose logs -f rocketchat

Die gesuchte Zeile ist das Startbanner:

+--------------------------------------------+
        SERVER RUNNING
   Rocket.Chat Version: 8.5.1
        NodeJS Version: 22.22.3 - x64
+--------------------------------------------+

Der erste Start dauert länger. Die Anwendung führt Datenbankmigrationen aus und erstellt Indizes. Warten Sie daher ein bis zwei Minuten, bevor Sie die Ursache untersuchen. Wenn das Log stattdessen wiederholt MongoServerSelectionError: Server selection timed out after 30000 ms mit einer Topologiebeschreibung des Typs ReplicaSetNoPrimary ausgibt, wurde der Replica Set nicht initialisiert. Wenn getaddrinfo ENOTFOUND mit einem zufälligen Hash wiederholt ausgegeben wird, wurde er mit dem falschen Host initialisiert. Gehen Sie in beiden Fällen einen Schritt zurück. Sobald SERVER RUNNING angezeigt wird, lauscht Rocket.Chat auf 127.0.0.1:3000. Dann können Sie einen echten Hostnamen und TLS davor schalten.

Hinter TLS betreiben

Machen Sie Rocket.Chat niemals über reines HTTP erreichbar. Wenn Sie sich einmal über http:// anmelden, geben Sie Ihr Administratorkennwort an jeden weiter, der den Netzwerkverkehr mitlesen kann. Terminieren Sie TLS in einem Reverse Proxy auf demselben Server und leiten Sie die Anfragen an 127.0.0.1:3000 weiter. Zwei Punkte sind wichtig: Der Proxy muss die Header für das WebSocket-Upgrade weiterleiten, weil Rocket.Chat Echtzeitverbindungen verwendet und ohne diese Header nicht funktioniert. Außerdem muss ROOT_URL im Container exakt der öffentlichen HTTPS-Adresse entsprechen, die Benutzer eingeben.

Beginnen Sie mit einem einfachen HTTP-Serverblock für nginx, der Anfragen an die Anwendung weiterleitet und die Upgrade-Header überträgt. Speichern Sie ihn als /etc/nginx/sites-available/rocketchat, erstellen Sie einen symbolischen Link nach sites-enabled und laden Sie nginx neu:

server {
    listen 80;
    server_name chat.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Lassen Sie den Server zunächst auf Port 80 laufen. Ein Block mit listen 443 ssl; und ohne Zertifikat besteht sudo nginx -t nicht. Laden Sie nginx neu (sudo nginx -t && sudo systemctl reload nginx) und stellen Sie anschließend das Zertifikat aus. Der einfachste Weg unter Ubuntu ist Let's-Encrypt-TLS-Zertifikate mit Certbot und nginx: certbot --nginx schreibt den Block oben direkt um. Dabei werden listen 443 ssl;, die ssl_certificate-Zeilen und eine automatische Weiterleitung von Port 80 auf Port 443 ergänzt. Außerdem wird die Erneuerung für Sie eingerichtet. Wenn Sie bereits mehrere Container hinter einem Proxy betreiben, ist Traefik mit automatischem TLS für viele Docker-Anwendungen die übersichtlichere Option. Fügen Sie dem Dienst rocketchat Router- und Service-Labels hinzu. Traefik stellt das Zertifikat dann automatisch aus und erneuert es, ohne dass ein nginx-Block erforderlich ist. Setzen Sie in jedem Fall ROOT_URL auf https://chat.example.com in compose.yml und führen Sie sudo docker compose up -d erneut aus, damit der Container die Änderung übernimmt. Wenn der Server nur aus Ihrem eigenen Netzwerk und nicht aus dem öffentlichen Internet erreichbar sein soll, schalten Sie einen selbst gehosteten WireGuard-VPN auf dem VPS davor und binden Sie den Proxy an die Tunneladresse.

Der Einrichtungsassistent beim ersten Start

Navigieren Sie zu https://chat.example.com, um den kurzen Einrichtungsassistenten von Rocket.Chat zu durchlaufen. Zuerst legen Sie das Administratorkonto mit Klarnamen, Benutzername, E-Mail-Adresse und einem sicheren Passwort an. Da dies das einzige existierende Konto ist, dürfen Sie die Zugangsdaten nicht verlieren. Danach folgen Organisations- und Serverinformationen: Name, Branche, Größe, Seitenname und Standardsprache. Diese Angaben sind rein kosmetischer Natur; füllen Sie diese aus und fahren Sie fort. Anschließend treffen Sie die entscheidende Wahl: Registrieren Sie diesen Arbeitsbereich bei der Rocket.Chat Cloud oder betreiben Sie ihn im Modus Standalone.

Die Registrierung ermöglicht mobile Push-Benachrichtigungen über das Gateway von Rocket.Chat sowie den Zugriff auf den Add-on-Marktplatz. Im Gegenzug entsteht eine Abhängigkeit von der Cloud-Steuerungsebene von Rocket.Chat. Über das Gateway versendete Push-Nachrichten werden zudem auf das monatliche Limit Ihres Arbeitsbereichs angerechnet. Der Standalone-Modus hält den Server vollständig privat und frei von externen Abhängigkeiten. Allerdings erhalten die offiziellen iOS- und Android-Apps dann keine Push-Benachrichtigungen mehr, da diese laut Dokumentation von Rocket.Chat nur mit dem Cloud-Gateway funktionieren, welches auf nicht registrierten Arbeitsbereichen nicht aktiv ist. Der Ausweg hierfür ist ein eigener, individuell angepasster Build der mobilen App: Deaktivieren Sie das Gateway in den Push-Einstellungen, hinterlegen Sie Ihre eigenen APNs-Zertifikate sowie Firebase Cloud Messaging-Zugangsdaten und lassen Sie Ihre Benutzer Ihre eigene App anstelle der offiziellen Version installieren. Wählen Sie den Standalone-Modus, wenn Datenschutz oberste Priorität hat, Ihre Benutzer primär die Web-App verwenden oder Sie bereit sind, eine eigene mobile App bereitzustellen. Wählen Sie die Registrierung, wenn Push-Benachrichtigungen in den offiziellen Apps zwingend erforderlich sind. Sie können diese Entscheidung später unter Admin jederzeit ändern.

Sichern Sie die Instanz, bevor Sie andere einladen

Rocket.Chat wird standardmäßig mit aktivierter offener Registrierung ausgeliefert. Das Registration Form ist auf Public gesetzt. Dadurch kann jeder, der die URL kennt, ein Konto erstellen. Unter einem öffentlich erreichbaren Hostnamen ist das eine offene Zugriffsmöglichkeit. Öffnen Sie Admin → Settings → Accounts → Registration und setzen Sie Registration Form auf Disabled. Dann erstellen Sie Konten manuell oder über Einladungslinks. Alternativ können Sie Secret URL verwenden. Deaktivieren Sie dort außerdem Allow Anonymous Read und Allow Anonymous Write, sofern Sie nicht ausdrücklich einen öffentlichen Kanal mit Leseberechtigung für anonyme Benutzer benötigen. Wenn die manuelle Erstellung jedes Kontos zu aufwendig ist und dies nicht der einzige Dienst ist, bei dem sich Ihr Team anmeldet, verbinden Sie den OAuth-Login von Rocket.Chat stattdessen mit einem selbst gehosteten Authentik-SSO-Server. Ein- und Austritte werden dann zentral an einer Stelle verwaltet und nicht für jede Anwendung einzeln.

Legen Sie auch fest, wo Uploads gespeichert werden. Der standardmäßige Speicher für File Upload ist GridFS. Dabei werden alle Bilder und Anhänge direkt in MongoDB gespeichert. Das ist einfach, führt aber dazu, dass Ihre Datenbank und jedes mongodump, das Sie erstellen, unbegrenzt wachsen, sobald Benutzer Screenshots einfügen. Unter Admin → Settings → File Upload können Sie den Speicher auf das lokale Dateisystem oder einen S3-kompatiblen Bucket umstellen und eine sinnvolle maximale Dateigröße festlegen. Wenn Ihr Team ganze Fotosammlungen statt gelegentlicher Screenshots austauscht, sollten diese in einem dedizierten Fotoserver und nicht in einer Chat-Datenbank gespeichert werden. PhotoPrism und Immich im Vergleich zeigt, wie viel RAM die beiden Lösungen benötigen und welche Backup-Befehle dafür erforderlich sind. Für ein kleines Team ist GridFS ausreichend. Beachten Sie jedoch, dass Ihre Backups mit der Zeit größer werden.

Backups mit mongodump

Alle Ihre Daten liegen im Volume mongodb_data. Kopieren Sie das Volume nicht einfach unter einer laufenden Datenbank weg. Erstellen Sie stattdessen mit mongodump einen konsistenten Dump und streamen Sie ihn in eine Datei auf dem Host:

sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gz

Dieses einzelne komprimierte gzip-Archiv enthält Ihren gesamten Workspace: Benutzer, Channels, Nachrichten, Einstellungen und, falls Sie Uploads in GridFS belassen haben, auch die Dateien. Wenn Sie Uploads in das Dateisystem oder nach S3 verschoben haben, sichern Sie diesen Speicher separat. Stellen Sie den Dump auf einem frischen Stack wieder her. Initialisieren Sie zuerst das Replica Set und führen Sie anschließend Folgendes aus:

sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gz

Kopieren Sie das Archiv vom System herunter, in einen Objektspeicher, auf einen anderen Server oder an einen beliebigen anderen Ort. Wenn der VPS ausfällt, darf die Sicherung nicht ebenfalls verloren gehen. Führen Sie den Dump jede Nacht per cron aus. Eine Sicherung, die Sie noch nie wiederhergestellt haben, ist eine Hoffnung, aber keine Sicherung. Üben Sie die Wiederherstellung einmal auf einem Wegwerf-VPS, damit Sie wissen, dass sie funktioniert, bevor Sie sie benötigen.

Upgrades: Tags fixieren, Hinweise lesen, MongoDB-Matrix beachten

Zwei Regeln sorgen für reibungslose Upgrades. Erstens: Aktualisieren Sie Rocket.Chat immer nur um eine Hauptversion. Beim Start führt die Software Schema-Migrationen durch. Die Dokumentation von Rocket.Chat schreibt vor, Hauptversionen nacheinander zu aktualisieren, da das Überspringen von Versionen zu schwerwiegenden Kompatibilitätsproblemen führen kann. Verlassen Sie sich nicht darauf, dass die Software Sie blockiert: Die Dokumentation garantiert nicht, dass ein Sprung von 6.x direkt auf 8.x sicher verweigert wird. Schlägt eine Migration mittendrin fehl, bleibt der Lock gesetzt und erfordert eine manuelle Reparatur. Ändern Sie den Image-Tag auf das aktuellste Release der nächsten Hauptversion, lesen Sie die Release-Hinweise auf Breaking Changes, führen Sie docker compose up -d aus und überwachen Sie die Logs, bis die Migration abgeschlossen ist, bevor Sie fortfahren. Zweitens: Beachten Sie die MongoDB-Support-Matrix. Jedes Rocket.Chat-Release unterstützt spezifische MongoDB-Versionen; curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions gibt an, welche das sind. Wenn Sie MongoDB aktualisieren, beispielsweise von 7.0 auf 8.0, führen Sie dies schrittweise durch und setzen Sie nach jedem Sprung die Feature-Compatibility-Version. Unter MongoDB 8.0 erfordert dieser Befehl ein explizites confirm: true, andernfalls wird er mit dem Hinweis verweigert, den Befehl mit dem Bestätigungs-Flag erneut auszuführen:

sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'

Erstellen Sie vor jedem Upgrade einer der beiden Komponenten ein mongodump. Dies ist Ihre vollständige Absicherung.

Fehlermodi und exakte Fehlermeldungen

Rocket.Chat befindet sich direkt nach docker compose up in einer Neustartschleife und docker compose logs rocketchat füllt sich mit einer MongoServerSelectionError. MongoDB läuft zwar, aber der Treiber kann kein Primary-Element auswählen. Die exakte Zeichenfolge verrät Ihnen den Fehler. Server selection timed out after 30000 ms mit einem Topologie-Typ von ReplicaSetNoPrimary bedeutet, dass Sie rs.initiate() nie ausgeführt haben; das Set besitzt noch keine Konfiguration. getaddrinfo ENOTFOUND gefolgt von einem zufälligen Hash bedeutet, dass Sie die Initialisierung ohne das explizite host: "mongodb:27017" durchgeführt haben. MongoDB hat daher einen nicht auflösbaren Container-Hostname bekannt gegeben. Diagnostizieren Sie dies mit sudo docker compose exec mongodb mongosh --eval 'rs.status()': Erscheint der Fehler MongoServerError: no replset config has been received, initialisieren Sie das Set. Zeigt es ein Mitglied an, dessen name ein zufälliger Hash ist, führen Sie die Initialisierung erneut mit dem Dienstnamen durch.

Die Web-UI lädt, aber der Login-Vorgang dreht sich endlos und wird nicht abgeschlossen. Öffnen Sie die Browser-Konsole, dort sehen Sie WebSocket connection to 'wss://chat.example.com/websocket' failed. Dies ist fast immer ein ROOT_URL-Konfigurationsfehler oder ein Proxy, der die Upgrade-Header nicht weiterleitet. Stellen Sie sicher, dass ROOT_URL der exakten öffentlichen Adresse inklusive https:// entspricht und dass Ihr nginx-location-Block Upgrade sowie Connection "upgrade" mit proxy_http_version 1.1 setzt. Ändern Sie dies bei Bedarf und führen Sie docker compose up -d erneut aus.

Ein Container stirbt ständig und docker compose ps zeigt, dass er Restarting. docker compose logs bricht mitten in der Zeile ab und sudo dmesg | tail zeigt Out of memory: Killed process 12345 (mongod) durch den OOM-Killer; der Exit-Code ist 137. Der Server hat keinen Arbeitsspeicher mehr. Die dauerhafte Lösung ist ein größerer VPS, mindestens 4 GB RAM. Als Übergangslösung können Sie Swap hinzufügen und den Cache von MongoDB mit --wiredTigerCacheSizeGB in dessen command begrenzen. Setzen Sie diesen Wert unter den Standardwert, beispielsweise auf 1 bei einem 4-GB-Server (Standard 1.5) oder 0.3 bei einem 2-GB-Server (Standard ca. 0.5). Swap verzögert den nächsten OOM-Absturz unter echter Last jedoch nur:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

docker compose up schlägt mit Error response from daemon: driver failed programming external connectivity ... bind: address already in use fehl. Ein anderer Prozess belegt bereits Port 3000, häufig ein vorheriger Rocket.Chat-Container, der nicht sauber beendet wurde, oder eine andere Anwendung. Finden Sie diesen mit sudo ss -ltnp | grep :3000, stoppen Sie den Prozess oder Container, oder ändern Sie die Host-Seite des Mappings auf 127.0.0.1:3001:3000 und aktualisieren Sie das proxy_pass Ihres Proxys entsprechend.

FAQ

Benötigt Rocket.Chat zwingend ein MongoDB Replica Set?

Ja, selbst auf einem einzelnen Server mit nur einem Datenbank-Knoten. Rocket.Chat stellt Nachrichten in Echtzeit über MongoDB Change Streams zu. Da Change Streams eine Funktion sind, die ausschließlich in Replica Sets verfügbar ist, kann eine eigenständige Instanz (Standalone) mongod diese nicht öffnen. Sie benötigen dafür keine mehreren Maschinen; starten Sie einen einzelnen MongoDB-Container mit --replSet rs0 und initialisieren Sie ein Set mit einem Mitglied über rs.initiate(). Überspringen Sie diesen Schritt, findet der Treiber keinen Primary-Knoten. Rocket.Chat verfängt sich dann in einer Neustart-Schleife mit MongoServerSelectionError: Server selection timed out und schließt den Bootvorgang nie ab.

Wie viel RAM benötigt ein selbst gehostetes Rocket.Chat?

Planen Sie 4 GB als praktisches Minimum und 8 GB für ein aktives Team ein. Der Node-Prozess von Rocket.Chat belegt etwa 1 bis 1,5 GB. Der standardmäßige WiredTiger-Cache von MongoDB berechnet sich aus der Hälfte des (Gesamt-RAM minus 1 GB), so als ob keine weiteren Dienste auf dem System laufen würden. Auf einem System mit 2 GB RAM kollidieren dieser Cache, der Heap von Node und der Overhead von mongod. Der Out-of-Memory-Killer beendet mongod unter realer Last, was sich durch Killed in den Logs und den Exit-Code 137 bemerkbar macht. 2 GB reichen lediglich aus, um die Software mit wenigen Testbenutzern zu evaluieren.

Wie binde ich Rocket.Chat hinter HTTPS ein?

Betreiben Sie einen Reverse Proxy auf demselben VPS, der TLS terminiert und Anfragen an 127.0.0.1:3000 weiterleitet. Setzen Sie die Umgebungsvariable ROOT_URL des Containers auf Ihre öffentliche https://-Adresse. Der Proxy muss die WebSocket-Upgrade-Header weiterleiten, da der Login sonst hängen bleibt. Certbot mit nginx ist das einfachste Setup für eine einzelne Anwendung; Traefik ist übersichtlicher, wenn Sie mehrere Container hinter einem Proxy betreiben und eine automatische Zertifikatsverwaltung wünschen.

Wie sichere ich ein selbst gehostetes Rocket.Chat?

Erstellen Sie einen konsistenten Datenbank-Dump mit mongodump, anstatt das Volume direkt zu kopieren: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Dieses Archiv enthält Benutzer, Kanäle, Nachrichten und Einstellungen sowie hochgeladene Dateien, sofern Sie den Speicher auf GridFS belassen haben. Kopieren Sie das Archiv vom Server, automatisieren Sie den Vorgang nächtlich per cron und führen Sie regelmäßig eine mongorestore auf einem Testsystem durch, um sicherzustellen, dass die Wiederherstellung funktioniert.

Wie aktualisiere ich Rocket.Chat, ohne MongoDB zu beschädigen?

Aktualisieren Sie Rocket.Chat immer nur um eine Hauptversion (Major Version) nach der anderen. Die Anwendung führt beim Start Migrationen durch; die Dokumentation warnt davor, dass das Überspringen von Hauptversionen zu schwerwiegenden Kompatibilitätsproblemen führen kann. Lesen Sie vor jeder Änderung des fixierten Image-Tags die Release-Notes. Prüfen Sie mit curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, welche MongoDB-Versionen das Ziel-Release unterstützt. Wenn Sie MongoDB aktualisieren, gehen Sie ebenfalls schrittweise vor und setzen Sie setFeatureCompatibilityVersion mit confirm: true nach jedem Zwischenschritt. Erstellen Sie vor jedem Vorgang zwingend ein mongodump.