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, über die niemand spricht

Planen Sie die Größe des Servers realistisch. Die untere sinnvolle Grenze für ein kleines Team sind 2 vCPU und 4 GB RAM. Der Node.js-Prozess von Rocket.Chat benötigt allein ungefähr 1 bis 1.5 GB, und der WiredTiger-Cache von MongoDB beansprucht standardmäßig etwa die Hälfte des verbleibenden RAM. Auf einem VPS mit 2 GB passen beide Prozesse beim Booten noch zusammen. Sobald echter Netzwerkverkehr eintrifft, geraten sie jedoch aneinander: MongoDB vergrößert seinen Cache, Node seinen Heap, dem Kernel gehen Seiten aus, und der Out-of-Memory-Killer beendet den jeweils größten Prozess, normalerweise mongod. Der Container gibt Killed aus, Docker startet ihn neu, und Sie erhalten einen Chatserver, der unter einer Last, die er problemlos bewältigen sollte, alle paar Minuten ausfällt. 2 GB reichen aus, um das System mit zwei Personen auszuprobieren. Für einen Teamserver reichen sie nicht. Beginnen Sie mit 4 GB. Wenn Sie Dutzende gleichzeitige Benutzer, Videokonferenzen oder eine wachsende Upload-Historie erwarten, sollten Sie 8 GB einplanen. Berücksichtigen Sie auch alle anderen Dienste, die der Server ausführen muss: Wenn Sie einen AFFiNE-Arbeitsbereich im Notion-Stil auf demselben VPS betreiben, konkurrieren vier weitere Container um dieselben Speicherseiten. Der dafür benötigte RAM muss zusätzlich zum Bedarf von Rocket.Chat eingeplant werden und darf nicht von diesem abgezogen werden.

Vor dem Start müssen außerdem drei Voraussetzungen erfüllt sein. Sie benötigen einen Domainnamen mit einem A-Record, der auf die öffentliche IP-Adresse des VPS zeigt. Die Echtzeitfunktionen und mobilen Clients von Rocket.Chat benötigen einen stabilen Hostnamen, keine nackte IP-Adresse. Außerdem müssen Ports 80 und 443 geöffnet sein, sowohl in der Server-Firewall als auch in der Netzwerk-Firewall Ihres Providers. In den meisten Verwaltungsoberflächen handelt es sich dabei um eine separate Einstellung. Zusätzlich benötigen Sie einen frischen Ubuntu-24.04-KVM-VPS mit root oder sudo. Wenn Sie noch entscheiden, ob ein Chatserver der richtige erste Dienst für Sie ist, ordnet der Leitfaden dazu, was sich 2026 für das Self-Hosting lohnt die wichtigsten Abwägungen ein.

Docker Engine und das Compose-Plugin installieren

Verwenden Sie das eigene apt-Repository von Docker, nicht das docker.io-Paket, das Ubuntu bereitstellt, und nicht die veraltete eigenständige docker-compose-Python-Binärdatei. Modernes Compose ist ein Docker-Plugin, das Sie als docker compose aufrufen, also mit einem Leerzeichen und nicht mit einem Bindestrich. docker-compose v1 ist veraltet und wird nicht mehr unterstützt. Außerdem verarbeitet es die unten verwendete Syntax für Healthchecks und Abhängigkeiten nicht korrekt.

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

Prüfen Sie, ob beide Komponenten vorhanden sind:

sudo docker version
sudo docker compose version

Entscheidend ist, dass docker compose version etwas wie Docker Compose version v2.x ausgibt. Wenn der Befehl mit docker: 'compose' is not a docker command fehlschlägt, wurde das Plugin nicht installiert. Beheben Sie das jetzt, bevor später schwer nachvollziehbare Fehler auftreten.

Die Compose-Datei: MongoDB als Replica Set mit einem Knoten

