Como instalar Rocket.Chat com Docker Compose

O que você vai criar

Um chat privado de equipa sob o seu controlo: Rocket.Chat a correr no seu próprio VPS com Docker Compose, com terminação TLS e todas as mensagens armazenadas numa base de dados MongoDB que pode salvaguardar e mover. O Rocket.Chat é uma alternativa open source madura ao Slack e ao Teams, com canais, mensagens diretas, threads, partilha de ficheiros e chamadas de voz e vídeo, tudo em hardware que arrenda e controla. No entanto, não é a única opção credível. Se ainda estiver a escolher, Mattermost, Rocket.Chat, Synapse e Zulip comparados apresenta as diferenças nos aspetos que causam problemas mais tarde: RAM, base de dados, notificações push em dispositivos móveis, SSO e atualizações. A aplicação é um único contentor que fica disponível em poucos minutos. Tudo o que realmente falha fica na base de dados ao lado, por isso a maior parte deste guia é dedicada ao MongoDB, em particular ao requisito que surpreende toda a gente na primeira utilização: o Rocket.Chat não funciona com um MongoDB autónomo. Precisa de um replica set, mesmo que esse "conjunto" tenha um único nó.

Pré-requisitos e a matemática da RAM que ninguém explica

Dimensione o servidor com realismo. O mínimo prático para uma equipa pequena é 2 vCPU e 4 GB de RAM. O processo Node.js do Rocket.Chat precisa de aproximadamente 1 a 1.5 GB por si só, e a cache WiredTiger do MongoDB usa por predefinição o maior valor entre 50% da (RAM total menos 1 GB) e 0.256 GB. Essa predefinição assume que mongod tem a máquina só para si: é calculada a partir da RAM total e não considera o que o Node já está a usar. Por isso, chega a 1.5 GB num servidor com 4 GB e a cerca de 0.5 GB num servidor com 2 GB. Isto é adicional à heap do Node, à memória própria do mongod fora da cache e à memória do sistema operativo. Num VPS com 2 GB, os dois cabem no arranque, mas entram em conflito assim que chega tráfego real: o MongoDB aumenta a cache, o Node aumenta a heap, o kernel fica sem páginas e o mecanismo de encerramento por falta de memória termina o processo maior, normalmente mongod. O contentor apresenta Killed, o Docker reinicia-o e o servidor de chat começa a desligar-se a cada poucos minutos sob uma carga que deveria suportar sem problemas. 2 GB são suficientes para testar o funcionamento com duas pessoas; não são suficientes para um servidor de equipa. Comece com 4 GB e use 8 GB se esperar dezenas de utilizadores em simultâneo, chamadas de vídeo ou um histórico de carregamentos em crescimento. Reserve também recursos para tudo o que o servidor tiver de executar: colocar um espaço de trabalho AFFiNE ao estilo do Notion no mesmo VPS adiciona mais quatro contentores a competir pelas mesmas páginas de memória, por isso a RAM deles deve ser adicionada à do Rocket.Chat, e não retirada dela.

Também precisa de ter três elementos preparados antes de começar. Um nome de domínio com um registo A a apontar para o IP público do VPS, porque as funcionalidades em tempo real do Rocket.Chat e os clientes móveis precisam de um nome de host estável, não de um IP isolado. As portas 80 e 443 abertas tanto na firewall do servidor como na firewall de rede do fornecedor, que é um controlo separado na maioria dos painéis. E um VPS KVM Ubuntu 24.04 novo, com root ou sudo. Se ainda estiver a decidir se um servidor de chat é o serviço certo para executar primeiro, o guia sobre o que vale a pena alojar em 2026 explica os compromissos envolvidos.

Instale o motor Docker e o plugin Compose

Use o repositório apt do próprio Docker, não o pacote docker.io que o Ubuntu disponibiliza nem o antigo binário autónomo docker-compose em Python. O Compose moderno é um plugin do Docker que deve ser invocado como docker compose, com um espaço, e não com um hífen. A versão antiga docker-compose v1 chegou ao fim da vida útil e processa incorretamente a sintaxe de healthcheck e de dependências apresentada abaixo.

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 os componentes estão disponíveis:

