Auto-héberger Rocket.Chat avec Docker Compose

Ce que vous allez mettre en place

Un chat d’équipe privé que vous contrôlez entièrement : Rocket.Chat s’exécute sur votre propre VPS avec Docker Compose, derrière une terminaison TLS, et chaque message est stocké dans une base MongoDB que vous pouvez sauvegarder et déplacer. Rocket.Chat est une alternative open source éprouvée à Slack et Teams. Elle fournit des canaux, des messages directs, des fils de discussion, le partage de fichiers, ainsi que les appels audio et vidéo, le tout sur une infrastructure que vous louez et contrôlez. Ce n’est toutefois pas la seule option sérieuse. Si vous êtes encore en phase de sélection, Mattermost, Rocket.Chat, Synapse et Zulip comparés les confronte sur les points qui posent problème plus tard : RAM, base de données, notifications push mobiles, SSO et mises à niveau. L’application tient dans un seul conteneur et démarre en quelques minutes. Les problèmes réels viennent de la base de données qui l’accompagne. C’est pourquoi ce guide porte principalement sur MongoDB, et en particulier sur la seule exigence qui surprend tout le monde la première fois : Rocket.Chat ne fonctionne pas avec une instance MongoDB autonome. Il a besoin d’un replica set, même si cet « ensemble » ne comporte qu’un seul nœud.

Prérequis et calcul de la RAM dont personne ne parle

Dimensionnez honnêtement la machine. Pour une petite équipe, le minimum réaliste est de 2 vCPU et 4 GB de RAM. Le processus Node.js de Rocket.Chat utilise à lui seul environ 1 à 1.5 GB, tandis que le cache WiredTiger de MongoDB est par défaut égal à la plus grande valeur entre 50 % de (la RAM totale moins 1 GB) et 0.256 GB. Cette valeur par défaut suppose que mongod dispose de toute la machine : elle est calculée à partir de la RAM totale et ne tient pas compte de la mémoire déjà utilisée par Node. Elle atteint donc 1.5 GB sur une machine de 4 GB et environ 0.5 GB sur une machine de 2 GB, en plus du heap de Node, de la mémoire utilisée par mongod en dehors du cache et du système d’exploitation. Sur un VPS de 2 GB, les deux processus démarrent sans problème, puis entrent en conflit dès que le trafic réel arrive : MongoDB augmente son cache, Node augmente son heap, le kernel manque de pages et l’out-of-memory killer termine le processus le plus volumineux, généralement mongod. Le conteneur affiche Killed, Docker le redémarre et vous obtenez un serveur de discussion qui tombe toutes les quelques minutes sous une charge qu’il devrait supporter sans difficulté. 2 GB suffisent pour tester le fonctionnement avec deux personnes ; ce n’est pas une configuration adaptée à une équipe. Commencez avec 4 GB et prévoyez 8 GB si vous attendez des dizaines d’utilisateurs simultanés, des appels vidéo ou un historique d’uploads qui augmente. Prévoyez également de la RAM pour les autres services hébergés sur la machine : installer un workspace AFFiNE de type Notion sur le même VPS ajoute quatre conteneurs qui se partagent les mêmes pages mémoire. Leur consommation doit donc s’ajouter à celle de Rocket.Chat, et non être déduite de celle-ci.

Vous devez également disposer de trois éléments avant de commencer. Un nom de domaine avec un enregistrement A pointant vers l’adresse IP publique du VPS : les fonctionnalités temps réel de Rocket.Chat et ses clients mobiles nécessitent un hostname stable, pas une simple adresse IP. Les ports 80 et 443 ouverts à la fois dans le firewall du serveur et dans le firewall réseau de votre fournisseur, qui constitue un contrôle distinct sur la plupart des panels. Enfin, un VPS KVM Ubuntu 24.04 neuf avec un accès root ou sudo. Si vous vous demandez encore si un serveur de discussion est le meilleur premier service à déployer, le guide consacré aux services qui valent la peine d’être auto-hébergés en 2026 présente les compromis à prendre en compte.

Installer le moteur Docker et le plugin Compose