Dieser Teil wird häufig falsch umgesetzt. Lesen Sie ihn daher langsam durch. Rocket.Chat verwendet Change Streams, um neue Nachrichten in Echtzeit an verbundene Clients zu übertragen. Change Streams sind nur in einem Replica Set verfügbar. Wenn Sie Rocket.Chat auf einen einfachen eigenständigen mongod verweisen, stellt die Anwendung zwar eine Verbindung her, kann aber keinen Change Stream öffnen und startet anschließend dauerhaft neu. Die Lösung ist unkompliziert: Sie verwenden einen einzelnen normalen MongoDB-Container, starten ihn jedoch mit --replSet und initialisieren anschließend ein Replica Set mit einem 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 in dieser Datei sind bewusst so getroffen. Der Rocket.Chat-Port wird auf 127.0.0.1:3000 veröffentlicht, nicht auf 0.0.0.0. Die Anwendung selbst verwendet kein TLS. Daher sollte nur der Reverse Proxy auf demselben Server darauf zugreifen können. Wenn Sie den Port an alle Schnittstellen binden, wäre eine unverschlüsselte Anmeldeseite direkt aus dem öffentlichen Internet erreichbar. MongoDB wird überhaupt nicht auf dem Host veröffentlicht. Der Dienst ist nur über das interne Compose-Netzwerk unter dem Namen mongodb erreichbar. Genau diesen Hostnamen verwendet MONGO_URL. MONGO_URL überträgt ?replicaSet=rs0. Wenn Sie diese Option weglassen, behandelt der Treiber den Server als eigenständig, obwohl er zu einem Replica Set gehört. Change Streams schlagen dann weiterhin fehl. MONGO_OPLOG_URL verweist auf die local-Datenbank, in der sich das Oplog befindet. Modernes Rocket.Chat bevorzugt Change Streams. Das Setzen dieser Option ist jedoch unproblematisch und hält ältere Codepfade funktionsfähig. depends_on verwendet condition: service_healthy. Compose wartet dadurch, bis MongoDB auf einen ping antwortet, bevor Rocket.Chat überhaupt gestartet wird. Dafür ist der Healthcheck vorgesehen.

Fixieren Sie für beide Images echte Versionstags: mongo:8.0 und hier beispielsweise ein explizites Rocket.Chat-Release wie 8.5.1. Verwenden Sie niemals :latest. Andernfalls wird ein unbeaufsichtigtes docker pull zu einem versehentlichen Upgrade, für das keine Migration möglich ist. Prüfen Sie vor dem Fixieren das aktuelle stabile Rocket.Chat-Release und die von ihm unterstützten MongoDB-Versionen. Rocket.Chat veröffentlicht für jedes Release ein maschinenlesbares Informationsdokument: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' liefert für 8.5.1 den Wert compatibleMongoVersions: ["8.0"]. Damit ist mongo:8.0 die einzige unterstützte Engine. Zusätzlich gibt das Dokument mit dem Flag lts an, ob es sich um ein Long-Term-Support-Release handelt, das sich für einen Server eignet, den Sie möglichst nicht laufend betreuen möchten. Nicht jedes Projekt veröffentlicht ein versioniertes Image. In diesem Fall wird die Version an der Quelle fixiert: Self-Hosting des openGym-Workout-Trackers bedeutet, einen bestimmten Git-Tag auszuchecken und daraus zu bauen, statt 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 Assistent für die Ersteinrichtung

Rufen Sie https://chat.example.com auf. Rocket.Chat führt Sie durch einen kurzen Assistenten. Zuerst legen Sie das Administratorkonto mit einem echten Namen, Benutzernamen, einer E-Mail-Adresse und einem sicheren Passwort an. Dies ist das einzige vorhandene Konto. Verlieren Sie die Zugangsdaten daher nicht. Danach folgen Organisations- und Serverinformationen: Name, Branche, Größe, der Name der Website und die Standardsprache. Diese Angaben sind hauptsächlich kosmetischer Natur. Füllen Sie sie aus und fahren Sie fort. Anschließend treffen Sie die wichtige Entscheidung: Sie können diesen Arbeitsbereich bei Rocket.Chat Cloud registrieren oder ihn eigenständig betreiben.

