Rocket.Chat zelf hosten met Docker Compose

Wat u bouwt

Een besloten teamchat die volledig uw eigendom is: Rocket.Chat draaiend op uw eigen VPS via Docker Compose, beveiligd met TLS, waarbij elk bericht wordt opgeslagen in een MongoDB-database die u kunt back-uppen en verplaatsen. Rocket.Chat is het volwassen open-source alternatief voor Slack en Teams, met kanalen, directe berichten, threads, het delen van bestanden, en spraak- en videobellen, allemaal op hardware die u huurt en beheert. Het is echter niet de enige geloofwaardige optie; als u nog aan het kiezen bent, zet Vergelijking van Mattermost, Rocket.Chat, Synapse en Zulip ze op een rij op basis van de zaken die later voor problemen kunnen zorgen: RAM, database, mobiele pushberichten, SSO en upgrades. De applicatie is een enkele container die binnen enkele minuten operationeel is. Alles wat daadwerkelijk misgaat, bevindt zich in de database ernaast, dus het grootste deel van deze handleiding gaat over MongoDB, en in het bijzonder over de vereiste die iedereen de eerste keer verrast: Rocket.Chat werkt niet met een standalone MongoDB. Het vereist een replica set, zelfs als die "set" uit slechts één node bestaat.

Vereisten en de RAM-berekening waar niemand over spreekt

Kies de juiste omvang voor uw server. De realistische ondergrens voor een klein team is 2 vCPU en 4 GB RAM. Het Node.js-proces van Rocket.Chat verbruikt zelf ongeveer 1 tot 1,5 GB. De WiredTiger-cache van MongoDB gebruikt standaard de grootste waarde van 50% van (totaal RAM minus 1 GB) of 0,256 GB. Deze standaardinstelling gaat ervan uit dat mongod de machine voor zichzelf heeft: de berekening is gebaseerd op het totale RAM en houdt geen rekening met het geheugen dat Node al in gebruik heeft. Op een systeem met 4 GB RAM komt dit neer op 1,5 GB, en op een systeem met 2 GB RAM op ongeveer 0,5 GB. Dit komt bovenop de heap van Node, het geheugen van mongod buiten de cache en het besturingssysteem. Op een VPS met 2 GB RAM passen beide processen bij het opstarten, maar ze botsen zodra er daadwerkelijk verkeer binnenkomt: MongoDB vergroot de cache, Node vergroot de heap, de kernel komt geheugenpagina's tekort en de out-of-memory killer beëindigt het grootste proces, meestal mongod. De container geeft Killed weer, Docker herstart deze en u heeft een chatserver die elke paar minuten uitvalt onder een belasting die hij gemakkelijk zou moeten aankunnen. 2 GB is voldoende om te testen met twee personen, maar het is geen server voor een team. Begin met 4 GB en kies voor 8 GB als u tientallen gelijktijdige gebruikers, videogesprekken of een groeiende uploadgeschiedenis verwacht. Houd ook rekening met andere taken op de server: het plaatsen van een Notion-stijl AFFiNE-werkruimte op dezelfde VPS voegt vier extra containers toe die strijden om hetzelfde geheugen. Dit RAM-gebruik moet dus bovenop dat van Rocket.Chat komen, niet eruit worden gehaald.

U heeft ook drie zaken nodig voordat u begint. Een domeinnaam met een A-record dat verwijst naar het publieke IP-adres van de VPS; de real-time functies en mobiele clients van Rocket.Chat vereisen een stabiele hostnaam, geen kaal IP-adres. Poorten 80 en 443 moeten openstaan in zowel de server-firewall als de netwerk-firewall van uw provider, wat bij de meeste beheerpanelen een aparte instelling is. Tot slot heeft u een schone Ubuntu 24.04 KVM VPS nodig met root- of sudo-toegang. Als u nog twijfelt of een chatserver de juiste eerste service is om te draaien, zet de gids over wat de moeite waard is om in 2026 zelf te hosten de afwegingen op een rij.

De Docker engine en de Compose-plugin installeren