Utilisez le dépôt apt de Docker, et non le paquet docker.io fourni par Ubuntu ni l’ancien binaire Python autonome docker-compose. Compose moderne est un plugin Docker que vous invoquez avec docker compose, suivi d’un espace, et non avec un trait d’union. L’ancienne version docker-compose v1 n’est plus maintenue et gère mal la syntaxe de healthcheck et des dépendances utilisée ci-dessous.

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

Vérifiez que les deux composants sont présents :

sudo docker version
sudo docker compose version

L’affichage d’une ligne de version par docker compose version est le contrôle important. Les versions actuelles affichent Docker Compose version v5.x (v5.6.0, publiée le 2 octobre 2026, était la dernière version au 2026-10-10) ; une installation plus ancienne peut encore afficher v2.x, et Docker prend en charge les deux. Docker décrit Compose v5 comme fonctionnellement identique à la v2. Le numéro v5 évite la confusion avec les anciens formats de fichiers Compose v2 et v3. Les deux conviennent donc à ce guide. Si la commande renvoie docker: 'compose' is not a docker command, le plugin n’a pas été installé. Vous risquez alors des erreurs difficiles à diagnostiquer par la suite. Corrigez le problème maintenant.

Le fichier Compose : MongoDB comme replica set à un seul nœud

C’est la partie qui pose le plus souvent problème, lisez-la donc attentivement. Rocket.Chat utilise les change streams MongoDB pour transmettre les nouveaux messages en temps réel aux clients connectés. Or les change streams sont disponibles uniquement avec un replica set. Si vous configurez Rocket.Chat avec un mongod autonome classique, il se connectera, échouera à ouvrir un change stream, puis redémarrera en boucle indéfiniment. La correction est simple : vous exécutez un conteneur MongoDB classique et unique, mais vous le démarrez avec --replSet, puis vous initialisez un replica set à un seul membre.

Créez un répertoire de travail et un fichier 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:

Certains choix sont délibérés. Le port de Rocket.Chat est publié sur 127.0.0.1:3000, et non sur 0.0.0.0. L’application ne gère pas TLS elle-même : seul le reverse proxy installé sur le même serveur doit pouvoir y accéder. Lier ce port à toutes les interfaces exposerait directement une page de connexion en clair sur Internet. MongoDB n’est pas publié sur l’hôte. Il est accessible uniquement sur le réseau interne de Compose, sous le nom mongodb, qui correspond exactement au nom d’hôte utilisé par MONGO_URL. MONGO_URL contient ?replicaSet=rs0, qui définit explicitement le nom du replica set. MongoDB recommande ce paramètre pour garantir un comportement cohérent avec les différents drivers. Son absence ne provoque pas de problème à elle seule : directConnection prend la valeur false par défaut. Le driver découvre donc quand même le replica set et envoie les opérations au primary, à condition que le replica set ait été initialisé avec un nom d’hôte que Rocket.Chat peut résoudre. La section suivante s’en charge. MONGO_OPLOG_URL pointe vers la base de données local, qui contient l’oplog. Les versions modernes de Rocket.Chat privilégient les change streams, mais ce paramètre est sans risque et préserve la compatibilité avec les anciens chemins de code. Le depends_on utilise condition: service_healthy. Compose attend donc que MongoDB réponde à un ping avant de démarrer Rocket.Chat. C’est le rôle du healthcheck.

Épinglez de vrais tags de version sur les deux images, mongo:8.0 et une version explicite de Rocket.Chat, comme 8.5.1 ici. N’utilisez jamais :latest : cela transforme une docker pull sans supervision en mise à niveau accidentelle, impossible à migrer correctement. Vérifiez la version stable actuelle de Rocket.Chat ainsi que les versions de MongoDB prises en charge avant de les épingler. Rocket.Chat publie un document d’information lisible par une machine pour chaque version : curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' renvoie compatibleMongoVersions: ["8.0"] pour 8.5.1. mongo:8.0 est donc le seul moteur pris en charge, avec un indicateur lts qui précise si cette version est une version long-term support qu’il est préférable d’épingler sur un serveur que vous ne souhaitez pas surveiller en permanence. Tous les projets ne publient pas d’image versionnée. Dans ce cas, l’épingle porte sur la source : auto-héberger le suivi d’entraînement openGym signifie extraire un tag git précis et compiler le projet à partir de celui-ci, au lieu de suivre une branche qui évolue.

Initialiser le replica set

Démarrez la stack :

sudo docker compose up -d