sudo docker version
sudo docker compose version

docker compose version imprimir uma linha de versão é a verificação relevante. As versões atuais imprimem Docker Compose version v5.x (v5.6.0, lançada em 2 de outubro de 2026, era a mais recente em 2026-10-10); uma instalação mais antiga pode ainda imprimir v2.x, e o Docker suporta ambas. O Docker descreve o Compose v5 como funcionalmente idêntico ao v2, numerado como v5 para evitar confusão com os formatos de ficheiro compose v2 e v3 legados, pelo que qualquer uma das versões serve para este guia. Se for apresentado o erro docker: 'compose' is not a docker command, o plugin não foi instalado e ocorrerão falhas difíceis de diagnosticar mais adiante. Corrija o problema agora.

O ficheiro compose: MongoDB como replica set de um único nó

Esta é a parte em que as pessoas mais se enganam, por isso leia com atenção. O Rocket.Chat usa change streams do MongoDB para enviar novas mensagens aos clientes ligados em tempo real, e os change streams só estão disponíveis num replica set. Aponte o Rocket.Chat para um mongod autónomo e ele vai ligar-se, falhar ao abrir um change stream e entrar num ciclo de reinícios. A correção não é complexa: execute um único contentor MongoDB normal, mas inicie-o com --replSet e depois inicialize um conjunto com um único membro.

Crie um diretório de trabalho e um 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:

Algumas escolhas aqui são deliberadas. A porta do Rocket.Chat é publicada em 127.0.0.1:3000, não em 0.0.0.0. A aplicação não tem TLS, por isso apenas o reverse proxy no mesmo servidor deve conseguir aceder-lhe; associá-la a todas as interfaces colocaria uma página de início de sessão sem encriptação diretamente na Internet pública. O MongoDB não é publicado no host; só pode ser acedido através da rede interna do Compose, com o nome mongodb, que é exatamente o hostname usado pelo MONGO_URL. MONGO_URL transporta ?replicaSet=rs0, que define explicitamente o nome do conjunto; o MongoDB recomenda configurá-lo para garantir um comportamento consistente entre drivers. Deixá-lo de fora não causa problemas por si só: directConnection assume o valor false, pelo que o driver continua a descobrir o replica set e a enviar operações para o primary, desde que o conjunto tenha sido iniciado com um hostname que o Rocket.Chat consiga resolver, algo que a próxima secção trata. MONGO_OPLOG_URL aponta para a base de dados local, onde fica o oplog; as versões modernas do Rocket.Chat preferem change streams, mas configurá-lo não causa problemas e mantém os caminhos de código mais antigos a funcionar. O depends_on usa condition: service_healthy, por isso o Compose espera que o MongoDB responda a um ping antes de iniciar o Rocket.Chat. É essa a finalidade do healthcheck.

Fixe tags de versão reais nas duas imagens, mongo:8.0 e uma versão explícita do Rocket.Chat, como 8.5.1 neste caso, e nunca use :latest. Essa opção transforma uma docker pull não supervisionada numa atualização acidental que não pode ser migrada. Verifique a versão estável atual do Rocket.Chat e as versões do MongoDB compatíveis antes de fixar as versões. O Rocket.Chat publica um documento de informações legível por máquinas para cada versão: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' devolve compatibleMongoVersions: ["8.0"] para a versão 8.5.1, pelo que mongo:8.0 é o único motor suportado, além de um sinalizador lts que indica se essa versão é uma build de suporte de longo prazo que vale a pena fixar num servidor que prefere não supervisionar continuamente. Nem todos os projetos publicam uma imagem versionada. Nesse caso, a fixação passa para o código-fonte: alojar o openGym workout tracker significa obter uma tag git específica e compilar a partir dela, em vez de seguir um branch que muda continuamente.