Gebruik de officiële apt-repository van Docker, niet het docker.io-pakket dat Ubuntu meelevert en niet het verouderde, losse docker-compose Python-binary-bestand. De moderne Compose is een Docker-plugin die u aanroept als docker compose, met een spatie in plaats van een koppelteken. De oude docker-compose v1 is end-of-life en verwerkt de onderstaande healthcheck- en dependency-syntaxis onjuist.

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

Controleer of beide onderdelen aanwezig zijn:

sudo docker version
sudo docker compose version

docker compose version dat een versieregel afdrukt, is de relevante controle. Huidige releases printen Docker Compose version v5.x (v5.6.0, uitgebracht op 2 oktober 2026, was de nieuwste versie per 2026-10-10); een oudere installatie print mogelijk nog v2.x, en Docker ondersteunt beide. Docker beschrijft Compose v5 als functioneel identiek aan v2; het versienummer v5 is gekozen om verwarring met de legacy v2- en v3-compose-bestandsformaten te voorkomen. Beide versies zijn dus geschikt voor deze handleiding. Als er een foutmelding verschijnt met docker: 'compose' is not a docker command, is de plugin niet geïnstalleerd en zult u later tegen onduidelijke fouten aanlopen; los dit hier op.

Het compose-bestand: MongoDB als single-node replica set

Dit is het onderdeel waar mensen de fout in gaan, dus lees dit aandachtig. Rocket.Chat gebruikt MongoDB change streams om nieuwe berichten in real-time naar verbonden clients te pushen, en change streams zijn alleen beschikbaar op een replica set. Als u Rocket.Chat koppelt aan een standaard standalone mongod, zal deze verbinding maken, het openen van een change stream niet lukken en vervolgens in een oneindige herstartlus terechtkomen. De oplossing is niet ingewikkeld: u draait een enkele, standaard MongoDB-container, maar u start deze met --replSet en initialiseert vervolgens een set met één lid.

Maak een werkmap en een compose.yml aan:

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:

Een aantal keuzes hier zijn bewust gemaakt. De Rocket.Chat-poort wordt gepubliceerd op 127.0.0.1:3000, niet 0.0.0.0; de applicatie zelf heeft geen TLS, dus alleen de reverse proxy op dezelfde machine mag deze bereiken. Het binden aan elke interface zou een inlogpagina in platte tekst direct op het openbare internet plaatsen. MongoDB wordt helemaal niet gepubliceerd naar de host; het is alleen bereikbaar via het interne netwerk van Compose onder de naam mongodb, wat exact de hostnaam is die de MONGO_URL gebruikt. MONGO_URL bevat ?replicaSet=rs0, wat de set expliciet benoemt; MongoDB raadt aan dit in te stellen voor consistent gedrag in verschillende drivers. Het weglaten ervan breekt op zichzelf niets: directConnection valt terug op false, dus de driver ontdekt nog steeds de replica set en stuurt operaties naar de primary, mits de set is geïnitieerd met een hostnaam die Rocket.Chat kan resolven, waar de volgende sectie voor zorgt. MONGO_OPLOG_URL wijst naar de local-database waar de oplog zich bevindt; moderne Rocket.Chat geeft de voorkeur aan change streams, maar het instellen ervan is onschadelijk en houdt oudere codepaden werkend. De depends_on gebruikt condition: service_healthy, waardoor Compose wacht tot MongoDB antwoordt op een ping voordat Rocket.Chat wordt gestart; dat is waar de healthcheck voor dient.

Pin echte versietags op beide images, mongo:8.0 en een expliciete Rocket.Chat-release zoals 8.5.1 hier, en gebruik nooit :latest, wat van een onbeheerde docker pull een onbedoelde, niet-migreerbare upgrade maakt. Controleer de huidige stabiele Rocket.Chat-release en de MongoDB-versies die deze ondersteunt voordat u de versie vastzet. Rocket.Chat publiceert per release een machineleesbaar infodocument: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' geeft compatibleMongoVersions: ["8.0"] terug voor 8.5.1, dus mongo:8.0 is de enige ondersteunde engine, plus een lts-vlag die aangeeft of die release een long-term-support build is die het waard is om vast te pinnen voor een server die u liever niet constant in de gaten houdt. Niet elk project publiceert een image met versienummer; in dat geval verplaatst de pin zich naar de bron: self-hosting the openGym workout tracker betekent het uitchecken van een specifieke git-tag en het bouwen vanaf dat punt in plaats van een bewegende branch te volgen.