Die Registrierung aktiviert mobile Push-Benachrichtigungen über das Gateway von Rocket.Chat sowie den Add-on-Marktplatz. Dafür besteht eine Verbindung zur Cloud-Steuerung von Rocket.Chat. Im eigenständigen Betrieb bleibt der Server vollständig privat und unabhängig. Push-Benachrichtigungen für iOS und Android funktionieren dann jedoch nicht mehr. Apple und Google erlauben es einer selbst erstellten Anwendung nicht, die Push-Zertifikate zu verwenden. Die offiziellen Anwendungen leiten Push-Benachrichtigungen über das Cloud-Gateway weiter. Wählen Sie den eigenständigen Betrieb, wenn Datenschutz entscheidend ist und Ihre Benutzer die Webanwendung verwenden. Wählen Sie die Registrierung, wenn mobile Push-Benachrichtigungen unverzichtbar sind. Sie können diese Entscheidung später unter Admin ä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 festlegen, Hinweise lesen, die MongoDB-Kompatibilitätsmatrix beachten

Zwei Regeln machen Upgrades planbar. Erstens: Aktualisieren Sie Rocket.Chat jeweils nur um eine Major-Version. Beim Start führt Rocket.Chat Schema-Migrationen aus und verweigert den direkten Sprung über mehrere Major-Versionen. Wenn Sie beispielsweise direkt von 6.x auf 8.x wechseln, wird der Start mit einem Migrationsfehler abgebrochen, statt Ihre Daten zu beschädigen. Setzen Sie den Image-Tag auf das neueste Release der nächsten Major-Version, lesen Sie die Hinweise dieses Releases auf inkompatible Änderungen, 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-Supportmatrix. Jedes Rocket.Chat-Release unterstützt eine bestimmte Auswahl an MongoDB-Versionen. curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions zeigt Ihnen, welche Versionen unterstützt werden. Wenn Sie MongoDB aktualisieren, beispielsweise von 7.0 auf 8.0, wechseln Sie jeweils nur um eine Major-Version und setzen Sie nach jedem Schritt die Feature-Compatibility-Version. Unter MongoDB 8.0 erfordert dieser Befehl ein explizites confirm: true. Andernfalls wird der Vorgang mit einer Meldung abgebrochen, die Sie auffordert, 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. Das ist die gesamte Absicherung.

Fehlerbilder mit den exakten Zeichenfolgen

Rocket.Chat führt direkt nach docker compose up Neustartschleifen aus, und docker compose logs rocketchat füllt sich mit einem MongoServerSelectionError. MongoDB läuft, aber der Treiber kann keinen Primary auswählen. Die exakte Zeichenfolge zeigt, welcher Fehler vorliegt. Server selection timed out after 30000 ms mit dem Topologietyp ReplicaSetNoPrimary bedeutet, dass Sie rs.initiate() noch nicht ausgeführt haben. Das Set hat noch keine Konfiguration. getaddrinfo ENOTFOUND gefolgt von einem zufälligen Hash bedeutet, dass Sie die Initialisierung ohne das explizite host: "mongodb:27017" gestartet haben. MongoDB hat dadurch einen nicht auflösbaren Container-Hostnamen bekanntgegeben. Diagnostizieren Sie das mit sudo docker compose exec mongodb mongosh --eval 'rs.status()': Wenn der Befehl MongoServerError: no replset config has been received meldet, initialisieren Sie das Set. Wenn er ein Mitglied anzeigt, dessen name ein zufälliger Hash ist, initialisieren Sie das Set mit dem Dienstnamen erneut.

Die Weboberfläche wird geladen, aber der Anmeldevorgang dreht sich endlos und wird nie abgeschlossen. Öffnen Sie die Browserkonsole. Dort sehen Sie WebSocket connection to 'wss://chat.example.com/websocket' failed. Fast immer liegt ein ROOT_URL-Konflikt oder ein Proxy vor, der die Upgrade-Header nicht weiterleitet. Prüfen Sie, ob ROOT_URL exakt der öffentlichen Adresse einschließlich https:// entspricht und ob der nginx-Block location Upgrade und Connection "upgrade" mit proxy_http_version 1.1 setzt. Ändern Sie die entsprechende Einstellung und führen Sie docker compose up -d erneut aus.

