Rocket.Chat mit Docker Compose selbst hosten

Was Sie aufbauen

Ein privater Team-Chat in Ihrem Eigenbesitz: Rocket.Chat, betrieben auf Ihrem eigenen VPS unter Docker Compose, abgesichert durch TLS. Alle Nachrichten werden in einer MongoDB-Datenbank gespeichert, die Sie sichern und verschieben können. Rocket.Chat ist eine ausgereifte Open-Source-Alternative zu Slack und Teams — mit Kanälen, Direktnachrichten, Threads, Dateifreigabe sowie Sprach- und Videofunktionen, alles auf Hardware, die Sie mieten und kontrollieren. Die Anwendung ist ein einzelner Container, der in wenigen Minuten bereitsteht. Alle kritischen Daten liegen in der dazugehörigen Datenbank. Daher konzentriert sich dieser Leitfaden primär auf MongoDB, insbesondere auf eine Anforderung, die beim ersten Mal oft überrascht: Rocket.Chat funktioniert nicht mit einer Standalone-MongoDB. Es wird ein Replica Set benötigt, selbst wenn dieses „Set“ nur aus einem einzelnen Knoten besteht.

Voraussetzungen und die RAM-Berechnung

Wählen Sie die Hardware-Ressourcen 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 allein etwa 1 bis 1,5 GB. Der WiredTiger-Cache von MongoDB belegt standardmäßig etwa die Hälfte des verbleibenden RAMs. Auf einem 2 GB VPS starten beide Prozesse zwar, kollidieren aber sofort bei tatsächlichem Datenverkehr: Der MongoDB-Cache wächst, der Node-Heap wächst, dem Kernel gehen die Pages aus, und der Out-of-Memory-Killer beendet den größten Prozess – meistens mongod. Der Container gibt Killed aus, Docker startet ihn neu, und der Chat-Server stürzt alle paar Minuten unter einer Last ab, die er eigentlich bewältigen sollte. 2 GB sind für Tests mit zwei Personen ausreichend, aber nicht für einen Team-Server. Beginnen Sie mit 4 GB. Planen Sie 8 GB ein, wenn Sie dutzende gleichzeitige Benutzer, Videocalls oder eine wachsende Upload-Historie erwarten.

Bevor Sie beginnen, müssen zudem drei Bedingungen erfüllt sein. Ein Domainname mit einem A-Record, der auf die öffentliche IP des VPS zeigt – die Echtzeit-Funktionen und mobilen Clients von Rocket.Chat benötigen einen stabilen Hostnamen statt einer nackten IP. Die Ports 80 und 443 müssen offen sein, sowohl in der Server-Firewall als auch in der Netzwerk-Firewall Ihres Providers (diese ist in den meisten Panels eine separate Einstellung). Und ein frisches Ubuntu 24.04 KVM VPS mit root- oder sudo-Rechten. Falls Sie noch entscheiden, ob ein Chat-Server der richtige erste Dienst ist, beschreibt der Leitfaden zu Selbsthostings im Jahr 2026 die jeweiligen Vor- und Nachteile.

Install the Docker engine and the Compose plugin

Verwenden Sie das eigene apt-Repository von Docker. Nutzen Sie nicht das von Ubuntu bereitgestellte docker.io-Paket und nicht das veraltete, eigenständige docker-compose Python-Binary. Das moderne Compose ist ein Docker-Plugin, das als docker compose aufgerufen wird – mit einem Leerzeichen statt eines Bindestrichs. Die alte Version docker-compose v1 ist am Ende ihres Lebenszyklus (end-of-life) und verarbeitet die unten aufgeführte Healthcheck- und Dependency-Syntax 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

Überprüfen Sie, ob beide Komponenten vorhanden sind:

sudo docker version
sudo docker compose version

Die Ausgabe von docker compose version sollte etwa Docker Compose version v2.x lauten; dies ist die relevante Prüfung. 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 an dieser Stelle.

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

