Door Rocket.Chat zelf hosten met Docker Compose
Installeer Rocket.Chat op uw eigen VPS met Docker Compose. Leer hoe u de vereiste MongoDB replica set configureert, TLS beveiligt en veelvoorkomende fouten in beheer voorkomt.
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 videofuncties, alles op hardware die u huurt en beheert. De applicatie is een enkele container die binnen enkele minuten operationeel is. Alles wat daadwerkelijk misgaat, bevindt zich in de database ernaast; daarom gaat het grootste deel van deze handleiding over MongoDB, en in het bijzonder over de ene 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 u over vertelt
Kies een realistische grootte voor uw server. De ondergrens voor een klein team is 2 vCPU en 4 GB RAM. Het Node.js-proces van Rocket.Chat vereist op zichzelf al ongeveer 1 tot 1,5 GB, en de WiredTiger-cache van MongoDB claimt standaard ongeveer de helft van het resterende RAM-geheugen. Op een VPS met 2 GB 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 geheugen tekort en de out-of-memory killer beëindigt het grootste proces, meestal mongod. De container geeft Killed, Docker start deze opnieuw op en u heeft een chatserver die elke paar minuten uitvalt onder een belasting die hij eigenlijk moeiteloos zou moeten verwerken. 2 GB is voldoende om de software met twee personen te testen; het is geen server voor een team. Begin bij 4 GB en kies voor 8 GB als u tientallen gelijktijdige gebruikers, videogesprekken of een groeiende uploadgeschiedenis verwacht.
U moet ook drie zaken op orde hebben 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. Poort 80 en 443 moeten openstaan in zowel de serverfirewall als de netwerkfirewall van uw provider, wat bij de meeste beheerpanelen een afzonderlijke instelling is. En een schone Ubuntu 24.04 KVM VPS 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. 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-syntax 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-pluginControleer of beide onderdelen aanwezig zijn:
sudo docker version
sudo docker compose versiondocker compose version dat iets als Docker Compose version v2.x afdrukt, is de controle die ertoe doet. Als dit een foutmelding geeft met docker: 'compose' is not a docker command, dan is de plugin niet geïnstalleerd en zult u later tegen verwarrende fouten aanlopen; los dit hier op.
Het compose-bestand: MongoDB als single-node replica set
Dit is het onderdeel waar vaak fouten worden gemaakt, 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 het verbinding maken, falen bij het openen van een change stream en vervolgens in een oneindige herstartlus terechtkomen. De oplossing is niet ingewikkeld: u draait een enkele, normale 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 op 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; laat dit weg en de driver behandelt de server als standalone, ook al is het een replica set, waardoor change streams alsnog falen. MONGO_OPLOG_URL wijst naar de local-database waar de oplog zich bevindt; moderne Rocket.Chat geeft de voorkeur aan change streams, maar dit instellen is onschadelijk en houdt oudere codepaden werkend. De depends_on gebruikt condition: service_healthy, dus Compose wacht tot MongoDB antwoordt op een ping voordat Rocket.Chat wordt gestart; dat is waar de healthcheck voor dient.
Zet voor beide images echte versietags vast: mongo:8.0 en hier een expliciete Rocket.Chat-release zoals 8.5.1. Gebruik nooit :latest. Daarmee wordt een onbewaakte docker pull een onbedoelde upgrade die niet kan worden gemigreerd. Controleer voordat u de versies vastzet welke Rocket.Chat-release momenteel stabiel is en welke MongoDB-versies deze ondersteunt. Rocket.Chat publiceert per release een machinaal leesbaar informatiedocument: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' retourneert voor 8.5.1 compatibleMongoVersions: ["8.0"]. Daarom is mongo:8.0 de enige ondersteunde engine. Het document bevat ook een lts-vlag die aangeeft of de release een long-term-support-build is die het vastzetten waard is voor een server die u liever niet voortdurend beheert. Niet elk project publiceert een versiegebonden image. In dat geval wordt de versie bij de broncode vastgezet: de workouttracker openGym zelf hosten betekent dat u een specifieke git-tag uitcheckt en daaruit bouwt, in plaats van een bewegende branch te volgen.
Initialisatie van de replica set
Start de stack:
sudo docker compose up -dRocket.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 rocketchatDe 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, met een echte naam, gebruikersnaam, e-mailadres en een sterk wachtwoord; dit is het enige account dat bestaat, dus verlies de gegevens niet. Vervolgens de organisatie- en serverinformatie, zoals de naam, sector, omvang, sitenaam en de standaardtaal; dit is cosmetisch, vul het in en ga door. Daarna volgt de keuze die er echt toe doet: registreer deze workspace bij Rocket.Chat Cloud, of kies voor 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. Standalone houdt de server volledig privé en vrij van externe afhankelijkheden, maar pushmeldingen op iOS en Android stoppen met werken. Apple en Google staan namelijk niet toe dat een zelfgebouwde app de pushcertificaten beheert; de officiële apps verlopen via de cloud-gateway. Kies voor standalone als privacy het hoofddoel is en uw gebruikers de web-app gebruiken; kies voor registratie als mobiele pushmeldingen essentieel zijn. U kunt uw keuze later wijzigen onder Admin.
Beveilig de server voordat u anderen uitnodigt
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 op één centrale plek beheerd in plaats van per applicatie.
Bepaal ook waar uploads worden opgeslagen. De standaardopslag voor File Upload is GridFS, wat elke afbeelding en bijlage direct in MongoDB opslaat. Dit is eenvoudig, maar het betekent dat uw database, en elke mongodump die u maakt, onbeperkt groeit naarmate mensen screenshots plakken. 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. Voor een klein team is GridFS prima; 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.gzDit 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.gzKopieer 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 applicatie voert bij het opstarten schema-migraties uit en weigert bewust om meerdere major-versies over te slaan; als u probeert direct van 6.x naar 8.x te gaan, stopt het proces met een migratiefout in plaats van uw data te beschadigen. Wijzig de image-tag naar de nieuwste release van de volgende major-versie, lees de release notes voor 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 bijwerkt, 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 weigert het systeem de actie en krijgt u 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 raakt vol met een MongoServerSelectionError. MongoDB draait, 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 initialisatie heeft uitgevoerd 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, initialiseer de set; als het een lid toont waarvan de name een willekeurige hash is, initialiseer dan opnieuw 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 sterven 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 1 in de command, maar swap vertraagt de volgende OOM onder echte belasting slechts:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfiledocker 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 update de proxy_pass van uw proxy zodat deze overeenkomt.
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 restart-loop belandt met MongoServerSelectionError: Server selection timed out en het opstartproces nooit voltooit.
Hoeveel RAM heeft een zelfgehoste Rocket.Chat nodig?
Houd rekening met 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 MongoDB claimt ruwweg de helft van het resterende RAM voor zijn WiredTiger-cache. Op een machine met 2 GB botsen deze twee en beëindigt de out-of-memory killer het proces mongod bij enige reële belasting, wat in de logs zichtbaar is als Killed en exitcode 137. 2 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 inlogproces 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 het archief van de server af, automatiseer dit dagelijks met cron en oefen een mongorestore op een wegwerpserver 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 weigert major-versies over te slaan. 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 één major-versie per keer en stel setFeatureCompatibilityVersion in met confirm: true na elke stap. Maak altijd eerst een mongodump.