Initialisatie van de replica set

Start de stack:

sudo docker compose up -d

Rocket.Chat zal direct crashen en Docker zal de container blijven herstarten. Dit is verwacht gedrag, omdat de replica set nog niet bestaat. Maak deze eenmalig handmatig aan:

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

Een correct resultaat is { ok: 1 }. Binnen enkele seconden verkiest de enkele node zichzelf tot primary; bevestig dit met:

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

U hoort PRIMARY te zien. Het belangrijkste detail op deze hele pagina is het host: "mongodb:27017"-argument. Als u een kale rs.initiate() uitvoert zonder ledenlijst, adverteert MongoDB de replica set onder de interne hostnaam van de container, een willekeurige hash zoals a1b2c3d4e5f6. Rocket.Chat, dat verbinding maakt vanuit zijn eigen container, kan die naam niet resolven. Hierdoor faalt de DNS-lookup van de MongoDB-driver en blijft het systeem in een lus loggen met MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Initialiseer altijd met de expliciete servicenaam die overeenkomt met uw MONGO_URL.

Eerste opstart: het proces monitoren

Zodra de set primair is, verbindt Rocket.Chat bij de volgende herstart correct en begint het met de migraties voor de eerste keer opstarten. Volg de logs:

sudo docker compose logs -f rocketchat

De regel waar u op wacht is de opstartbanner:

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

De eerste opstart is traag; de applicatie voert databasemigraties uit en bouwt indexen op. Wacht daarom een minuut of twee voordat u zich zorgen maakt. Als de log in plaats daarvan MongoServerSelectionError: Server selection timed out after 30000 ms herhaalt met een topologiebeschrijving van het type ReplicaSetNoPrimary, dan is de replica set niet geïnitialiseerd. Als de log getaddrinfo ENOTFOUND herhaalt op een willekeurige hash, dan is deze geïnitialiseerd met de verkeerde host. Ga in beide gevallen één stap terug. Zodra u SERVER RUNNING ziet, luistert Rocket.Chat op 127.0.0.1:3000 en is het tijd om een echte hostnaam en TLS ervoor te plaatsen.

Beveilig met TLS

Stel Rocket.Chat nooit bloot via onversleuteld HTTP. Log één keer in via http:// en u heeft uw beheerderswachtwoord aan iedereen op het netwerkpad prijsgegeven. Beëindig TLS in een reverse proxy op dezelfde server en stuur het verkeer door naar 127.0.0.1:3000. Twee zaken zijn hierbij van belang: de proxy moet de WebSocket upgrade-headers doorsturen, omdat Rocket.Chat real-time is en zonder deze headers niet functioneert, en de ROOT_URL van de container moet exact overeenkomen met het publieke HTTPS-adres dat gebruikers in hun browser invoeren.

Begin met een standaard HTTP nginx-serverblok dat de aanvragen doorstuurt naar de applicatie en de upgrade-headers doorgeeft. Sla dit op als /etc/nginx/sites-available/rocketchat, maak een symbolische koppeling naar sites-enabled en herlaad de configuratie:

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;
    }
}

Laat dit voorlopig op poort 80 staan; een blok met listen 443 ssl; zonder certificaat zal de validatie van sudo nginx -t niet doorstaan. Herlaad nginx (sudo nginx -t && sudo systemctl reload nginx) en vraag vervolgens het certificaat aan. De meest efficiënte methode op Ubuntu staat beschreven in Let's Encrypt TLS-certificaten met Certbot en nginx: certbot --nginx herschrijft het bovenstaande blok ter plaatse, voegt listen 443 ssl; en de ssl_certificate-regels toe, configureert een automatische redirect van 80 naar 443 en plant de vernieuwing voor u in. Als u reeds meerdere containers achter één proxy draait, is Traefik met automatische TLS voor meerdere Docker-applicaties een nettere optie; voeg router- en service-labels toe aan de rocketchat-service en Traefik zal het certificaat voor u aanvragen en vernieuwen, zonder dat er een nginx-configuratieblok nodig is. Stel in beide gevallen ROOT_URL in op https://chat.example.com in compose.yml en voer sudo docker compose up -d opnieuw uit zodat de container de wijziging verwerkt. Indien u wilt dat de server alleen bereikbaar is vanuit uw eigen netwerk in plaats van via het publieke internet, plaats deze dan achter een zelfgehoste WireGuard VPN op de VPS en bind de proxy aan het tunneladres.