Rocket.Chat va immédiatement s’arrêter en boucle et Docker va continuer à le redémarrer. C’est attendu, car le replica set n’existe pas encore. Créez-le une seule fois, manuellement :

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

Le résultat attendu est { ok: 1 }. Après quelques secondes, le nœud unique s’élit primary. Vérifiez-le avec :

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

Vous devez voir PRIMARY. Le détail le plus important de toute cette page est l’argument host: "mongodb:27017". Si vous exécutez un rs.initiate() seul, sans liste de membres, MongoDB annonce le replica set avec le hostname interne du conteneur, un hash aléatoire comme a1b2c3d4e5f6. Rocket.Chat, qui se connecte depuis son propre conteneur, ne peut pas résoudre ce nom. Le driver MongoDB échoue donc lors de la résolution DNS et boucle indéfiniment en journalisant MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Initialisez toujours le replica set avec le nom explicite du service correspondant à votre MONGO_URL.

Premier démarrage : surveiller le lancement

Une fois le set défini comme primaire, le redémarrage suivant de Rocket.Chat se connecte correctement et lance les migrations du premier démarrage. Suivez les journaux :

sudo docker compose logs -f rocketchat

La ligne à rechercher est la bannière de démarrage :

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

Le premier démarrage est lent. L’application exécute les migrations de la base de données et crée les index. Attendez donc une ou deux minutes avant de vous inquiéter. Si le journal répète plutôt MongoServerSelectionError: Server selection timed out after 30000 ms avec une description de topologie de type ReplicaSetNoPrimary, le replica set n’est pas initialisé. S’il répète getaddrinfo ENOTFOUND avec un hash aléatoire, il a été initialisé avec le mauvais hôte. Dans les deux cas, revenez à l’étape précédente. Dès que vous voyez SERVER RUNNING, Rocket.Chat est à l’écoute sur 127.0.0.1:3000. Vous pouvez alors placer un vrai nom d’hôte et TLS devant le service.

Derrière TLS

N’exposez jamais Rocket.Chat en HTTP simple. Une seule connexion sur http:// suffit pour transmettre votre mot de passe administrateur à toute personne présente sur le chemin réseau. Terminez TLS dans un reverse proxy installé sur le même serveur, puis transmettez les requêtes vers 127.0.0.1:3000. Deux points sont essentiels : le proxy doit transmettre les en-têtes de mise à niveau WebSocket, car Rocket.Chat fonctionne en temps réel et ne fonctionne plus sans eux, et la valeur de ROOT_URL dans le conteneur doit correspondre exactement à l’adresse HTTPS publique saisie par les utilisateurs.

Commencez par un bloc server nginx en HTTP simple, qui fait office de proxy vers l’application et transmet les en-têtes de mise à niveau. Enregistrez-le dans /etc/nginx/sites-available/rocketchat, créez un lien symbolique vers sites-enabled, puis rechargez nginx :

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

Laissez-le sur le port 80 pour le moment. Un bloc contenant listen 443 ssl; mais aucun certificat ne passera même pas sudo nginx -t. Rechargez nginx avec sudo nginx -t && sudo systemctl reload nginx, puis demandez le certificat. Sur Ubuntu, la méthode la plus simple consiste à utiliser les certificats TLS Let’s Encrypt avec Certbot et nginx : certbot --nginx réécrit directement le bloc ci-dessus en ajoutant listen 443 ssl;, les lignes ssl_certificate et une redirection automatique de 80 vers 443. Il planifie également le renouvellement. Si plusieurs conteneurs sont déjà exécutés derrière un même proxy, Traefik avec TLS automatique pour plusieurs applications Docker est une solution plus propre : ajoutez les labels de routeur et de service au service rocketchat, puis Traefik demande et renouvelle le certificat pour vous, sans aucun bloc nginx. Dans les deux cas, définissez ROOT_URL sur https://chat.example.com dans compose.yml, puis relancez sudo docker compose up -d pour que le conteneur prenne en compte la modification. Si vous souhaitez que le serveur soit accessible uniquement depuis votre propre réseau et non depuis Internet, placez devant lui un VPN WireGuard auto-hébergé sur le VPS et liez le proxy à l’adresse du tunnel.

Assistant de configuration au premier démarrage

