Guías

Por Matt Connor 2026-10-10

Instalar Rocket.Chat con Docker Compose en un VPS

Q: ¿Cómo hago una copia de seguridad de un Rocket.Chat autohospedado?

Cree un volcado coherente de la base de datos con mongodump en lugar de copiar el volumen: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Ese archivo contiene usuarios, canales, mensajes y ajustes. También incluye los archivos subidos si mantiene el almacenamiento en GridFS. Copie el archivo fuera del servidor. Automatice esta tarea cada noche con cron. Después, pruebe una mongorestore en un servidor desechable para confirmar que la restauración funciona realmente.

Guía para alojar Rocket.Chat con Docker Compose: replica set MongoDB de un nodo, TLS, copias de seguridad y errores habituales corregidos.

Qué va a implementar

Un chat privado para equipos bajo su control: Rocket.Chat ejecutándose en su propio VPS mediante Docker Compose, con terminación TLS y todos los mensajes almacenados en una base de datos MongoDB que puede respaldar y trasladar. Rocket.Chat es una alternativa madura y de código abierto a Slack y Teams. Incluye canales, mensajes directos, hilos, intercambio de archivos y funciones de voz y vídeo, todo en el hardware que alquila y administra. No es la única opción sólida. Si todavía está eligiendo, comparación entre Mattermost, Rocket.Chat, Synapse y Zulip las compara según los aspectos que suelen causar problemas más adelante: RAM, base de datos, notificaciones push móviles, SSO y actualizaciones. La aplicación es un único contenedor que se inicia en pocos minutos. Todo lo que suele fallar realmente está en la base de datos asociada. Por eso, la mayor parte de esta guía trata sobre MongoDB y, en particular, sobre el único requisito que sorprende a todo el mundo la primera vez: Rocket.Chat no funciona con una instancia independiente de MongoDB. Necesita un conjunto de réplicas, aunque ese «conjunto» tenga un solo nodo.

Requisitos previos y el cálculo de RAM que nadie explica

Dimensione el servidor de forma realista. El mínimo razonable para un equipo pequeño es 2 vCPU y 4 GB de RAM. El proceso Node.js de Rocket.Chat necesita aproximadamente entre 1 y 1.5 GB por sí solo, y la caché WiredTiger de MongoDB usa de forma predeterminada el mayor valor entre el 50 % de (RAM total menos 1 GB) y 0.256 GB. Este valor predeterminado supone que mongod dispone de toda la máquina: se calcula a partir de la RAM total y no tiene en cuenta la memoria que Node ya utiliza. Por eso resulta en 1.5 GB en un servidor de 4 GB y en aproximadamente 0.5 GB en uno de 2 GB, además del heap de Node, la memoria propia de mongod fuera de la caché y el sistema operativo. En un VPS de 2 GB, ambos caben al arrancar, pero entran en conflicto en cuanto llega tráfico real: MongoDB aumenta su caché, Node aumenta su heap, el kernel se queda sin páginas y el asesino de procesos por falta de memoria termina el proceso que más memoria consume, normalmente mongod. El contenedor muestra Killed, Docker lo reinicia y el servidor de chat se desconecta cada pocos minutos bajo una carga que debería soportar sin problemas. 2 GB son suficientes para probarlo con dos personas, pero no para un servidor de equipo. Empiece con 4 GB y asígnele 8 GB si espera decenas de usuarios simultáneos, videollamadas o un historial de archivos subidos que crezca con el tiempo. Reserve memoria también para cualquier otra carga del servidor: alojar un espacio de trabajo AFFiNE de estilo Notion en el mismo VPS añade otros cuatro contenedores que compiten por las mismas páginas de memoria, por lo que su RAM debe sumarse a la de Rocket.Chat, no descontarse de ella.

También necesita disponer de tres elementos antes de empezar. Un nombre de dominio con un registro A que apunte a la IP pública del VPS. Las funciones en tiempo real de Rocket.Chat y sus clientes móviles necesitan un nombre de host estable, no una IP sin más. Los puertos 80 y 443 abiertos tanto en el firewall del servidor como en el firewall de red del proveedor, que en la mayoría de los paneles es un control independiente. Y un VPS KVM nuevo con Ubuntu 24.04 y acceso root o sudo. Si todavía está decidiendo si un servidor de chat es el servicio adecuado para ejecutar primero, la guía sobre qué merece la pena alojar por cuenta propia en 2026 explica las ventajas y los inconvenientes.