De installatiewizard voor de eerste keer opstarten

Navigeer naar https://chat.example.com en Rocket.Chat leidt u door een korte wizard. Eerst het admin-account: een echte naam, gebruikersnaam, e-mailadres en een sterk wachtwoord; dit is het enige account dat bestaat, dus verlies de gegevens niet. Vervolgens organisatie- en serverinformatie: naam, sector, omvang, de sitenaam en de standaardtaal; dit is cosmetisch, vul het in en ga verder. Daarna de keuze die er echt toe doet: registreer deze workspace bij Rocket.Chat Cloud, of houd deze standalone.

Registratie maakt mobiele pushmeldingen via de gateway van Rocket.Chat en de add-on marketplace mogelijk, ten koste van een afhankelijkheid van het control-plane van de cloud van Rocket.Chat; pushmeldingen die via de gateway worden verzonden, tellen ook mee voor de maandelijkse limiet van uw workspace. Standalone houdt de server volledig privé en vrij van externe afhankelijkheden, maar de officiële iOS- en Android-apps ontvangen geen pushmeldingen meer. Volgens de documentatie van Rocket.Chat werken deze apps namelijk alleen met de cloud-gateway, en de gateway werkt niet op een niet-geregistreerde workspace. De oplossing hiervoor is een eigen white-labeled build van de mobiele app: schakel de gateway uit in de Push-instellingen, voer uw eigen APNs-certificaten en Firebase Cloud Messaging-inloggegevens in, en laat uw gebruikers uw eigen app installeren in plaats van de officiële versie. Kies voor standalone als privacy het hoofddoel is en uw gebruikers de web-app gebruiken, of als u bereid bent uw eigen mobiele app uit te brengen; kies voor registratie als pushmeldingen op de officiële apps een vereiste zijn. U kunt uw keuze later altijd wijzigen onder Admin.

Beveilig de server voordat u gebruikers toelaat

Rocket.Chat wordt standaard geleverd met open registratie ingeschakeld. Het registratieformulier staat standaard op Public, waardoor iedereen die de URL vindt een account kan aanmaken. Op een publieke hostnaam is dit een open deur. Ga naar Admin → Settings → Accounts → Registration en zet Registration Form op Disabled, zodat u accounts handmatig of via een uitnodigingslink aanmaakt, of op Secret URL. Schakel terwijl u daar bent Allow Anonymous Read en Allow Anonymous Write uit, tenzij u specifiek een publiek kanaal met alleen-lezen toegang wilt. Als het handmatig aanmaken van elk account te veel werk is en dit niet de enige service is waar uw team op inlogt, koppel de OAuth-login van Rocket.Chat dan aan een zelfgehoste Authentik SSO-server. Zo worden nieuwe en vertrekkende gebruikers centraal beheerd in plaats van per applicatie.

Bepaal ook waar uploads worden opgeslagen. De standaardopslag voor File Upload is GridFS, waarbij elke afbeelding en bijlage in MongoDB zelf wordt opgeslagen. Dit is eenvoudig, maar het betekent dat uw database, en elke mongodump die u maakt, onbeperkt groeit naarmate mensen screenshots delen. Onder Admin → Settings → File Upload kunt u de opslag wijzigen naar het lokale bestandssysteem of een S3-compatibele bucket, en een redelijke maximale bestandsgrootte instellen. Als uw team volledige fotobibliotheken uitwisselt in plaats van incidentele screenshots, horen deze thuis op een speciale fotoserver in plaats van in een chatdatabase. PhotoPrism en Immich vergeleken weegt het RAM-verbruik van beide opties af tegen de benodigde back-upcommando's. Voor een klein team volstaat GridFS; houd er alleen rekening mee dat uw back-ups na verloop van tijd zwaarder worden.

Backups maken met mongodump

Al uw data bevindt zich in het mongodb_data volume. Kopieer het volume niet zomaar terwijl de database actief is; maak een consistente dump met mongodump en stream deze naar een bestand op de host:

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