Dies ist der Teil, der häufig falsch konfiguriert wird; lesen Sie ihn daher sorgfältig. Rocket.Chat nutzt MongoDB change streams, um neue Nachrichten in Echtzeit an verbundene Clients zu senden. Change streams sind nur in einem Replica Set verfügbar. Wenn Sie Rocket.Chat auf einen einfachen Standalone mongod verweisen, wird die Verbindung zwar hergestellt, aber das Öffnen eines change streams schlägt fehl, was zu einer Endlosschleife beim Neustart führt. Die Lösung ist einfach: Sie nutzen einen gewöhnlichen MongoDB-Container, starten diesen jedoch mit --replSet und initialisieren anschließend ein One-Member-Set.

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 gewählt. Der Rocket.Chat-Port wird auf 127.0.0.1:3000 veröffentlicht, nicht auf 0.0.0.0 — die App selbst besitzt kein TLS, daher sollte nur der Reverse Proxy auf demselben Host darauf zugreifen; eine Bindung an alle Interfaces würde eine Login-Seite im Klartext direkt ins öffentliche Internet stellen. MongoDB wird überhaupt nicht an den Host veröffentlicht; es ist nur über das interne Netzwerk von Compose unter dem Namen mongodb erreichbar, was exakt dem Hostnamen entspricht, den der MONGO_URL verwendet. MONGO_URL enthält ?replicaSet=rs0 — lassen Sie dies weg, behandelt der Driver den Server als Standalone, obwohl es ein Replica Set ist, und change streams schlagen weiterhin fehl. MONGO_OPLOG_URL verweist auf die local-Datenbank, in der der oplog liegt; modernes Rocket.Chat bevorzugt change streams, aber diese Einstellung ist unbedenklich und stellt die Kompatibilität mit älteren Code-Pfaden sicher. Die depends_on nutzt condition: service_healthy, sodass Compose wartet, bis MongoDB auf einen ping antwortet, bevor Rocket.Chat gestartet wird — genau hierfür ist der Healthcheck gedacht.

Verwenden Sie feste Versions-Tags für beide Images — mongo:8.0 und eine explizite Rocket.Chat-Version wie 8.5.1 hier — und verwenden Sie niemals :latest, da dies ein automatisches docker pull in ein versehentliches, nicht migrierbares Upgrade verwandelt. Prüfen Sie die aktuelle stabile Rocket.Chat-Version und die unterstützten MongoDB-Versionen, bevor Sie die Tags festlegen. Rocket.Chat veröffentlicht pro Release ein maschinenlesbares Informationsdokument: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' liefert compatibleMongoVersions: ["8.0"] für 8.5.1, somit ist mongo:8.0 die einzige unterstützte Engine, ergänzt durch ein lts-Flag, das angibt, ob das Release eine Long-Term-Support-Version ist, die sich für einen wartungsarmen Betrieb eignet.

Initialisieren Sie das Replica Set

Starten Sie den Stack:

sudo docker compose up -d

Rocket.Chat wird sofort abstürzen und Docker wird den Neustart fortsetzen — das ist erwartet, da das Replica Set noch nicht existiert. Erstellen Sie es einmal manuell:

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

Ein korrektes Ergebnis ist { ok: 1 }. Innerhalb weniger Sekunden wählt der einzelne Knoten sich selbst zum Primary; bestätigen Sie dies mit:

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

Das Ergebnis sollte PRIMARY sein. Das wichtigste Detail auf dieser Seite ist das Argument host: "mongodb:27017". Wenn Sie einen einfachen rs.initiate() ohne Mitgliederliste ausführen, bewirbt MongoDB das Replica Set unter dem internen Hostnamen des Containers — ein zufälliger Hash wie a1b2c3d4e5f6. Rocket.Chat kann diesen Namen aus seinem eigenen Container heraus nicht auflösen. Der MongoDB-Treiber schlägt daher bei der DNS-Auflösung fehl und schreibt fortlaufend MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 in das Log. Initialisieren Sie das Set immer mit dem expliziten Service-Namen, der Ihrem MONGO_URL entspricht.

Erster Bootvorgang: Überwachung des Starts

Sobald das Set als Primary konfiguriert ist, erfolgt der nächste Neustart von Rocket.Chat fehlerfrei und startet die Migrationsprozesse für die Erstinstallation. Überprüfen Sie die Logs:

sudo docker compose logs -f rocketchat

Die relevante Zeile ist das Startup-Banner:

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

Der erste Bootvorgang dauert lange, da die App Datenbank-Migrationen durchführt und Indizes erstellt. Warten Sie ein bis zwei Minuten ab. Wenn das Log stattdessen MongoServerSelectionError: Server selection timed out after 30000 ms mit einer Topologie-Beschreibung vom Typ ReplicaSetNoPrimary wiederholt, wurde das Replica Set nicht initialisiert. Wenn getaddrinfo ENOTFOUND mit einem zufälligen Hash wiederholt wird, erfolgte die Initialisierung mit einem falschen Host. In beiden Fällen müssen Sie den vorherigen Schritt wiederholen. Sobald SERVER RUNNING erscheint, lauscht Rocket.Chat auf 127.0.0.1:3000. Es ist nun an der Zeit, einen echten Hostnamen und TLS einzurichten.

