Installare Rocket.Chat con Docker Compose: guida completa

Cosa stai realizzando

Una chat di team privata di cui detieni il controllo totale: Rocket.Chat in esecuzione su una tua VPS tramite Docker Compose, con terminazione TLS e ogni messaggio archiviato in un database MongoDB che puoi sottoporre a backup e migrare. Rocket.Chat è l'alternativa open source matura a Slack e Teams, dotata di canali, messaggi diretti, thread, condivisione file, oltre a chiamate vocali e video, il tutto su hardware che noleggi e controlli. Non è l'unica opzione valida; se sei ancora in fase di valutazione, Confronto tra Mattermost, Rocket.Chat, Synapse e Zulip li mette a confronto sugli aspetti critici a lungo termine: RAM, database, notifiche push mobile, SSO e aggiornamenti. L'applicazione è un singolo container che si avvia in pochi minuti. Tutto ciò che può effettivamente causare problemi risiede nel database adiacente, pertanto gran parte di questa guida riguarda MongoDB e, in particolare, il requisito che sorprende chiunque la prima volta: Rocket.Chat non può essere eseguito con un'istanza MongoDB standalone. Richiede un replica set, anche se tale "set" è composto da un singolo nodo.

Prerequisiti e i calcoli sulla RAM che nessuno ti spiega

Dimensiona il server in modo onesto. Il limite minimo realistico per un piccolo team è 2 vCPU e 4 GB di RAM. Il processo Node.js di Rocket.Chat richiede da solo circa 1 - 1,5 GB, mentre la cache WiredTiger di MongoDB utilizza per impostazione predefinita il valore maggiore tra il 50% della (RAM totale meno 1 GB) o 0,256 GB. Tale impostazione predefinita presuppone che mongod abbia la macchina a sua completa disposizione: viene calcolata sulla RAM totale senza considerare quanta ne stia già occupando Node. Di conseguenza, su una macchina da 4 GB occupa 1,5 GB, mentre su una da 2 GB ne occupa circa 0,5 GB, che vanno a sommarsi all'heap di Node, alla memoria di mongod al di fuori della cache e al sistema operativo. Su una VPS da 2 GB, i due processi convivono all'avvio ma entrano in conflitto non appena arriva traffico reale: MongoDB espande la cache, Node espande l'heap, il kernel esaurisce le pagine di memoria e l'out-of-memory killer termina il processo più grande, solitamente mongod. Il container stampa Killed, Docker lo riavvia e si ottiene un server di chat che si interrompe ogni pochi minuti sotto un carico che dovrebbe gestire senza problemi. 2 GB vanno bene per testare il software con due persone; non sono adatti per un server di team. Parti da 4 GB e passa a 8 GB se prevedi decine di utenti simultanei, videochiamate o una cronologia dei caricamenti in crescita. Considera anche il budget di memoria per qualsiasi altro servizio ospitato sulla macchina: installare un workspace AFFiNE in stile Notion sulla stessa VPS aggiunge altri quattro container che competono per le stesse pagine di memoria, quindi la loro RAM deve essere aggiunta a quella di Rocket.Chat, non sottratta.

Prima di iniziare, devi disporre di tre elementi. Un nome di dominio con un record A che punti all'IP pubblico della VPS; le funzionalità in tempo reale e i client mobile di Rocket.Chat richiedono un hostname stabile, non un semplice indirizzo IP. Porte 80 e 443 aperte sia sul firewall del server che sul firewall di rete del provider, che nella maggior parte dei pannelli di controllo è un'impostazione separata. Infine, una VPS Ubuntu 24.04 KVM pulita con accesso root o sudo. Se stai ancora valutando se un server di chat sia il servizio giusto da gestire autonomamente, la guida su cosa vale la pena ospitare in proprio nel 2026 illustra i compromessi necessari.

Installazione del motore Docker e del plugin Compose

Utilizzare il repository apt ufficiale di Docker, non il pacchetto docker.io fornito da Ubuntu e non l'obsoleto binario Python standalone docker-compose. Il Compose moderno è un plugin Docker che si invoca come docker compose, con uno spazio anziché un trattino. Il vecchio docker-compose v1 è fuori supporto e gestisce in modo errato la sintassi degli healthcheck e delle dipendenze riportata di seguito.

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