Accédez à https://chat.example.com. Rocket.Chat vous guide dans un court assistant. Commencez par le compte admin : nom réel, nom d’utilisateur, adresse e-mail et mot de passe robuste. Il s’agit du seul compte existant, ne le perdez donc pas. Renseignez ensuite les informations sur l’organisation et le serveur : nom, secteur, taille, nom du site et langue par défaut. Ces informations sont essentiellement cosmétiques ; complétez-les, puis continuez. Vient ensuite le choix important : enregistrer cet espace de travail auprès de Rocket.Chat Cloud ou le conserver en mode autonome.

L’enregistrement active les notifications push mobiles via la gateway de Rocket.Chat ainsi que la marketplace des modules complémentaires, au prix d’une relation avec le control plane cloud de Rocket.Chat. Les push envoyées via la gateway sont également décomptées de la limite mensuelle de votre espace de travail. Le mode autonome garde le serveur entièrement privé et sans dépendance, mais les applications officielles iOS et Android ne reçoivent plus de notifications push. La documentation de Rocket.Chat indique en effet que ces applications fonctionnent uniquement avec sa cloud gateway, et que la gateway ne fonctionne pas sur un espace de travail non enregistré. La solution consiste à utiliser votre propre build white-labeled de l’application mobile : désactivez la gateway dans les paramètres Push, renseignez vos propres certificats APNs et identifiants Firebase Cloud Messaging, puis demandez à vos utilisateurs d’installer votre application au lieu de l’application officielle. Choisissez le mode autonome si la confidentialité est prioritaire et que vos utilisateurs utilisent l’application web, ou si vous êtes prêt à publier votre propre application mobile. Choisissez l’enregistrement si les notifications push sur les applications officielles sont indispensables. Vous pourrez modifier ce choix ultérieurement dans Admin.

Verrouillez l’accès avant d’inviter qui que ce soit

Rocket.Chat est livré avec l’inscription ouverte activée. Par défaut, Registration Form est réglé sur Public, ce qui permet à toute personne qui trouve l’URL de créer un compte. Sur un hostname public, cela revient à laisser une porte ouverte. Allez dans Admin → Settings → Accounts → Registration et réglez Registration Form sur Disabled, afin de créer les comptes manuellement ou au moyen d’un lien d’invitation, ou sur Secret URL. Profitez-en pour désactiver Allow Anonymous Read et Allow Anonymous Write, sauf si vous voulez précisément proposer un canal public en lecture seule. Si créer chaque compte manuellement vous semble fastidieux et que ce service n’est pas le seul auquel votre équipe se connecte, configurez la connexion OAuth de Rocket.Chat vers un serveur SSO Authentik auto-hébergé. Les arrivées et les départs seront ainsi gérés une seule fois, au même endroit, plutôt qu’application par application.

Choisissez également l’emplacement des uploads. Par défaut, le stockage File Upload utilise GridFS, qui stocke chaque image et chaque pièce jointe directement dans MongoDB. Cette configuration est simple, mais votre base de données, ainsi que chaque mongodump que vous effectuez, grossissent sans limite lorsque les utilisateurs collent des captures d’écran. Dans Admin → Settings → File Upload, vous pouvez remplacer ce stockage par le système de fichiers local ou par un bucket compatible S3, puis définir une taille maximale raisonnable pour les fichiers. Si votre équipe échange des bibliothèques photo entières plutôt que quelques captures d’écran occasionnelles, stockez-les sur un serveur photo dédié plutôt que dans une base de données de chat. La comparaison entre PhotoPrism et Immich évalue le coût de chacun en RAM par rapport aux commandes de sauvegarde nécessaires. Pour une petite équipe, GridFS convient. Sachez simplement que vos sauvegardes seront de plus en plus volumineuses.

Sauvegardes avec mongodump

Toutes vos données se trouvent dans le volume mongodb_data. Ne copiez pas simplement le volume pendant que la base de données fonctionne. Effectuez un dump cohérent avec mongodump et redirigez-le vers un fichier sur l’hôte :

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

Cette archive gzip contient l’intégralité de votre espace de travail : utilisateurs, canaux, messages, paramètres et, si vous avez conservé les uploads dans GridFS, les fichiers également. Si vous avez déplacé les uploads vers le système de fichiers ou S3, sauvegardez ce stockage séparément. Pour restaurer les données sur une nouvelle stack, initialisez d’abord le replica set, puis exécutez :

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