Nutzen Sie TLS

Exponieren Sie Rocket.Chat niemals über unverschlüsseltes HTTP. Wenn Sie sich einmal über http:// anmelden, geben Sie Ihr Admin-Passwort an jeden Akteur auf dem Netzwerkpfad weiter. Terminieren Sie TLS in einem Reverse Proxy auf demselben Host und leiten Sie die Anfragen an 127.0.0.1:3000 weiter. Zwei Aspekte sind wichtig: Der Proxy muss die WebSocket-Upgrade-Header weiterleiten, da Rocket.Chat auf Echtzeit basiert und ohne diese nicht funktioniert. Zudem muss die ROOT_URL des Containers exakt mit der öffentlichen HTTPS-Adresse übereinstimmen, die Benutzer eingeben.

Beginnen Sie mit einem einfachen HTTP nginx Server-Block, der auf die App proxyt und die Upgrade-Header weiterleitet. Speichern Sie diesen als /etc/nginx/sites-available/rocketchat, erstellen Sie einen symbolischen Link nach sites-enabled und laden Sie die Konfiguration 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 Dienst vorerst auf Port 80 laufen — ein Block mit listen 443 ssl; ohne Zertifikat wird sudo nginx -t nicht bestehen. Laden Sie nginx neu (sudo nginx -t && sudo systemctl reload nginx) und fordern Sie anschließend das Zertifikat an. Der einfachste Weg unter Ubuntu ist Let's Encrypt TLS-Zertifikate mit Certbot und nginx: certbot --nginx schreibt den obigen Block um, fügt listen 443 ssl;, die ssl_certificate Zeilen und eine automatische 80-zu-443-Weiterleitung hinzu und plant die Erneuerung für Sie. Falls Sie bereits mehrere Container hinter einem Proxy betreiben, ist Traefik mit automatischem TLS für viele Docker-Apps die sauberere Option — fügen Sie dem rocketchat Service Router- und Service-Labels hinzu. Traefik übernimmt die Anfragen und die Zertifikatserneuerung ohne nginx-Block. In beiden Fällen müssen Sie ROOT_URL in compose.yml auf https://chat.example.com setzen und sudo docker compose up -d erneut ausführen, damit der Container die Änderung übernimmt. Wenn der Server nur aus Ihrem internen Netzwerk statt aus dem öffentlichen Internet erreichbar sein soll, schalten Sie einen selbst gehosteten WireGuard VPN auf dem VPS vor und binden Sie den Proxy an die Tunnel-Adresse.

Der Einrichtungsassistent beim ersten Start

Navigieren Sie zu https://chat.example.com und Rocket.Chat führt Sie durch einen kurzen Assistenten. Zuerst erstellen Sie das Admin-Konto – Vorname, Benutzername, E-Mail-Adresse und ein starkes Passwort; dies ist das einzige Konto, das existiert. Geben Sie es nicht an andere weiter. Als Nächstes folgen Organisation und Server-Infos – Name, Branche, Größe, Website-Name und Standardsprache; diese Angaben sind rein optisch und können einfach ausgefüllt werden. Danach folgt die entscheidende Wahl: Diesen Workspace bei Rocket.Chat Cloud registrieren oder im Standalone-Modus betreiben.

Eine Registrierung ermöglicht mobile Push-Benachrichtigungen über das Rocket.Chat-Gateway und den Add-on-Marktplatz. Dies erfordert jedoch eine Verbindung zur Control-Plane von Rocket.Chat Cloud. Im Standalone-Modus bleibt der Server vollständig privat und unabhängig. Allerdings funktionieren dann keine Push-Benachrichtigungen für iOS und Android, da Apple und Google es nicht erlauben, dass eine selbst erstellte App die Push-Zertifikate hält – die offiziellen Apps leiten die Anfragen über das Cloud-Gateway. Wählen Sie Standalone, wenn der Datenschutz oberste Priorität hat und Ihre Benutzer die Web-App nutzen. Wählen Sie die Registrierung, wenn mobile Push-Benachrichtigungen zwingend erforderlich sind. Sie können diese Entscheidung später unter Admin ändern.

