Installer Rocket.Chat avec Docker Compose sur un VPS

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 RAM rarement expliqué

Dimensionnez honnêtement le serveur. Pour une petite équipe, le minimum réaliste est de 2 vCPU et 4 GB de RAM. Le processus Node.js de Rocket.Chat demande à lui seul environ 1 à 1.5 GB, et le cache WiredTiger de MongoDB utilise par défaut environ la moitié de la RAM restante. Sur un VPS de 2 GB, les deux services tiennent au démarrage, puis entrent en concurrence 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 arrête le processus le plus volumineux, généralement mongod. Le conteneur affiche Killed, Docker le redémarre, et vous obtenez un serveur de chat qui se déconnecte toutes les quelques minutes sous une charge qu’il devrait absorber sans difficulté. 2 GB conviennent pour tester le fonctionnement à deux ; ce n’est pas suffisant pour un serveur d’é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 s’allonge. Prévoyez aussi la mémoire nécessaire aux autres services du serveur : installer un espace de travail AFFiNE de type Notion sur le même VPS ajoute quatre conteneurs qui se disputent les mêmes pages mémoire. Leur consommation de RAM doit donc s’ajouter à celle de Rocket.Chat, et non être prélevée sur celle-ci.

Trois éléments doivent également être en place 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 nom d’hôte stable, et non une simple adresse IP. Les ports 80 et 443 ouverts à la fois sur le pare-feu du serveur et sur le pare-feu réseau de votre fournisseur, qui constitue un contrôle distinct dans la plupart des interfaces d’administration. Enfin, un VPS KVM Ubuntu 24.04 fraîchement installé, avec un accès root ou sudo. Si vous déterminez encore si un serveur de chat est le premier service à auto-héberger, le guide sur les services qui méritent d’être auto-hébergés en 2026 présente les compromis.

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, avec un espace et non un trait d’union. L’ancien docker-compose v1 est en fin de vie et gère incorrectement 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

docker compose version qui affiche quelque chose comme Docker Compose version v2.x est le contrôle important. Si la commande renvoie une erreur avec docker: 'compose' is not a docker command, le plugin n’est pas installé. Vous risquez sinon de rencontrer des erreurs difficiles à diagnostiquer plus tard. Corrigez le problème maintenant.

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

C’est ici que les erreurs sont les plus fréquentes. Lisez donc attentivement. Rocket.Chat utilise les change streams MongoDB pour transmettre les nouveaux messages aux clients connectés en temps réel. Or les change streams ne sont disponibles qu’avec un replica set. Si vous configurez Rocket.Chat pour utiliser une instance autonome classique mongod, il se connectera, échouera à ouvrir un change stream, puis redémarrera en boucle indéfiniment. La correction est simple : exécutez un conteneur MongoDB standard, mais démarrez-le avec --replSet, puis 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 elle-même TLS. Seul le reverse proxy installé sur le même serveur doit donc pouvoir y accéder. Une écoute sur 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 transmet ?replicaSet=rs0. Sans cette option, le driver considère le serveur comme autonome, même s’il s’agit d’un replica set, et les change streams échouent toujours. MONGO_OPLOG_URL pointe vers la base de données local, qui contient l’oplog. Les versions récentes de Rocket.Chat privilégient les change streams, mais ce paramètre reste sans effet négatif et permet de conserver la compatibilité avec les anciens chemins de code. Le depends_on utilise condition: service_healthy. Compose attend ainsi que MongoDB réponde à un ping avant de démarrer Rocket.Chat. C’est le rôle du healthcheck.

Utilisez des tags de version réels et figés pour les deux images, mongo:8.0 et une version explicite de Rocket.Chat comme 8.5.1 ici, et n’utilisez jamais :latest. Sinon, une mise à niveau docker pull sans intervention peut se transformer en mise à niveau accidentelle, impossible à migrer. Vérifiez la version stable actuelle de Rocket.Chat ainsi que les versions de MongoDB compatibles avant de figer les versions. Rocket.Chat publie un document d’informations lisible par 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. Le document contient aussi un indicateur lts qui précise si cette version bénéficie d’un support à long terme et mérite d’être figée sur un serveur que vous préférez ne pas devoir surveiller en permanence. Tous les projets ne publient pas d’image versionnée. Dans ce cas, le figement s’applique au code source : auto-héberger le suivi d’entraînement openGym consiste à extraire un tag git précis et à compiler le projet à partir de celui-ci, plutôt qu’à 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.