Copiez l’archive hors de la machine, dans un stockage objet, sur un autre serveur ou à tout autre emplacement qui ne sera pas affecté par la panne du VPS. Exécutez le dump chaque nuit depuis cron. Une sauvegarde que vous n’avez jamais restaurée est un espoir, pas une sauvegarde. Testez la restauration une fois sur un VPS temporaire afin de vérifier son bon fonctionnement avant d’en avoir besoin.

Mises à niveau : verrouillez les tags, lisez les notes et respectez la matrice MongoDB

Deux règles permettent de garder les mises à niveau prévisibles. Premièrement, mettez Rocket.Chat à niveau une version majeure à la fois. Rocket.Chat exécute des migrations de schéma au démarrage. Sa documentation recommande donc de passer séquentiellement d’une version majeure à la suivante. Elle avertit que le saut de plusieurs versions majeures peut provoquer de graves problèmes de compatibilité. Ne comptez pas sur le logiciel pour vous en empêcher : sa documentation ne garantit pas qu’un passage direct de 6.x à 8.x sera refusé sans risque. Une migration qui échoue en cours de route laisse son verrou en place et nécessite une réparation manuelle. Modifiez le tag de l’image pour utiliser la dernière release de la version majeure suivante, lisez les notes de cette release pour repérer les changements incompatibles, exécutez docker compose up -d, puis surveillez les journaux jusqu’à la fin de la migration avant de poursuivre.

Deuxièmement, respectez la matrice de prise en charge de MongoDB. Chaque release de Rocket.Chat prend en charge un ensemble précis de versions de MongoDB, et curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions vous indique lesquelles. Lorsque vous mettez MongoDB à niveau, par exemple de 7.0 à 8.0, ne franchissez qu’une version majeure à la fois et définissez la version de compatibilité des fonctionnalités après chaque étape. Avec MongoDB 8.0, cette commande exige un confirm: true explicite. Sinon, elle échoue et vous demande de la réexécuter avec le flag de confirmation :

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

Effectuez un mongodump avant chaque mise à niveau de l’un ou l’autre composant. C’est toute la protection dont vous disposez.

Modes d’échec, avec les chaînes exactes

Rocket.Chat redémarre en boucle juste après docker compose up, et docker compose logs rocketchat se remplit avec un MongoServerSelectionError. MongoDB fonctionne, mais le driver ne parvient pas à sélectionner un primaire. La chaîne exacte indique l’erreur de configuration. Server selection timed out after 30000 ms avec un type de topologie ReplicaSetNoPrimary signifie que vous n’avez jamais exécuté rs.initiate(). Le replica set n’a encore aucune configuration. getaddrinfo ENOTFOUND suivi d’un hash aléatoire signifie que vous avez lancé l’initialisation sans l’option explicite host: "mongodb:27017". MongoDB a donc annoncé un nom d’hôte de conteneur impossible à résoudre. Diagnostiquez le problème avec sudo docker compose exec mongodb mongosh --eval 'rs.status()' : si la commande renvoie l’erreur MongoServerError: no replset config has been received, initialisez le replica set ; si elle affiche un membre dont name est un hash aléatoire, réinitialisez-le avec le nom du service.

L’interface web se charge, mais la connexion tourne indéfiniment et n’aboutit jamais. Ouvrez la console du navigateur. Vous y verrez WebSocket connection to 'wss://chat.example.com/websocket' failed. Il s’agit presque toujours d’un problème de correspondance ROOT_URL ou d’un proxy qui ne transmet pas les en-têtes de mise à niveau. Vérifiez que ROOT_URL correspond exactement à l’adresse publique, y compris https://, et que votre bloc nginx location définit Upgrade et Connection "upgrade" avec proxy_http_version 1.1. Après toute modification, exécutez de nouveau docker compose up -d.