Schützen Sie das System vor der Einladung von Benutzern

Rocket.Chat wird standardmäßig mit open registration on ausgeliefert. Das Registration Form ist auf Public eingestellt. Dadurch kann jeder, der die URL findet, ein Konto erstellen. Auf einem öffentlichen Hostnamen stellt dies ein Sicherheitsrisiko dar. Gehen Sie zu Admin → Settings → Accounts → Registration und stellen Sie das Registration Form auf Disabled, um Konten manuell oder per Einladungslink zu erstellen, oder auf Secret URL. Deaktivieren Sie zudem Allow Anonymous Read und Allow Anonymous Write, es sei denn, Sie benötigen explizit einen öffentlichen Read-only-Kanal.

Legen Sie zudem den Speicherort für Uploads fest. Der Standard-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 – durch Screenshots unbegrenzt anwächst. Unter Admin → Settings → File Upload können Sie den Speicher auf das lokale Dateisystem oder einen S3-kompatiblen Bucket umstellen und eine angemessene maximale Dateigröße festlegen. Für kleine Teams ist GridFS ausreichend; beachten Sie jedoch, dass Ihre Backups mit der Zeit größer werden.

Backups mit mongodump

Alle Daten befinden sich im mongodb_data Volume. Kopieren Sie das Volume nicht einfach, während die Datenbank läuft. Erstellen Sie stattdessen einen konsistenten Dump mit mongodump, der in eine Datei auf dem Host gestreamt wird:

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

Dieses einzelne gzipped Archiv enthält Ihren gesamten Workspace: Benutzer, Kanäle, Nachrichten, Einstellungen und – falls Uploads auf GridFS gespeichert wurden – auch die Dateien. Falls Sie Uploads auf das Filesystem oder S3 verschoben haben, sichern Sie diesen Speicher separat. Stellen Sie die Daten auf einem neuen Stack wieder her, indem Sie zuerst das Replica Set initialisieren, und führen Sie dann aus:

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

Kopieren Sie das Archiv vom Server weg – auf Object Storage, einen anderen Server oder an einen Ort, der nicht verloren geht, wenn der VPS ausfällt – und führen Sie den Dump jede Nacht per cron aus. Ein Backup, das noch nie wiederhergestellt wurde, ist eine Hoffnung, kein Backup. Üben Sie die Wiederherstellung einmal auf einem Test-VPS, um sicherzustellen, dass sie funktioniert, bevor Sie sie im Ernstfall benötigen.

Upgrades: Tags fixieren, Release Notes lesen, MongoDB-Matrix beachten

Zwei Regeln sorgen für reibungslose Upgrades. Erstens: Upgraden Sie Rocket.Chat immer nur um eine Major-Version. Das System führt beim Start Schema-Migrationen durch und verhindert Sprünge zwischen Major-Versionen. Ein direkter Sprung von 6.x auf 8.x führt zu einem Migrationsfehler, um Datenkorruption zu vermeiden. Ändern Sie das Image-Tag auf das neueste Release der nächsten Major-Version. Lesen Sie die Release Notes auf Breaking Changes. Führen Sie docker compose up -d aus und warten Sie, bis die Migration in den Logs abgeschlossen ist. Zweitens: Beachten Sie die MongoDB-Support-Matrix. Jedes Rocket.Chat-Release unterstützt eine spezifische Auswahl an MongoDB-Versionen; curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions gibt Aufschluss darüber. Wenn Sie MongoDB aktualisieren – zum Beispiel von 7.0 auf 8.0 – gehen Sie schrittweise vor. Setzen Sie nach jedem Major-Schritt die Feature-Compatibility-Version. Unter MongoDB 8.0 erfordert dieser Befehl ein explizites confirm: true. Andernfalls erscheint eine Fehlermeldung mit dem Hinweis, 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 einzige Absicherung.

Fehlerzustände und die exakten Fehlermeldungen