Instale el motor de Docker y el plugin de Compose

Use el repositorio apt de Docker, no el paquete docker.io que incluye Ubuntu ni el antiguo binario independiente de docker-compose para Python. Compose moderno es un plugin de Docker que se ejecuta como docker compose, con un espacio, no con un guion. La versión antigua docker-compose v1 llegó al final de su vida útil y gestiona incorrectamente la sintaxis de healthcheck y de dependencias que aparece a continuación.

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

Confirme que ambos componentes estén instalados:

sudo docker version
sudo docker compose version

docker compose version mostrando una línea de versión es la comprobación relevante. Las versiones actuales muestran Docker Compose version v5.x (v5.6.0, publicada el 2 de octubre de 2026, era la más reciente el 2026-10-10); una instalación antigua todavía puede mostrar v2.x, y Docker admite ambas. Docker describe Compose v5 como funcionalmente idéntico a v2, pero lo numera como v5 para evitar confusiones con los formatos de archivo de Compose v2 y v3 heredados, por lo que cualquiera de las dos versiones sirve para esta guía. Si aparece el error docker: 'compose' is not a docker command, el plugin no se instaló y pronto se producirán errores difíciles de interpretar; corríjalo aquí.

El archivo compose: MongoDB como conjunto de réplicas de un solo nodo

Esta es la parte que suele configurarse mal, así que léala despacio. Rocket.Chat usa change streams de MongoDB para enviar mensajes nuevos a los clientes conectados en tiempo real, y los change streams sólo están disponibles en un conjunto de réplicas. Si apunta Rocket.Chat a un mongod independiente, se conectará, no podrá abrir un change stream y entrará en un bucle de reinicios permanente. La solución no es complicada: ejecute un contenedor normal de MongoDB, pero inícielo con --replSet y después inicialice un conjunto con un solo miembro.

Cree un directorio de trabajo y un 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:

Algunas decisiones son deliberadas. El puerto de Rocket.Chat se publica en 127.0.0.1:3000, no en 0.0.0.0. La aplicación no usa TLS, por lo que sólo el reverse proxy del mismo servidor debe acceder a ella; vincularlo a todas las interfaces expondría una página de inicio de sesión sin cifrar directamente en Internet. MongoDB no se publica en el host; sólo se puede acceder a él a través de la red interna de Compose con el nombre mongodb, que es exactamente el nombre de host que usa MONGO_URL. MONGO_URL contiene ?replicaSet=rs0, que especifica el nombre del conjunto; MongoDB recomienda establecerlo para mantener un comportamiento coherente entre los drivers. Omitirlo no rompe nada por sí solo: directConnection tiene false como valor predeterminado, por lo que el driver sigue detectando el conjunto de réplicas y envía las operaciones al primario, siempre que el conjunto se haya iniciado con un nombre de host que Rocket.Chat pueda resolver. La siguiente sección se encarga de ello. MONGO_OPLOG_URL apunta a la base de datos local, donde se almacena el oplog; las versiones modernas de Rocket.Chat prefieren los change streams, pero establecerlo no causa problemas y mantiene compatibles las rutas de código antiguas. depends_on usa condition: service_healthy, por lo que Compose espera a que MongoDB responda a un ping antes de iniciar Rocket.Chat. Para eso sirve el healthcheck.

Fije etiquetas de versión reales en ambas imágenes, mongo:8.0 y una versión explícita de Rocket.Chat, como 8.5.1 en este caso, y no use nunca :latest. Esto convierte una docker pull desatendida en una actualización accidental que no se puede migrar. Compruebe la versión estable actual de Rocket.Chat y las versiones de MongoDB compatibles antes de fijarlas. Rocket.Chat publica un documento de información legible por máquinas para cada versión: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' devuelve compatibleMongoVersions: ["8.0"] para 8.5.1, por lo que mongo:8.0 es el único motor compatible, además de un indicador lts que informa si esa versión es una compilación de soporte a largo plazo adecuada para fijarla en un servidor que no quiere supervisar continuamente. No todos los proyectos publican una imagen versionada. En ese caso, la versión se fija en el código fuente: alojar el rastreador de entrenamientos openGym significa descargar una etiqueta git específica y compilarla, en lugar de seguir una rama que cambia.