Inicialize o conjunto de réplicas

Inicie a stack:

sudo docker compose up -d

O Rocket.Chat começará a falhar imediatamente, e o Docker continuará a reiniciá-lo. Isso é esperado porque o conjunto de réplicas ainda não existe. Crie-o uma vez, manualmente:

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

O resultado correto é { ok: 1 }. Em poucos segundos, o nó único elege-se como primary. Confirme com:

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

Deve ver PRIMARY. O detalhe mais importante de toda esta página é o argumento host: "mongodb:27017". Se executar um rs.initiate() simples, sem uma lista de membros, o MongoDB anuncia o conjunto de réplicas usando o hostname interno do contentor, um hash aleatório como a1b2c3d4e5f6. O Rocket.Chat, ao ligar-se a partir do seu próprio contentor, não consegue resolver esse nome. Por isso, o driver do MongoDB falha a resolução DNS desse nome e fica num ciclo infinito, registando MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Inicialize sempre o conjunto com o nome explícito do serviço correspondente ao seu MONGO_URL.

Primeiro arranque: acompanhe a inicialização

Depois de o conjunto estar definido como primário, o próximo reinício do Rocket.Chat estabelece a ligação corretamente e inicia as migrações da primeira execução. Acompanhe os logs:

sudo docker compose logs -f rocketchat

A linha que deve aguardar é o banner de arranque:

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

O primeiro arranque é lento. A aplicação executa migrações da base de dados e cria índices, por isso aguarde um ou dois minutos antes de investigar. Se o log repetir MongoServerSelectionError: Server selection timed out after 30000 ms com uma descrição da topologia do tipo ReplicaSetNoPrimary, o conjunto de réplicas não foi iniciado. Se repetir getaddrinfo ENOTFOUND com um hash aleatório, foi iniciado com o host incorreto. Em qualquer dos casos, volte um passo. Quando vir SERVER RUNNING, o Rocket.Chat estará a escutar em 127.0.0.1:3000 e será altura de colocar um nome de host real e TLS à frente dele.

Coloque-o atrás de TLS

Nunca exponha o Rocket.Chat através de HTTP simples. Depois de iniciar sessão em http://, a sua palavra-passe de administrador fica disponível para qualquer pessoa no caminho da ligação. Termine o TLS num reverse proxy no mesmo servidor e encaminhe para 127.0.0.1:3000. Há dois pontos importantes: o proxy tem de encaminhar os cabeçalhos de atualização do WebSocket, porque o Rocket.Chat funciona em tempo real e deixa de funcionar sem eles; e o ROOT_URL do contentor tem de corresponder exatamente ao endereço HTTPS público introduzido pelos utilizadores.

Comece com um bloco de servidor HTTP simples do nginx que faça proxy para a aplicação e encaminhe os cabeçalhos de atualização. Guarde-o como /etc/nginx/sites-available/rocketchat, crie um link simbólico para sites-enabled e recarregue a configuração:

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

Deixe-o na porta 80 por agora. Um bloco com listen 443 ssl; e sem certificado nem sequer passa sudo nginx -t. Recarregue o nginx (sudo nginx -t && sudo systemctl reload nginx) e depois emita o certificado. No Ubuntu, a opção mais simples é Certificados TLS Let's Encrypt com Certbot e nginx: certbot --nginx reescreve o bloco anterior no próprio local, adicionando listen 443 ssl;, as linhas ssl_certificate e um redirecionamento automático de 80 para 443. Também agenda a renovação automaticamente. Se já executar vários contentores atrás de um único proxy, Traefik com TLS automático para várias aplicações Docker é a opção mais organizada. Adicione etiquetas de router e serviço ao serviço rocketchat, e o Traefik solicita e renova o certificado automaticamente, sem qualquer bloco do nginx. Em qualquer dos casos, defina ROOT_URL como https://chat.example.com em compose.yml e execute novamente sudo docker compose up -d para que o contentor aplique a alteração. Se quiser que o servidor seja acessível apenas a partir da sua própria rede, e não da Internet pública, coloque à frente uma VPN WireGuard auto-hospedada no VPS e associe o proxy ao endereço do túnel.