L’assistant de configuration initiale

Accédez à https://chat.example.com. Rocket.Chat vous guide alors dans un assistant court. Commencez par renseigner le compte admin, le nom réel, le nom d’utilisateur, l’adresse e-mail et un mot de passe robuste. Il s’agit du seul compte existant. Ne le perdez pas. Renseignez ensuite les informations sur l’organisation et le serveur : nom, secteur d’activité, taille, nom du site et langue par défaut. Ces paramètres 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 passerelle de Rocket.Chat et l’add-on marketplace, au prix d’une relation avec le control plane cloud de Rocket.Chat. Le mode autonome conserve un serveur entièrement privé et sans dépendance externe. En revanche, les notifications push iOS et Android cessent de fonctionner, car Apple et Google n’autorisent pas une application construite par vos soins à utiliser les certificats push. Les applications officielles passent par la passerelle cloud. Choisissez le mode autonome si la confidentialité est prioritaire et que vos utilisateurs travaillent principalement dans l’application web. Choisissez l’enregistrement si les notifications push mobiles 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 : figer les tags, lire les notes, respecter la matrice MongoDB

Deux règles rendent les mises à niveau prévisibles. Premièrement, mettez Rocket.Chat à niveau une version majeure à la fois. Au démarrage, Rocket.Chat exécute des migrations de schéma et refuse volontairement de sauter des versions majeures. Si vous essayez de passer directement de 6.x à 8.x, le service s’arrête avec une erreur de migration au lieu de risquer de corrompre vos données. Modifiez le tag de l’image pour utiliser la dernière release de la version majeure suivante, lisez les notes de cette release pour connaître les changements incompatibles, exécutez docker compose up -d, puis surveillez les journaux jusqu’à la fin de la migration avant de continuer. 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, avancez d’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 s’arrête avec un message vous demandant 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 votre seule véritable assurance.

Modes de défaillance, 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 primary. La chaîne exacte indique l’erreur commise. 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 pas encore de configuration. getaddrinfo ENOTFOUND suivi d’un hash aléatoire signifie que vous avez lancé l’initialisation sans préciser explicitement 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 de ROOT_URL ou d’un proxy qui ne transmet pas les en-têtes d’upgrade. 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. Modifiez l’un de ces éléments, puis relancez 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 1 dans son command, mais le swap ne fait 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. Le port 3000 est déjà utilisé, souvent par un ancien conteneur Rocket.Chat qui ne s’est pas arrêté correctement, ou par une autre application. Identifiez le processus avec sudo ss -ltnp | grep :3000, arrêtez ce processus ou ce conteneur, ou modifiez le port côté hôte dans le mapping en le remplaçant par 127.0.0.1:3001:3000, puis mettez à jour proxy_pass dans votre proxy.

FAQ

Rocket.Chat a-t-il vraiment besoin d’un replica set MongoDB ?

Oui, même pour un serveur unique avec un seul nœud de base de données. Rocket.Chat distribue les messages en temps réel au moyen des flux de modifications MongoDB. Les flux de modifications sont uniquement disponibles avec un replica set, et un mongod autonome ne peut pas en ouvrir. Vous n’avez pas besoin de plusieurs machines. Exécutez un seul conteneur MongoDB démarré avec --replSet rs0, puis initialisez un replica set à un seul membre avec rs.initiate(). Si vous ignorez 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. MongoDB réserve environ la moitié de la RAM restante à son cache WiredTiger. Sur une machine de 2 GB, les deux se disputent donc la mémoire. L’out-of-memory killer termine mongod dès que la charge devient réelle. Les journaux affichent alors Killed 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 de mise à niveau WebSocket. Sinon, la connexion restera bloquée lors de l’authentification. Certbot avec nginx est la configuration 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. Elle contient aussi les fichiers importés si vous avez conservé le stockage sur GridFS. Copiez-la hors du serveur. Automatisez cette opération chaque nuit avec cron. Effectuez également un mongorestore sur une machine de test 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 refuse de sauter des versions majeures. Consultez les notes de chaque version avant de modifier le tag de l’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. Lorsque vous mettez MongoDB à niveau, avancez également d’une version majeure à la fois et définissez setFeatureCompatibilityVersion avec confirm: true après chaque étape. Effectuez toujours un mongodump au préalable.