Verificare che entrambi i componenti siano presenti:

sudo docker version
sudo docker compose version

docker compose version che stampa una riga di versione è il controllo fondamentale. Le release attuali stampano Docker Compose version v5.x (la v5.6.0, rilasciata il 2 ottobre 2026, era l'ultima disponibile al 2026-10-10); un'installazione meno recente potrebbe ancora stampare v2.x, ed entrambi sono supportati da Docker. Docker descrive Compose v5 come funzionalmente identico alla v2, numerato v5 per evitare confusione con i formati legacy dei file compose v2 e v3, quindi entrambi sono validi per questa guida. Se viene restituito l'errore docker: 'compose' is not a docker command, il plugin non è stato installato e si verificheranno errori di difficile interpretazione in seguito; risolvere il problema in questa fase.

Il file compose: MongoDB come replica set a nodo singolo

Questa è la parte in cui molti sbagliano, quindi leggila con attenzione. Rocket.Chat utilizza i change stream di MongoDB per inviare nuovi messaggi ai client connessi in tempo reale; i change stream sono disponibili solo su un replica set. Se punti Rocket.Chat verso un'istanza MongoDB standalone mongod, il servizio si connetterà, non riuscirà ad aprire un change stream e rimarrà bloccato in un ciclo di riavvii infiniti. La soluzione non è complessa: esegui un normale container MongoDB, ma lo avvii con --replSet e successivamente inizializzi un set composto da un solo membro.

Crea una directory di lavoro e 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:

Alcune scelte qui sono deliberate. La porta di Rocket.Chat è pubblicata su 127.0.0.1:3000, non su 0.0.0.0; l'applicazione stessa non gestisce TLS, quindi solo il reverse proxy sulla stessa macchina dovrebbe potervi accedere. Associare il servizio a tutte le interfacce esporrebbe una pagina di login in chiaro direttamente su Internet. MongoDB non è pubblicato sull'host; è raggiungibile solo tramite la rete interna di Compose con il nome mongodb, che è esattamente l'hostname utilizzato da MONGO_URL. MONGO_URL contiene ?replicaSet=rs0, che assegna un nome esplicito al set; MongoDB raccomanda di impostarlo per garantire un comportamento coerente tra i vari driver. Ometterlo non causa guasti immediati: directConnection utilizza false come valore predefinito, quindi il driver rileva comunque il replica set e invia le operazioni al nodo primario, a patto che il set sia stato inizializzato con un hostname risolvibile da Rocket.Chat, aspetto che verrà trattato nella prossima sezione. MONGO_OPLOG_URL punta al database local dove risiede l'oplog; le versioni moderne di Rocket.Chat preferiscono i change stream, ma impostare questo parametro è innocuo e mantiene compatibili i percorsi di codice più datati. Il depends_on utilizza condition: service_healthy, quindi Compose attende che MongoDB risponda a un ping prima di avviare Rocket.Chat; questo è lo scopo dell'healthcheck.

Blocca le versioni reali su entrambe le immagini, usando mongo:8.0 e una release esplicita di Rocket.Chat come 8.5.1 in questo esempio, e non usare mai :latest, che trasformerebbe un docker pull incustodito in un aggiornamento accidentale e non reversibile. Verifica la release stabile corrente di Rocket.Chat e le versioni di MongoDB supportate prima di bloccare le versioni. Rocket.Chat pubblica un documento informativo leggibile dalle macchine per ogni release: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' restituisce compatibleMongoVersions: ["8.0"] per la versione 8.5.1, indicando che mongo:8.0 è l'unico motore supportato, oltre a un flag lts che indica se quella release è una build a supporto a lungo termine (LTS), ideale per un server che preferisci non dover monitorare costantemente. Non tutti i progetti pubblicano un'immagine con versione specifica; in tal caso, il blocco si sposta sul codice sorgente: self-hosting del tracker di allenamento openGym significa effettuare il checkout di un tag git specifico e compilare da quello, invece di seguire un branch in continua evoluzione.

Inizializzazione del replica set

Avviare lo stack:

sudo docker compose up -d

Rocket.Chat subirà un crash immediato e Docker continuerà a riavviarlo; questo comportamento è previsto poiché il replica set non esiste ancora. Crearlo manualmente una sola volta:

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

Un risultato corretto è { ok: 1 }. Entro pochi secondi il singolo nodo si elegge come primary; verificare con:

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

Il risultato atteso è PRIMARY. Il dettaglio più importante di questa intera pagina è l'argomento host: "mongodb:27017". Se si esegue un comando rs.initiate() nudo, senza l'elenco dei membri, MongoDB annuncia il replica set utilizzando l'hostname interno del container, ovvero un hash casuale come a1b2c3d4e5f6. Rocket.Chat, connettendosi dal proprio container, non è in grado di risolvere tale nome; di conseguenza, il driver MongoDB fallisce la risoluzione DNS e rimane in un ciclo infinito registrando MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Inizializzare sempre utilizzando il nome del servizio esplicito che corrisponde al proprio MONGO_URL.

Primo avvio: monitorare l'inizializzazione

Una volta che il set è primario, il riavvio successivo di Rocket.Chat si connette correttamente e avvia le migrazioni del primo avvio. Monitorare i log:

sudo docker compose logs -f rocketchat

La riga da attendere è il banner di avvio:

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

Il primo avvio è lento, poiché l'applicazione esegue le migrazioni del database e crea gli indici; attendere un paio di minuti prima di preoccuparsi. Se il log ripete invece MongoServerSelectionError: Server selection timed out after 30000 ms con una descrizione della topologia di tipo ReplicaSetNoPrimary, il replica set non è stato inizializzato; se ripete getaddrinfo ENOTFOUND su un hash casuale, è stato inizializzato con l'host errato. In entrambi i casi, tornare al passaggio precedente. Una volta visualizzato SERVER RUNNING, Rocket.Chat è in ascolto sulla porta 127.0.0.1:3000 ed è il momento di configurare un hostname reale e TLS davanti ad esso.

Protezione tramite TLS

Non esporre mai Rocket.Chat su HTTP non cifrato. Effettuare il login tramite http:// una sola volta significa consegnare la propria password di amministratore a chiunque si trovi sul percorso. Termina il TLS in un reverse proxy sulla stessa macchina e inoltra il traffico a 127.0.0.1:3000. Due aspetti sono fondamentali: il proxy deve inoltrare gli header di upgrade dei WebSocket, poiché Rocket.Chat è un'applicazione in tempo reale che smette di funzionare senza di essi, e la variabile ROOT_URL del container deve corrispondere esattamente all'indirizzo HTTPS pubblico digitato dagli utenti.

Inizia con un blocco server nginx HTTP semplice che esegua il proxy verso l'applicazione e inoltri gli header di upgrade. Salvalo come /etc/nginx/sites-available/rocketchat, crea un link simbolico in sites-enabled e ricarica:

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

Lascialo sulla porta 80 per il momento; un blocco con listen 443 ssl; privo di certificato non supererà nemmeno il sudo nginx -t. Ricarica nginx (sudo nginx -t && sudo systemctl reload nginx), quindi emetti il certificato. Il percorso più pulito su Ubuntu è Certificati TLS Let's Encrypt con Certbot e nginx: certbot --nginx riscrive il blocco precedente sul posto, aggiungendo listen 443 ssl;, le righe ssl_certificate e un redirect automatico da 80 a 443, pianificando inoltre il rinnovo per te. Se gestisci già diversi container dietro un unico proxy, Traefik con TLS automatico per molte app Docker è l'opzione più ordinata: aggiungi le etichette di router e service al servizio rocketchat e Traefik richiederà e rinnoverà il certificato per te, senza alcun blocco nginx. In ogni caso, imposta ROOT_URL su https://chat.example.com in compose.yml ed esegui nuovamente sudo docker compose up -d affinché il container recepisca la modifica. Se desideri che il server sia raggiungibile solo dall'interno della tua rete anziché da Internet, anteponi una VPN WireGuard self-hosted sulla VPS e associa il proxy all'indirizzo del tunnel.

La procedura guidata di configurazione iniziale

Naviga su https://chat.example.com e Rocket.Chat ti guiderà attraverso una breve procedura di configurazione. Per prima cosa, crea l'account amministratore, inserendo nome reale, nome utente, email e una password sicura; questo è l'unico account esistente, quindi non perderlo. Successivamente, inserisci le informazioni sull'organizzazione e sul server: nome, settore, dimensioni, nome del sito e lingua predefinita; sono dati puramente estetici, compilali e prosegui. Infine, la scelta che conta davvero: registrare questo workspace con Rocket.Chat Cloud, oppure mantenerlo standalone.

La registrazione abilita le notifiche push mobile tramite il gateway di Rocket.Chat e l'accesso al marketplace dei componenti aggiuntivi, al costo di una relazione di controllo con il cloud di Rocket.Chat; le notifiche inviate tramite il gateway concorrono inoltre al raggiungimento del limite mensile del tuo workspace. La modalità standalone mantiene il server completamente privato e privo di dipendenze, ma le app ufficiali per iOS e Android smettono di ricevere notifiche push, poiché la documentazione di Rocket.Chat specifica che tali app funzionano solo con il gateway cloud e il gateway non viene eseguito su un workspace non registrato. La soluzione alternativa consiste nel creare una propria build white-label dell'app mobile: disattiva il gateway nelle impostazioni Push, inserisci i tuoi certificati APNs e le credenziali Firebase Cloud Messaging, e fai installare ai tuoi utenti la tua app invece di quella ufficiale. Scegli standalone se la privacy è l'obiettivo principale e i tuoi utenti utilizzano l'app web, oppure se sei pronto a distribuire la tua app mobile; scegli la registrazione se le notifiche push sulle app ufficiali sono un requisito imprescindibile. Puoi cambiare idea in seguito nella sezione Admin.

Metti in sicurezza il sistema prima di invitare chiunque

Rocket.Chat viene rilasciato con la registrazione aperta attiva; per impostazione predefinita, il modulo di registrazione è impostato su Public, quindi chiunque trovi l'URL può creare un account. Su un hostname pubblico, questo rappresenta una porta aperta. Vai su Amministrazione → Impostazioni → Account → Registrazione e imposta Modulo di registrazione su Disabled, in modo da creare gli account manualmente o tramite link di invito, oppure su Secret URL. Mentre sei lì, disattiva Consenti lettura anonima e Consenti scrittura anonima, a meno che tu non voglia specificamente un canale pubblico in sola lettura. Se creare ogni account manualmente ti sembra noioso e questo non è l'unico servizio a cui il tuo team accede, punta il login OAuth di Rocket.Chat verso un server SSO Authentik self-hosted, così che le nuove assunzioni e le uscite vengano gestite una sola volta in un unico punto, invece che applicazione per applicazione.

Decidi anche dove archiviare i caricamenti. L'archiviazione predefinita per il Caricamento file è GridFS, che salva ogni immagine e allegato direttamente all'interno di MongoDB. È una soluzione semplice, ma significa che il tuo database, e ogni mongodump che esegui, cresce senza limiti man mano che gli utenti incollano screenshot. Sotto Amministrazione → Impostazioni → Caricamento file puoi cambiare l'archiviazione verso il file system locale o un bucket compatibile con S3, e impostare una dimensione massima del file ragionevole. Se il tuo team si scambia intere librerie fotografiche invece di qualche occasionale screenshot, questi file appartengono a un server fotografico dedicato piuttosto che a un database di chat, e il confronto tra PhotoPrism e Immich valuta quanto costa ciascuno in termini di RAM rispetto ai comandi di backup necessari. Per un piccolo team GridFS va bene; tieni solo presente che i tuoi backup diventeranno più pesanti nel tempo.

Backup con mongodump

Tutti i tuoi dati risiedono nel volume mongodb_data. Non limitarti a copiare il volume mentre il database è in esecuzione; esegui un dump coerente con mongodump, inviandolo tramite stream a un file sull'host:

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

Quell'unico archivio compresso con gzip costituisce l'intero spazio di lavoro: utenti, canali, messaggi, impostazioni e, se hai lasciato i caricamenti su GridFS, anche i file. Se hai spostato i caricamenti sul file system o su S3, esegui il backup di tale archivio di caricamenti separatamente. Ripristina su uno stack pulito inizializzando prima il replica set, quindi:

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

Copia l'archivio fuori dalla macchina, su uno storage a oggetti, un altro server o ovunque il guasto del VPS non comporti la perdita del backup, ed esegui il dump tramite cron ogni notte. Un backup che non hai mai ripristinato è solo una speranza, non un backup; prova la procedura di ripristino una volta su un VPS usa e getta, così da verificare che funzioni prima di averne realmente bisogno.

Aggiornamenti: bloccare i tag, leggere le note, rispettare la matrice di Mongo

Due regole rendono gli aggiornamenti privi di complicazioni. Primo, aggiornare Rocket.Chat una major version alla volta. Il software esegue migrazioni dello schema all'avvio e la documentazione di Rocket.Chat prescrive di aggiornare sempre in sequenza tra le major version, avvertendo che saltarle può causare gravi problemi di compatibilità. Non fare affidamento sul software per bloccare l'operazione: nulla nella documentazione garantisce che un salto diretto dalla 6.x alla 8.x venga rifiutato in sicurezza; una migrazione che fallisce a metà lascia il lock attivo e richiede una riparazione manuale. Aggiorna il tag dell'immagine all'ultima release della major successiva, leggi le note di quella release per eventuali modifiche incompatibili, esegui docker compose up -d e monitora i log finché la migrazione non è completata prima di procedere. Secondo, rispettare la matrice di supporto di MongoDB. Ogni release di Rocket.Chat supporta uno specifico set di versioni di MongoDB e curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions indica quali. Quando si aggiorna MongoDB, ad esempio dalla 7.0 alla 8.0, procedi una major version alla volta e imposta la versione di compatibilità delle funzionalità (feature-compatibility version) dopo ogni passaggio. Su MongoDB 8.0 quel comando richiede un esplicito confirm: true, altrimenti viene rifiutato con un messaggio che richiede di rieseguirlo con il flag di conferma:

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

Esegui un mongodump prima di ogni aggiornamento di entrambi i componenti. Questa è l'unica vera polizza assicurativa.

Modalità di errore, con le stringhe esatte

Rocket.Chat entra in un loop di riavvio subito dopo docker compose up, e docker compose logs rocketchat si riempie con un MongoServerSelectionError. MongoDB è in esecuzione ma il driver non riesce a selezionare un nodo primario, e la stringa esatta indica l'errore commesso. Server selection timed out after 30000 ms con un tipo di topologia ReplicaSetNoPrimary significa che non è mai stato eseguito rs.initiate(), il set non ha ancora una configurazione. getaddrinfo ENOTFOUND seguito da un hash casuale significa che è stata eseguita l'inizializzazione senza il parametro esplicito host: "mongodb:27017", quindi MongoDB ha annunciato un hostname del container non risolvibile. Diagnosticare con sudo docker compose exec mongodb mongosh --eval 'rs.status()': se restituisce l'errore MongoServerError: no replset config has been received, inizializzare il set; se mostra un membro il cui name è un hash casuale, reinizializzare usando il nome del servizio.

L'interfaccia web si carica ma il login rimane in caricamento infinito e non si completa mai. Aprire la console del browser per visualizzare WebSocket connection to 'wss://chat.example.com/websocket' failed. Questo è quasi sempre un disallineamento di ROOT_URL o un proxy che non inoltra gli header di upgrade. Verificare che ROOT_URL corrisponda esattamente all'indirizzo pubblico, incluso https://, e che il blocco location di nginx imposti Upgrade e Connection "upgrade" con proxy_http_version 1.1. Modificare uno dei due parametri e rieseguire docker compose up -d.

Un container continua a terminare e docker compose ps mostra che Restarting. docker compose logs si interrompe a metà riga e sudo dmesg | tail mostra Out of memory: Killed process 12345 (mongod) da parte dell'oom-killer; il codice di uscita è 137. Il server ha esaurito la RAM. La soluzione definitiva è una VPS più grande, minimo 4 GB. Come soluzione temporanea, aggiungere swap e limitare la cache di MongoDB con --wiredTigerCacheSizeGB nel suo command, impostando un valore inferiore a quello predefinito anziché superiore, ad esempio 1 su una macchina da 4 GB (predefinito 1.5) o 0.3 su una da 2 GB (predefinito circa 0.5), ma lo swap ritarda solo il prossimo OOM sotto carico reale:

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

docker compose up fallisce con Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Qualcosa sta già occupando la porta 3000, spesso un precedente container Rocket.Chat che non si è arrestato correttamente, o un'altra applicazione. Individuare il processo con sudo ss -ltnp | grep :3000, arrestare tale processo o container, oppure modificare il lato host del mapping in 127.0.0.1:3001:3000 e aggiornare il proxy_pass del proxy di conseguenza.

FAQ

Rocket.Chat richiede davvero un replica set di MongoDB?

Sì, anche per un singolo server con un solo nodo di database. Rocket.Chat invia messaggi in tempo reale utilizzando i change stream di MongoDB; i change stream sono una funzionalità esclusiva dei replica set, pertanto una configurazione standalone mongod non può aprirne uno. Non sono necessarie più macchine: è sufficiente eseguire un container MongoDB avviato con --replSet rs0 e inizializzare un set a membro singolo con rs.initiate(). Se si salta questo passaggio, il driver non troverà mai un nodo primary e Rocket.Chat entrerà in un loop di riavvio con MongoServerSelectionError: Server selection timed out, senza mai completare l'avvio.

Quanta RAM richiede un'istanza self-hosted di Rocket.Chat?

È necessario pianificare 4 GB come minimo pratico e 8 GB per un team attivo. Il processo Node di Rocket.Chat utilizza circa 1 - 1,5 GB, mentre la cache WiredTiger predefinita di MongoDB occupa la metà della RAM totale (meno 1 GB), calcolata come se non ci fosse altro in esecuzione sul sistema. Su una macchina da 2 GB, quella cache, l'heap di Node e l'overhead di mongod entrano in conflitto; l'out-of-memory killer termina mongod sotto carico, mostrando Killed nei log e il codice di uscita 137. Due GB sono sufficienti solo per valutare il software con un paio di utenti di test.

Come posso configurare Rocket.Chat dietro HTTPS?

Esegui un reverse proxy sulla stessa VPS che termini il TLS e inoltri il traffico a 127.0.0.1:3000, quindi imposta la variabile ROOT_URL del container sul tuo indirizzo https:// pubblico. Il proxy deve inoltrare gli header di upgrade WebSocket, altrimenti il login rimarrà bloccato. Certbot con nginx è la configurazione più semplice per una singola applicazione; Traefik è più pulito se si eseguono diversi container dietro un unico proxy e si desidera la gestione automatica dei certificati.

Come posso eseguire il backup di un'istanza self-hosted di Rocket.Chat?

Esegui un dump coerente del database con mongodump invece di copiare il volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Quell'archivio contiene utenti, canali, messaggi e impostazioni, oltre ai file caricati se hai lasciato lo storage su GridFS. Copia il file fuori dal server, automatizza l'operazione ogni notte con cron e prova un mongorestore su una macchina di test per verificare che il ripristino funzioni effettivamente.

Come posso aggiornare Rocket.Chat senza compromettere MongoDB?

Aggiorna Rocket.Chat una major version alla volta; il software esegue migrazioni all'avvio e la documentazione avverte che saltare le major version può causare gravi problemi di compatibilità. Leggi le note di ogni release prima di modificare il tag dell'immagine fissato. Verifica quali versioni di MongoDB sono supportate dalla release di destinazione con curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions e, quando aggiorni MongoDB, procedi una major version alla volta impostando setFeatureCompatibilityVersion con confirm: true dopo ogni passaggio. Esegui sempre un mongodump prima di procedere.