O assistente de configuração inicial

Aceda a https://chat.example.com e o Rocket.Chat orienta-o através de um assistente curto. Primeiro, a conta de administrador, o nome real, o nome de utilizador, o email e uma palavra-passe forte; esta é a única conta existente, por isso não a perca. Depois, as informações da organização e do servidor, como o nome, o setor, a dimensão, o nome do site e o idioma predefinido; são apenas elementos visuais, preencha-os e avance. Em seguida, surge a escolha que realmente importa: registar este workspace no Rocket.Chat Cloud ou mantê-lo autónomo.

O registo ativa as notificações push móveis através do gateway do Rocket.Chat e o marketplace de add-ons, mas cria uma relação com o plano de controlo na cloud do Rocket.Chat; as notificações push enviadas através do gateway também contam para o limite mensal do workspace. O modo autónomo mantém o servidor totalmente privado e sem dependências externas, mas as aplicações oficiais para iOS e Android deixam de receber notificações push, porque a documentação do Rocket.Chat indica que essas aplicações só funcionam com o gateway cloud e que o gateway não funciona num workspace não registado. A alternativa é criar a sua própria versão personalizada da aplicação móvel: desative o gateway nas definições de Push, introduza os seus próprios certificados APNs e as credenciais do Firebase Cloud Messaging e peça aos utilizadores que instalem a sua aplicação em vez da aplicação oficial. Escolha o modo autónomo se a privacidade for o principal objetivo e os seus utilizadores utilizarem a aplicação Web, ou se estiver preparado para distribuir a sua própria aplicação móvel; escolha o registo se as notificações push nas aplicações oficiais forem indispensáveis. Pode alterar esta opção mais tarde em Admin.

Bloqueie o acesso antes de convidar alguém

O Rocket.Chat é distribuído com o registo aberto ativado. Por predefinição, o Registration Form está definido como Public, por isso qualquer pessoa que encontre o URL pode criar uma conta. Num hostname público, isso permite o acesso a qualquer pessoa. Aceda a Admin → Settings → Accounts → Registration e defina Registration Form como Disabled, para criar contas manualmente ou através de um link de convite, ou como Secret URL. Enquanto estiver nessa secção, desative Allow Anonymous Read e Allow Anonymous Write, exceto se pretender especificamente um canal público apenas de leitura. Se criar cada conta manualmente parecer trabalhoso e este não for o único serviço em que a sua equipa inicia sessão, configure o login OAuth do Rocket.Chat para usar um servidor SSO Authentik autoalojado. Assim, as entradas e saídas de utilizadores são geridas uma vez, num único local, em vez de aplicação por aplicação.

Defina também o destino dos uploads. O armazenamento predefinido de File Upload é o GridFS, que guarda cada imagem e anexo dentro do próprio MongoDB. É simples, mas significa que a base de dados, e todas as mongodump que fizer, aumenta sem limite à medida que as pessoas colam capturas de ecrã. Em Admin → Settings → File Upload, pode mudar o armazenamento para o sistema de ficheiros local ou para um bucket compatível com S3, e definir um tamanho máximo de ficheiro razoável. Se a sua equipa troca bibliotecas fotográficas completas em vez de capturas de ecrã ocasionais, esses ficheiros devem ficar num servidor de fotografias dedicado, não numa base de dados de chat. A comparação entre PhotoPrism e Immich avalia o custo de cada opção em RAM e os comandos de backup necessários. Para uma equipa pequena, o GridFS é adequado; tenha apenas em conta que os backups ficam maiores com o tempo.

Backups com mongodump

Todos os seus dados estão no volume mongodb_data. Não copie o volume enquanto a base de dados está em execução. Crie um dump consistente com mongodump, transmitido para um ficheiro no host:

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