Inicialice el conjunto de réplicas

Inicie la pila:

sudo docker compose up -d

Rocket.Chat comenzará a fallar de inmediato y Docker lo reiniciará continuamente. Esto es normal porque el conjunto de réplicas todavía no existe. Créelo una vez, manualmente:

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

El resultado correcto es { ok: 1 }. En pocos segundos, el nodo único se elige como primary. Confírmelo con:

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

Debe ver PRIMARY. El detalle más importante de toda esta página es el argumento host: "mongodb:27017". Si ejecuta un rs.initiate() sin una lista de miembros, MongoDB anuncia el conjunto de réplicas usando el nombre de host interno del contenedor, un hash aleatorio como a1b2c3d4e5f6. Rocket.Chat, que se conecta desde su propio contenedor, no puede resolver ese nombre. Por eso el controlador de MongoDB falla al resolverlo mediante DNS y queda registrando MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 en un bucle infinito. Inicialice siempre el conjunto con el nombre explícito del servicio que coincide con su MONGO_URL.

Primer arranque: supervise el inicio

Cuando el conjunto ya es el principal, el siguiente reinicio de Rocket.Chat se conecta correctamente e inicia sus migraciones de primer arranque. Siga los registros:

sudo docker compose logs -f rocketchat

La línea que debe esperar es el aviso de inicio:

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

El primer arranque es lento. La aplicación ejecuta migraciones de la base de datos y crea índices, así que espere uno o dos minutos antes de investigar. Si el registro repite MongoServerSelectionError: Server selection timed out after 30000 ms con una descripción de topología de tipo ReplicaSetNoPrimary, el conjunto de réplicas no está iniciado. Si repite getaddrinfo ENOTFOUND con un hash aleatorio, se inició con el host incorrecto. En ambos casos, vuelva al paso anterior. Cuando vea SERVER RUNNING, Rocket.Chat estará escuchando en 127.0.0.1:3000 y será el momento de configurarle un nombre de host real y TLS.

Ponlo detrás de TLS

Nunca expongas Rocket.Chat mediante HTTP sin cifrar. Si inicias sesión una vez a través de http://, habrás entregado tu contraseña de administrador a cualquiera que pueda interceptar el tráfico. Termina TLS en un reverse proxy del mismo servidor y reenvía las solicitudes a 127.0.0.1:3000. Hay dos aspectos importantes: el proxy debe reenviar las cabeceras de actualización de WebSocket, porque Rocket.Chat funciona en tiempo real y deja de funcionar sin ellas, y ROOT_URL del contenedor debe coincidir exactamente con la dirección HTTPS pública que introducen los usuarios.

Empieza con un bloque de servidor HTTP sin cifrar de nginx que haga proxy hacia la aplicación y reenvíe las cabeceras de actualización. Guárdalo como /etc/nginx/sites-available/rocketchat, crea un enlace simbólico en sites-enabled y recarga 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;
    }
}

Déjalo en el puerto 80 por ahora. Un bloque con listen 443 ssl; y sin certificado ni siquiera superará sudo nginx -t. Recarga nginx (sudo nginx -t && sudo systemctl reload nginx) y emite el certificado. En Ubuntu, la opción más sencilla es certificados TLS de Let's Encrypt con Certbot y nginx: certbot --nginx reescribe el bloque anterior en el mismo archivo. Añade listen 443 ssl;, las líneas ssl_certificate y una redirección automática de 80 a 443. También programa la renovación por ti. Si ya ejecutas varios contenedores detrás de un único proxy, Traefik con TLS automático para varias aplicaciones Docker es una opción más ordenada. Añade las etiquetas del router y del servicio al servicio rocketchat. Traefik solicitará y renovará el certificado por ti, sin ningún bloque de nginx. En ambos casos, establece ROOT_URL en https://chat.example.com dentro de compose.yml y vuelve a ejecutar sudo docker compose up -d para que el contenedor aplique el cambio. Si quieres que el servidor sólo sea accesible desde tu propia red y no desde Internet pública, colócalo detrás de una VPN WireGuard autohospedada en el VPS y vincula el proxy a la dirección del túnel.