Rocket.Chat startet direkt nach docker compose up in einer Neustartschleife, und docker compose logs rocketchat füllt sich mit einem MongoServerSelectionError. MongoDB läuft, aber der Driver kann keinen Primary auswählen. Die exakte Fehlermeldung zeigt den Fehler an. Server selection timed out after 30000 ms mit dem Topology-Typ ReplicaSetNoPrimary bedeutet, dass rs.initiate() nicht ausgeführt wurde – das Set hat noch keine Konfiguration. getaddrinfo ENOTFOUND gefolgt von einem zufälligen Hash bedeutet, dass die Initialisierung ohne das explizite host: "mongodb:27017" erfolgt ist; MongoDB hat einen nicht auflösbaren Container-Hostname gemeldet. Diagnostizieren Sie dies mit sudo docker compose exec mongodb mongosh --eval 'rs.status()': Wenn der Fehler MongoServerError: no replset config has been received auftritt, initialisieren Sie das Set; wenn ein Member mit einem name als zufälligem Hash angezeigt wird, führen Sie die Initialisierung mit dem Service-Namen erneut aus.

Die Web-UI lädt, aber der Login-Vorgang dreht sich endlos und schließt nie ab. Öffnen Sie die Browser-Konsole; dort sehen Sie WebSocket connection to 'wss://chat.example.com/websocket' failed. Dies liegt fast immer an einem ROOT_URL-Mismatch oder einem Proxy, der die Upgrade-Header nicht weiterleitet. Prüfen Sie, ob ROOT_URL der exakten öffentlichen Adresse inklusive https:// entspricht und ob Ihr nginx location-Block Upgrade und Connection "upgrade" mit proxy_http_version 1.1 setzt. Ändern Sie eine dieser Einstellungen und führen Sie docker compose up -d erneut aus.

Ein Container stürzt ständig ab und docker compose ps zeigt an, dass Restarting vorliegt. 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 hat zu wenig RAM. Die dauerhafte Lösung ist ein größerer VPS – mindestens 4 GB. Als Übergangslösung können Sie Swap hinzufügen und den MongoDB-Cache mit --wiredTigerCacheSizeGB 1 in der command begrenzen, aber Swap verzögert nur den nächsten OOM unter realer Last:

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 Prozess belegt bereits Port 3000 – oft ein vorheriger Rocket.Chat-Container, der nicht sauber gestoppt wurde, oder eine andere Anwendung. Finden Sie den Prozess mit sudo ss -ltnp | grep :3000, stoppen Sie diesen Prozess oder Container, oder ändern Sie die Host-Seite des Mappings auf 127.0.0.1:3001:3000 und passen Sie den proxy_pass Ihres Proxys entsprechend an.

FAQ

Benötigt Rocket.Chat zwingend ein MongoDB replica set?

Ja, auch bei einem einzelnen Server mit nur einem Datenbank-Knoten. Rocket.Chat überträgt Nachrichten in Echtzeit über MongoDB change streams. Diese Funktion ist nur in einem replica set verfügbar; ein standalone mongod kann keine change streams öffnen. Sie benötigen keine mehreren Maschinen; Sie können einen MongoDB-Container mit --replSet rs0 starten und ein eingliedriges Set mit rs.initiate() initialisieren. Wenn Sie diesen Schritt überspringen, findet der Driver keinen Primary. Rocket.Chat startet dann in einer Endlosschleife mit MongoServerSelectionError: Server selection timed out und der Bootvorgang schließt nicht 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 nutzt etwa 1 bis 1,5 GB. MongoDB beansprucht etwa die Hälfte des verbleibenden RAM für den WiredTiger cache. Auf einem 2 GB System kommt es zu Konflikten, und der out-of-memory killer beendet mongod unter realer Last. Dies führt zu Killed in den Logs und dem Exit-Code 137. 2 GB reichen nur aus, um die Software mit wenigen Test-Usern zu evaluieren.

Wie setze ich Rocket.Chat hinter HTTPS?

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

Wie erstelle ich ein Backup für ein selbst gehostetes Rocket.Chat?

Erstellen Sie einen konsistenten Datenbank-Dump mit mongodump, anstatt das Volume 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 der Speicher auf GridFS konfiguriert ist. Kopieren Sie das Backup vom Server weg, automatisieren Sie es nächtlich mit cron und testen Sie eine mongorestore auf einem Testsystem, um sicherzustellen, dass die Wiederherstellung funktioniert.

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

Aktualisieren Sie Rocket.Chat immer nur um eine Major-Version – das System führt beim Booten Migrationen durch und erlaubt keine Sprünge zwischen Major-Versionen. Lesen Sie die Release Notes jeder Version, bevor Sie das Image-Tag anpassen. 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 Schritt für Schritt eine Major-Version aufwärts und setzen Sie nach jedem Schritt setFeatureCompatibilityVersion mit confirm: true. Erstellen Sie immer zuerst ein mongodump.