Esse único arquivo compactado com gzip contém todo o seu workspace: utilizadores, canais, mensagens, definições e, se deixou os uploads no GridFS, também os ficheiros. Se moveu os uploads para o sistema de ficheiros ou para o S3, faça uma cópia de segurança desse armazenamento separadamente. Restaure numa stack nova inicializando primeiro o replica set e, em seguida:

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

Copie o arquivo para fora do servidor, para armazenamento de objetos, outro servidor ou qualquer local em que a falha do VPS não destrua também a cópia de segurança. Execute o dump todas as noites pelo cron. Uma cópia de segurança que nunca foi restaurada é uma expectativa, não uma cópia de segurança. Teste o restauro uma vez num VPS descartável para confirmar que funciona antes de precisar dele.

Atualizações: fixe as tags, leia as notas e respeite a matriz do MongoDB

Duas regras tornam as atualizações previsíveis. Primeiro, atualize o Rocket.Chat uma versão principal de cada vez. O Rocket.Chat executa migrações do esquema durante o arranque, e a documentação de atualização do Rocket.Chat indica que as versões principais devem ser atualizadas sequencialmente. Ignorar versões principais pode causar problemas graves de compatibilidade. Não conte com o software para impedir isso: a documentação não garante que um salto direto de 6.x para 8.x seja recusado de forma segura, e uma migração que falhe a meio deixa o conjunto de bloqueios ativo e exige reparação manual. Altere a tag da imagem para a versão mais recente da próxima versão principal, leia as notas dessa versão para identificar alterações incompatíveis, execute docker compose up -d e monitorize os logs até a migração terminar antes de prosseguir. Segundo, respeite a matriz de suporte do MongoDB. Cada versão do Rocket.Chat suporta um conjunto específico de versões do MongoDB, e curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions mostra quais são. Quando atualizar o MongoDB, por exemplo, de 7.0 para 8.0, avance uma versão principal de cada vez e defina a versão de compatibilidade de funcionalidades depois de cada salto. No MongoDB 8.0, esse comando exige um confirm: true explícito; caso contrário, falha com uma mensagem que indica para o executar novamente com a flag de confirmação:

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

Faça um mongodump antes de cada atualização de qualquer um dos componentes. Essa é toda a proteção necessária.

Modos de falha, com as strings exatas

Os contentores do Rocket.Chat entram em ciclos de reinício logo depois de docker compose up, e docker compose logs rocketchat fica preenchido com um MongoServerSelectionError. O MongoDB está em execução, mas o driver não consegue selecionar um primary, e a string exata indica qual foi o erro. Server selection timed out after 30000 ms com um tipo de topologia ReplicaSetNoPrimary significa que nunca executou rs.initiate(); o conjunto ainda não tem configuração. getaddrinfo ENOTFOUND seguido de um hash aleatório significa que iniciou sem o host: "mongodb:27017" explícito, e o MongoDB anunciou um nome de host de contentor que não pode ser resolvido. Diagnostique com sudo docker compose exec mongodb mongosh --eval 'rs.status()': se devolver o erro MongoServerError: no replset config has been received, inicie o conjunto; se mostrar um membro cujo name é um hash aleatório, inicie novamente usando o nome do serviço.

A interface web carrega, mas o início de sessão fica em carregamento e nunca termina. Abra a consola do browser e verá WebSocket connection to 'wss://chat.example.com/websocket' failed. Isto quase sempre é uma incompatibilidade de ROOT_URL ou um proxy que não encaminha os cabeçalhos de upgrade. Confirme que ROOT_URL corresponde ao endereço público exato, incluindo https://, e que o bloco location do nginx define Upgrade e Connection "upgrade" com proxy_http_version 1.1. Altere um dos dois e execute novamente docker compose up -d.