Ein Container beendet sich ständig, und docker compose ps zeigt Restarting an. docker compose logs bricht mitten in der Zeile ab, und sudo dmesg | tail zeigt Out of memory: Killed process 12345 (mongod) vom oom-killer an. Der Exit-Code ist 137. Der Server verfügt nicht über ausreichend RAM. Die eigentliche Lösung ist ein größerer VPS mit mindestens 4 GB. Als Übergangslösung können Sie Swap hinzufügen und den Cache von MongoDB mit --wiredTigerCacheSizeGB 1 in dessen command begrenzen. Unter realer Last verzögert Swap den nächsten OOM 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. Port 3000 wird bereits verwendet. Häufig ist ein vorheriger Rocket.Chat-Container die Ursache, der nicht sauber beendet wurde. Es kann auch eine andere Anwendung sein. Ermitteln Sie den Prozess mit sudo ss -ltnp | grep :3000. Beenden Sie den Prozess oder Container. Alternativ ändern Sie die Host-Seite des Mappings in 127.0.0.1:3001:3000 und passen proxy_pass in der Proxy-Konfiguration entsprechend an.

FAQ

Benötigt Rocket.Chat wirklich ein MongoDB-Replikatset?

Ja, auch bei einem einzelnen Server mit einem Datenbankknoten. Rocket.Chat stellt Nachrichten in Echtzeit über MongoDB Change Streams bereit. Change Streams sind nur mit einem Replikatset verfügbar. Ein eigenständiger mongod kann keinen Change Stream öffnen. Sie benötigen keine mehreren Rechner. Starten Sie einen einzelnen MongoDB-Container mit --replSet rs0 und initialisieren Sie ein Replikatset mit einem Mitglied mit rs.initiate(). Wenn Sie diesen Schritt überspringen, findet der Treiber nie einen Primary. Rocket.Chat startet dann mit MongoServerSelectionError: Server selection timed out wiederholt neu und wird nie vollständig gestartet.

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

Planen Sie praktisch mindestens 4 GB und für ein ausgelastetes Team 8 GB ein. Der Node-Prozess von Rocket.Chat verwendet etwa 1 bis 1,5 GB. MongoDB beansprucht ungefähr die Hälfte des verbleibenden RAM für seinen WiredTiger-Cache. Auf einem System mit 2 GB konkurrieren beide daher um den Speicher. Der Out-of-Memory-Killer beendet mongod bei jeder realen Auslastung. In den Logs erscheint dann Killed und der Prozess endet mit dem Exit-Code 137. Zwei GB reichen nur aus, um die Software mit einigen Testbenutzern zu evaluieren.

Wie betreibe ich Rocket.Chat hinter HTTPS?

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

Wie sichere ich ein selbst gehostetes Rocket.Chat?

Erstellen Sie mit mongodump einen konsistenten Datenbank-Dump, anstatt das Volume zu kopieren: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Das Archiv enthält Benutzer, Channels, Nachrichten und Einstellungen. Es enthält außerdem hochgeladene Dateien, wenn Sie den Speicher auf GridFS belassen haben. Kopieren Sie das Archiv vom Server weg. Automatisieren Sie die Sicherung nightly mit cron. Führen Sie auf einem Wegwerf-System eine mongorestore durch. So stellen Sie sicher, dass die Wiederherstellung tatsächlich funktioniert.

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

Aktualisieren Sie Rocket.Chat jeweils um eine Major-Version. Beim Start führt Rocket.Chat Migrationen aus und verweigert das Überspringen von Major-Versionen. Lesen Sie vor der Änderung des festgelegten Image-Tags die Versionshinweise der jeweiligen Version. Prüfen Sie mit curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, welche MongoDB-Versionen Ihre Zielversion unterstützt. Aktualisieren Sie MongoDB ebenfalls jeweils um eine Major-Version. Setzen Sie nach jedem Schritt setFeatureCompatibilityVersion mit confirm: true. Erstellen Sie vorher immer eine mongodump.