Dit enkele gzipped archief bevat uw volledige werkomgeving: gebruikers, kanalen, berichten, instellingen en, indien u uploads op GridFS heeft laten staan, ook de bestanden. Als u uploads heeft verplaatst naar het bestandssysteem of S3, maak dan een afzonderlijke back-up van die opslag. Herstel de data op een nieuwe stack door eerst de replica set te initialiseren en vervolgens:

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

Kopieer het archief buiten de server, naar object storage, een andere server of een willekeurige locatie waar het uitvallen van de VPS de back-up niet onbereikbaar maakt. Voer de dump dagelijks uit via cron. Een back-up die u nooit heeft hersteld is slechts een hoop, geen back-up; oefen het herstelproces eenmaal op een tijdelijke VPS zodat u zeker weet dat het werkt voordat u het daadwerkelijk nodig heeft.

Upgrades: pin tags, lees de opmerkingen, respecteer de Mongo-matrix

Twee regels houden upgrades voorspelbaar. Ten eerste: upgrade Rocket.Chat één major-versie per keer. De software voert bij het opstarten schema-migraties uit en de documentatie van Rocket.Chat schrijft voor om altijd opeenvolgend tussen major-versies te upgraden. Het overslaan van major-versies kan leiden tot ernstige compatibiliteitsproblemen. Vertrouw er niet op dat de software dit blokkeert: de documentatie garandeert niet dat een sprong van 6.x direct naar 8.x veilig wordt geweigerd. Een migratie die halverwege faalt, laat de lock actief en vereist handmatig herstel. Wijzig de image-tag naar de nieuwste release van de volgende major-versie, lees de opmerkingen bij die release over ingrijpende wijzigingen, voer docker compose up -d uit en monitor de logs totdat de migratie is voltooid voordat u verdergaat. Ten tweede: respecteer de MongoDB-supportmatrix. Elke Rocket.Chat-release ondersteunt een specifieke set MongoDB-versies en curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions geeft aan welke dit zijn. Wanneer u MongoDB upgradet, bijvoorbeeld van 7.0 naar 8.0, doe dit dan één major-versie per keer en stel na elke stap de feature-compatibility-versie in. Op MongoDB 8.0 vereist dit commando een expliciete confirm: true, anders wordt het geweigerd met een melding om het commando opnieuw uit te voeren met de bevestigingsvlag:

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

Maak een mongodump voordat u een van beide componenten upgradet. Dat is uw volledige verzekering.

Foutmodi, met de exacte strings

Rocket.Chat blijft herstarten direct na docker compose up, en docker compose logs rocketchat loopt vol met een MongoServerSelectionError. MongoDB draait wel, maar de driver kan geen primary selecteren, en de exacte string geeft aan welke fout u heeft gemaakt. Server selection timed out after 30000 ms met een topology type van ReplicaSetNoPrimary betekent dat u rs.initiate() nooit heeft uitgevoerd; de set heeft nog geen configuratie. getaddrinfo ENOTFOUND gevolgd door een willekeurige hash betekent dat u de set heeft geïnitieerd zonder de expliciete host: "mongodb:27017", waardoor MongoDB een onoplosbare container-hostname heeft geadverteerd. Diagnoseer dit met sudo docker compose exec mongodb mongosh --eval 'rs.status()': als dit de fout MongoServerError: no replset config has been received geeft, initieer dan de set; als het een lid toont waarvan de name een willekeurige hash is, her-initieer dan met de servicenaam.

De web-UI laadt, maar het inloggen blijft oneindig laden en voltooit nooit. Open de browserconsole en u zult WebSocket connection to 'wss://chat.example.com/websocket' failed zien. Dit is bijna altijd een ROOT_URL-mismatch of een proxy die de upgrade-headers niet doorstuurt. Bevestig dat ROOT_URL gelijk is aan het exacte publieke adres inclusief https://, en dat uw nginx location-blok Upgrade en Connection "upgrade" instelt met proxy_http_version 1.1. Wijzig een van beide en voer docker compose up -d opnieuw uit.