El asistente de configuración inicial

Abra https://chat.example.com en el navegador y Rocket.Chat le guiará por un asistente breve. Primero, la cuenta de administrador, con nombre real, nombre de usuario, correo electrónico y una contraseña segura; esta es la única cuenta existente, así que no la pierda. Después, la información de la organización y del servidor: nombre, sector, tamaño, nombre del sitio e idioma predeterminado; son datos meramente estéticos, complételos y continúe. Luego aparece la decisión realmente importante: registrar este espacio de trabajo en Rocket.Chat Cloud o mantenerlo independiente.

El registro habilita las notificaciones push móviles mediante la pasarela de Rocket.Chat y el mercado de complementos, pero crea una relación con el plano de control de la nube de Rocket.Chat; las notificaciones push enviadas mediante la pasarela también cuentan para el límite mensual de su espacio de trabajo. El modo independiente mantiene el servidor completamente privado y sin dependencias externas, pero las aplicaciones oficiales de iOS y Android dejan de recibir notificaciones push, porque la documentación de Rocket.Chat indica que esas aplicaciones sólo funcionan con su pasarela en la nube, y la pasarela no se ejecuta en un espacio de trabajo no registrado. La alternativa es crear su propia versión de la aplicación móvil con marca blanca: desactive la pasarela en la configuración de Push, introduzca sus propios certificados de APNs y credenciales de Firebase Cloud Messaging, y haga que los usuarios instalen su aplicación en lugar de la oficial. Elija el modo independiente si la privacidad es el objetivo principal y sus usuarios trabajan en la aplicación web, o si está preparado para distribuir su propia aplicación móvil; elija el registro si las notificaciones push en las aplicaciones oficiales son imprescindibles. Puede cambiar esta decisión más adelante en Admin.

Bloquéelo antes de invitar a alguien

Rocket.Chat se distribuye con el registro abierto activado. De forma predeterminada, Registration Form está configurado como Public, por lo que cualquiera que encuentre la URL puede crear una cuenta. En un hostname público, esto deja el servicio expuesto. Vaya a Admin → Settings → Accounts → Registration y configure Registration Form como Disabled, para crear cuentas manualmente o mediante un enlace de invitación, o como Secret URL. Mientras está allí, desactive Allow Anonymous Read y Allow Anonymous Write, salvo que necesite específicamente un canal público de solo lectura. Si crear cada cuenta manualmente resulta tedioso y este no es el único servicio al que inicia sesión su equipo, configure el inicio de sesión OAuth de Rocket.Chat para usar un servidor SSO Authentik autohospedado. Así, las altas y las bajas se gestionan una sola vez y desde un único lugar, en vez de servicio por servicio.

Decida también dónde se almacenan las cargas. El almacenamiento predeterminado de File Upload es GridFS, que guarda cada imagen y archivo adjunto dentro de MongoDB. Es sencillo, pero significa que la base de datos, y cada mongodump que cree, crece sin límite a medida que las personas pegan capturas de pantalla. En Admin → Settings → File Upload puede cambiar el almacenamiento al sistema de archivos local o a un bucket compatible con S3, y establecer un tamaño máximo razonable para los archivos. Si su equipo intercambia bibliotecas fotográficas completas en lugar de alguna captura ocasional, esas bibliotecas deben estar en un servidor de fotos dedicado y no en una base de datos de chat. Comparación de PhotoPrism e Immich analiza el consumo de RAM de cada opción y los comandos de backup que necesita. Para un equipo pequeño, GridFS es adecuado; tenga en cuenta que sus backups serán cada vez más pesados.

Copias de seguridad con mongodump

Todos los datos están en el volumen mongodb_data. No copie el volumen mientras la base de datos está en ejecución. Cree un volcado coherente con mongodump y transmítalo a un archivo en el host:

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