Um contentor continua a terminar e docker compose ps mostra Restarting. docker compose logs é interrompido a meio da linha e sudo dmesg | tail mostra Out of memory: Killed process 12345 (mongod) do oom-killer; o código de saída é 137. O servidor ficou sem RAM. A correção real é usar um VPS maior, com 4 GB no mínimo. Como medida temporária, adicione swap e limite a cache do MongoDB com --wiredTigerCacheSizeGB no respetivo command. Defina um valor inferior ao predefinido, não superior; por exemplo, 1 num servidor com 4 GB (predefinição 1.5) ou 0.3 num servidor com 2 GB (predefinição de cerca de 0.5). No entanto, o swap apenas atrasa o próximo OOM sob carga real:

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

docker compose up falha com Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Algo já está a usar a porta 3000, normalmente um contentor anterior do Rocket.Chat que não terminou corretamente ou outra aplicação. Localize-o com sudo ss -ltnp | grep :3000, pare esse processo ou contentor, ou altere o lado do host do mapeamento para 127.0.0.1:3001:3000 e atualize proxy_pass no proxy para corresponder.

FAQ

O Rocket.Chat precisa mesmo de um replica set do MongoDB?

Sim, mesmo num único servidor com um só nó de base de dados. O Rocket.Chat entrega mensagens em tempo real através de change streams do MongoDB, e os change streams só estão disponíveis em replica sets; um mongod standalone não pode abrir um. Não precisa de várias máquinas. Execute um único contentor MongoDB iniciado com --replSet rs0 e inicialize um conjunto com um membro usando rs.initiate(). Se ignorar esse passo, o driver nunca encontra um primary. O Rocket.Chat entra num ciclo de reinícios com MongoServerSelectionError: Server selection timed out e nunca conclui o arranque.

De quanta RAM precisa uma instalação self-hosted do Rocket.Chat?

Planeie 4 GB como mínimo prático e 8 GB para uma equipa com utilização intensa. O processo Node do Rocket.Chat usa cerca de 1 a 1,5 GB, e a cache WiredTiger predefinida do MongoDB corresponde a metade da RAM total menos 1 GB, como se não estivesse mais nada a executar no servidor. Num servidor com 2 GB, essa cache, a heap do Node e a sobrecarga do próprio mongod entram em conflito. O out-of-memory killer termina o mongod com qualquer carga real, apresenta Killed nos logs e devolve o código de saída 137. Dois GB só são suficientes para avaliar o software com alguns utilizadores de teste.

Como coloco o Rocket.Chat atrás de HTTPS?

Execute um reverse proxy no mesmo VPS para terminar o TLS e encaminhar as ligações para 127.0.0.1:3000. Defina o ROOT_URL do contentor com o endereço https:// público. O proxy tem de encaminhar os cabeçalhos de upgrade do WebSocket. Caso contrário, o início de sessão fica bloqueado. Certbot com nginx é a configuração mais simples para uma única aplicação. Traefik é mais prático se executar vários contentores atrás de um proxy e quiser gerir os certificados automaticamente.

Como faço uma cópia de segurança de uma instalação self-hosted do Rocket.Chat?

Faça um dump consistente da base de dados com mongodump em vez de copiar o volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Esse arquivo contém utilizadores, canais, mensagens e definições, além dos ficheiros carregados, se tiver mantido o armazenamento no GridFS. Copie o arquivo para fora do servidor, automatize a execução todas as noites com cron e teste uma mongorestore num servidor descartável. Assim confirma que o restauro funciona realmente.

Como atualizo o Rocket.Chat sem causar problemas no MongoDB?

Atualize o Rocket.Chat uma versão principal de cada vez. O Rocket.Chat executa migrações durante o arranque, e a documentação alerta que saltar versões principais pode causar problemas graves de compatibilidade. Não conte com o sistema para impedir esse procedimento. Leia as notas de cada versão antes de alterar a tag de imagem fixada. Verifique quais versões do MongoDB são compatíveis com a versão de destino usando curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Ao atualizar o MongoDB, avance uma versão principal de cada vez e defina setFeatureCompatibilityVersion com confirm: true depois de cada atualização. Faça sempre primeiro uma mongodump.