Een container blijft stoppen en docker compose ps toont dat deze Restarting. docker compose logs breekt halverwege de regel af en sudo dmesg | tail toont Out of memory: Killed process 12345 (mongod) van de oom-killer; de exitcode is 137. De server heeft onvoldoende RAM. De echte oplossing is een grotere VPS, minimaal 4 GB. Voeg als tijdelijke oplossing swap toe en beperk de cache van MongoDB met --wiredTigerCacheSizeGB in de command, ingesteld onder de standaardwaarde in plaats van erboven, bijvoorbeeld 1 op een 4 GB-server (standaard 1.5) of 0.3 op een 2 GB-server (standaard ongeveer 0.5), maar swap vertraagt de volgende OOM onder echte belasting slechts:

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

docker compose up faalt met Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Iets bezet al poort 3000, vaak een eerdere Rocket.Chat-container die niet correct is gestopt, of een andere applicatie. Zoek dit proces met sudo ss -ltnp | grep :3000, stop dat proces of die container, of wijzig de host-zijde van de mapping naar 127.0.0.1:3001:3000 en werk de proxy_pass van uw proxy bij om dit te matchen.

FAQ

Heeft Rocket.Chat echt een MongoDB replica set nodig?

Ja, zelfs voor een enkele server met één databasenode. Rocket.Chat verstuurt berichten in real-time met behulp van MongoDB change streams, en change streams zijn een functie die alleen beschikbaar is in een replica set; een standalone mongod kan deze niet openen. U heeft geen meerdere machines nodig; u draait één MongoDB-container die is gestart met --replSet rs0 en initialiseert een set met één lid via rs.initiate(). Slaat u deze stap over, dan vindt de driver nooit een primary, waardoor Rocket.Chat in een herstart-loop belandt met MongoServerSelectionError: Server selection timed out en nooit volledig opstart.

Hoeveel RAM heeft een zelfgehoste Rocket.Chat nodig?

Reken op 4 GB als praktisch minimum en 8 GB voor een actief team. Het Node-proces van Rocket.Chat gebruikt ongeveer 1 tot 1,5 GB, en de standaard WiredTiger-cache van MongoDB beslaat de helft van (totaal RAM minus 1 GB), waarbij ervan wordt uitgegaan dat er niets anders op de machine draait. Op een machine met 2 GB botsen die cache, de heap van Node en de overhead van mongod zelf, waardoor de out-of-memory killer bij enige reële belasting mongod beëindigt, wat in de logs zichtbaar is als Killed en exitcode 137. Twee GB is alleen voldoende om de software te evalueren met een paar testgebruikers.

Hoe plaats ik Rocket.Chat achter HTTPS?

Draai een reverse proxy op dezelfde VPS die TLS-termination afhandelt en doorstuurt naar 127.0.0.1:3000, en stel de ROOT_URL van de container in op uw publieke https://-adres. De proxy moet de WebSocket upgrade-headers doorsturen, anders blijft het inloggen hangen. Certbot met nginx is de eenvoudigste opzet voor één applicatie; Traefik is overzichtelijker als u meerdere containers achter één proxy draait en automatisch certificaatbeheer wenst.

Hoe maak ik een back-up van een zelfgehoste Rocket.Chat?

Maak een consistente database-dump met mongodump in plaats van het volume te kopiëren: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Dat archief bevat gebruikers, kanalen, berichten en instellingen, plus geüploade bestanden als u de opslag op GridFS heeft gelaten. Kopieer dit van de server af, automatiseer het dagelijks met cron en oefen een mongorestore op een testomgeving zodat u zeker weet dat het herstel daadwerkelijk werkt.

Hoe upgrade ik Rocket.Chat zonder MongoDB te beschadigen?

Upgrade Rocket.Chat één major-versie per keer; het voert migraties uit bij het opstarten en de documentatie waarschuwt dat het overslaan van major-versies ernstige compatibiliteitsproblemen kan veroorzaken. Lees de release notes van elke versie voordat u de vastgezette image-tag aanpast. Controleer welke MongoDB-versies uw doelversie ondersteunt met curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions, en wanneer u MongoDB verplaatst, doe dit dan stap voor stap per major-versie en stel setFeatureCompatibilityVersion in met confirm: true na elke stap. Maak altijd eerst een mongodump.