Ese único archivo comprimido con gzip contiene todo el espacio de trabajo: usuarios, canales, mensajes, configuración y, si dejó las cargas en GridFS, también los archivos. Si trasladó las cargas al sistema de archivos o a S3, haga una copia de seguridad de ese almacenamiento por separado. Para restaurar en una pila nueva, inicialice primero el conjunto de réplicas y después:

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

Copie el archivo fuera del servidor, en un almacenamiento de objetos, otro servidor o cualquier ubicación donde la caída del VPS no destruya también la copia de seguridad. Ejecute el volcado cada noche desde cron. Una copia de seguridad que nunca ha restaurado es una esperanza, no una copia de seguridad. Practique la restauración una vez en un VPS desechable para confirmar que funciona antes de necesitarla.

Actualizaciones: fije las etiquetas, lea las notas y respete la matriz de Mongo

Dos reglas mantienen las actualizaciones bajo control. Primero, actualice Rocket.Chat una versión principal cada vez. El sistema ejecuta migraciones del esquema durante el arranque, y la documentación de actualización de Rocket.Chat indica que siempre se deben aplicar las actualizaciones secuencialmente entre versiones principales. También advierte que omitir versiones principales puede causar problemas graves de compatibilidad. No dé por hecho que el software se lo impedirá: la documentación no garantiza que un salto directo de 6.x a 8.x se rechace de forma segura, y una migración que falle a mitad de proceso deja activado el bloqueo y requiere una reparación manual. Cambie la etiqueta de la imagen a la versión más reciente de la siguiente versión principal, lea las notas de esa versión para identificar cambios incompatibles, ejecute docker compose up -d y supervise los registros hasta que termine la migración antes de continuar. Segundo, respete la matriz de compatibilidad de MongoDB. Cada versión de Rocket.Chat admite un conjunto específico de versiones de MongoDB, y curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions le indica cuáles son. Cuando actualice MongoDB, por ejemplo de 7.0 a 8.0, avance una versión principal cada vez y establezca la versión de compatibilidad de funciones después de cada salto. En MongoDB 8.0, ese comando requiere un confirm: true explícito. De lo contrario, se rechaza y muestra un mensaje que indica que debe volver a ejecutarlo con el indicador de confirmación:

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

Haga un mongodump antes de cada actualización de cualquiera de los dos componentes. Esa es toda la protección necesaria.

Modos de fallo, con las cadenas exactas

Rocket.Chat entra en bucles de reinicio justo después de docker compose up y docker compose logs rocketchat se llena con un MongoServerSelectionError. MongoDB está activo, pero el controlador no puede seleccionar un nodo primario. La cadena exacta indica qué error se cometió. Server selection timed out after 30000 ms con un tipo de topología ReplicaSetNoPrimary significa que nunca ejecutó rs.initiate(). El conjunto todavía no tiene configuración. getaddrinfo ENOTFOUND seguido de un hash aleatorio significa que inició el conjunto sin especificar explícitamente host: "mongodb:27017". Por eso MongoDB anunció un nombre de host de contenedor que no se puede resolver. Diagnostique el problema con sudo docker compose exec mongodb mongosh --eval 'rs.status()'. Si devuelve el error MongoServerError: no replset config has been received, inicie el conjunto. Si muestra un miembro cuyo name es un hash aleatorio, vuelva a iniciarlo con el nombre del servicio.

La interfaz web se carga, pero el inicio de sesión queda bloqueado y nunca termina. Abra la consola del navegador. Allí verá WebSocket connection to 'wss://chat.example.com/websocket' failed. Casi siempre se debe a una discrepancia de ROOT_URL o a un proxy que no reenvía las cabeceras de actualización. Confirme que ROOT_URL coincida exactamente con la dirección pública, incluido https://, y que el bloque location de nginx establezca Upgrade y Connection "upgrade" con proxy_http_version 1.1. Cambie uno de estos valores y vuelva a ejecutar docker compose up -d.