Un conteneur s’arrête constamment et docker compose ps indique Restarting. docker compose logs s’interrompt au milieu d’une ligne et sudo dmesg | tail affiche Out of memory: Killed process 12345 (mongod) provenant de l’oom-killer ; le code de sortie est 137. Le serveur n’a plus assez de RAM. La vraie solution consiste à utiliser un VPS plus grand, avec 4 GB au minimum. En attendant, ajoutez du swap et limitez le cache de MongoDB avec --wiredTigerCacheSizeGB dans son command. Définissez une valeur inférieure à la valeur par défaut, et non supérieure. Par exemple, utilisez 1 sur un serveur de 4 GB (valeur par défaut : 1.5) ou 0.3 sur un serveur de 2 GB (valeur par défaut : environ 0.5). Le swap ne fait toutefois que retarder le prochain OOM en charge réelle :

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

docker compose up échoue avec Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Un autre processus utilise déjà le port 3000. Il s’agit souvent d’un ancien conteneur Rocket.Chat qui ne s’est pas arrêté correctement, ou d’une autre application. Identifiez-le avec sudo ss -ltnp | grep :3000, arrêtez ce processus ou ce conteneur, ou modifiez le côté hôte du mapping avec 127.0.0.1:3001:3000, puis mettez à jour proxy_pass dans votre proxy pour qu’il corresponde.

FAQ

Rocket.Chat a-t-il réellement besoin d’un replica set MongoDB ?

Oui, même sur un seul serveur avec un seul nœud de base de données. Rocket.Chat distribue les messages en temps réel à l’aide des change streams de MongoDB. Les change streams sont disponibles uniquement avec un replica set, et un mongod autonome ne peut pas en ouvrir. Vous n’avez pas besoin de plusieurs machines : lancez un seul conteneur MongoDB avec --replSet rs0, puis initialisez un replica set à un membre avec rs.initiate(). Si vous omettez cette étape, le driver ne trouve jamais de primary. Rocket.Chat redémarre alors en boucle avec MongoServerSelectionError: Server selection timed out et ne termine jamais son démarrage.

De combien de RAM Rocket.Chat auto-hébergé a-t-il besoin ?

Prévoyez 4 GB comme minimum pratique et 8 GB pour une équipe active. Le processus Node de Rocket.Chat utilise environ 1 à 1.5 GB. Le cache WiredTiger par défaut de MongoDB représente la moitié de la RAM totale moins 1 GB, comme si aucun autre processus ne fonctionnait sur le serveur. Sur un serveur doté de 2 GB, ce cache, le heap de Node et la surcharge propre de mongod entrent en concurrence. L’out-of-memory killer termine alors mongod dès que la charge devient réelle, avec Killed dans les journaux et le code de sortie 137. Deux GB suffisent uniquement pour évaluer le logiciel avec quelques utilisateurs de test.

Comment placer Rocket.Chat derrière HTTPS ?

Exécutez un reverse proxy sur le même VPS. Il assure la terminaison TLS et transmet les requêtes vers 127.0.0.1:3000. Définissez ROOT_URL du conteneur sur votre adresse publique https://. Le proxy doit transmettre les en-têtes d’upgrade WebSocket, sinon la connexion reste bloquée lors de la connexion. Certbot avec nginx est la solution la plus simple pour une seule application. Traefik est plus pratique si vous exécutez plusieurs conteneurs derrière un même proxy et souhaitez automatiser la gestion des certificats.

Comment sauvegarder un Rocket.Chat auto-hébergé ?

Créez un dump cohérent de la base de données avec mongodump au lieu de copier le volume : docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Cette archive contient les utilisateurs, les canaux, les messages et les paramètres, ainsi que les fichiers téléversés si vous avez conservé le stockage sur GridFS. Copiez-la hors du serveur, automatisez cette opération chaque nuit avec cron et testez une mongorestore sur un serveur temporaire afin de vérifier que la restauration fonctionne réellement.

Comment mettre à niveau Rocket.Chat sans casser MongoDB ?

Mettez à niveau Rocket.Chat une version majeure à la fois. Le logiciel exécute des migrations au démarrage, et sa documentation avertit que le fait d’ignorer des versions majeures peut provoquer de graves problèmes de compatibilité. Elle ne garantit pas qu’une mise à niveau sera bloquée. Lisez les notes de chaque version avant de modifier le tag d’image épinglé. Vérifiez les versions de MongoDB prises en charge par la version cible avec curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Lors d’une mise à niveau de MongoDB, avancez également d’une version majeure à la fois et définissez setFeatureCompatibilityVersion avec confirm: true après chaque étape. Effectuez toujours une mongodump au préalable.