Un contenedor sigue terminándose y docker compose ps muestra Restarting. docker compose logs se corta a mitad de una línea y sudo dmesg | tail muestra Out of memory: Killed process 12345 (mongod) del oom-killer. El código de salida es 137. El servidor se ha quedado sin RAM. La solución real es usar un VPS más grande, con 4 GB como mínimo. Como medida temporal, añada swap y limite la caché de MongoDB con --wiredTigerCacheSizeGB en su command. Establezca un valor inferior al predeterminado, no superior. Por ejemplo, use 1 en un servidor con 4 GB (el valor predeterminado es 1.5) o 0.3 en uno con 2 GB (el valor predeterminado es aproximadamente 0.5). Sin embargo, la swap sólo retrasa el siguiente OOM cuando existe carga real:

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

docker compose up falla con Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Otro proceso ya está usando el puerto 3000. A menudo se trata de un contenedor anterior de Rocket.Chat que no se detuvo correctamente, o de otra aplicación. Localícelo con sudo ss -ltnp | grep :3000. Detenga ese proceso o contenedor, o cambie el lado del host de la asignación a 127.0.0.1:3001:3000 y actualice proxy_pass en el proxy para que coincida.

FAQ

¿Rocket.Chat realmente necesita un conjunto de réplicas de MongoDB?

Sí, incluso en un solo servidor con un único nodo de base de datos. Rocket.Chat entrega mensajes en tiempo real mediante flujos de cambios de MongoDB, y los flujos de cambios sólo están disponibles en conjuntos de réplicas. Un mongod independiente no puede abrirlos. No necesita varias máquinas: debe ejecutar un contenedor de MongoDB iniciado con --replSet rs0 e inicializar un conjunto de un solo miembro con rs.initiate(). Si omite este paso, el controlador nunca encuentra un nodo primario. Por eso Rocket.Chat entra en un ciclo de reinicios con MongoServerSelectionError: Server selection timed out y nunca termina de iniciar.

¿Cuánta RAM necesita Rocket.Chat autohospedado?

Planifique 4 GB como mínimo práctico y 8 GB para un equipo con bastante actividad. El proceso de Node de Rocket.Chat usa aproximadamente entre 1 y 1.5 GB. La caché predeterminada de WiredTiger de MongoDB equivale a la mitad de la RAM total menos 1 GB. Se calcula como si no hubiera ningún otro proceso en el servidor. En un servidor con 2 GB, esa caché, el heap de Node y la sobrecarga propia de mongod compiten por la memoria. Con una carga real, el terminador de procesos por falta de memoria finaliza mongod. En los registros aparece Killed y el código de salida es 137. Dos GB sólo bastan para evaluar el software con un par de usuarios de prueba.

¿Cómo coloco Rocket.Chat detrás de HTTPS?

Ejecute un reverse proxy en la misma VPS. El proxy debe terminar TLS y reenviar las peticiones a 127.0.0.1:3000. Configure ROOT_URL del contenedor con la dirección pública https://. El proxy debe reenviar las cabeceras de actualización de WebSocket. De lo contrario, el inicio de sesión se quedará bloqueado. Certbot con nginx es la configuración más sencilla para una sola aplicación. Traefik resulta más práctico si ejecuta varios contenedores detrás de un único proxy y quiere gestionar los certificados automáticamente.

¿Cómo hago una copia de seguridad de un Rocket.Chat autohospedado?

Cree un volcado coherente de la base de datos con mongodump en lugar de copiar el volumen: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Ese archivo contiene usuarios, canales, mensajes y ajustes. También incluye los archivos subidos si mantiene el almacenamiento en GridFS. Copie el archivo fuera del servidor. Automatice esta tarea cada noche con cron. Después, pruebe una mongorestore en un servidor desechable para confirmar que la restauración funciona realmente.

¿Cómo actualizo Rocket.Chat sin romper MongoDB?

Actualice Rocket.Chat una versión principal cada vez. Rocket.Chat ejecuta migraciones durante el arranque, y su documentación advierte que omitir versiones principales puede causar problemas graves de compatibilidad. No asuma que el proceso se detendrá para impedirlo. Lea las notas de cada versión antes de cambiar la etiqueta de imagen fijada. Compruebe qué versiones de MongoDB admite la versión de destino con curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Al actualizar MongoDB, avance una versión principal cada vez y establezca setFeatureCompatibilityVersion con confirm: true después de cada salto. Cree siempre una mongodump antes de empezar.

#rocket-chat #docker #docker-compose #mongodb #self-hosting #tls