Jak postawić Rocket.Chat na Docker Compose

Cel projektu

Prywatny czat zespołowy w pełnej własności: Rocket.Chat uruchomiony na własnym VPS za pomocą Docker Compose, zabezpieczony protokołem TLS, z każdą wiadomością zapisaną w bazie danych MongoDB, którą można tworzyć kopie zapasowe i przenosić. Rocket.Chat to dojrzała, otwartoźródłowa alternatywa dla Slack i Teams — kanały, wiadomości bezpośrednie, wątki, udostępnianie plików oraz komunikacja głosowa i wideo, wszystko na wynajętym i kontrolowanym przez użytkownika sprzęcie. Aplikacja to pojedynczy kontener, który uruchamia się w kilka minut. Większość problemów technicznych wynika z konfiguracji bazy danych, dlatego główna część tego poradnika dotyczy MongoDB, a w szczególności jednego wymogu, który zaskakuje użytkowników: Rocket.Chat nie zadziała z samodzielną instancją MongoDB. Wymagany jest replica set, nawet jeśli ten „set” składa się tylko z jednego węzła.

Wymagania wstępne oraz obliczenia RAM, o których nikt nie wspomina

Należy rzetelnie dobrać parametry serwera. Realne minimum dla małego zespołu to 2 vCPU i 4 GB RAM. Proces Node.js aplikacji Rocket.Chat wymaga około 1 do 1,5 GB pamięci. Domyślnie silnik WiredTiger w bazie MongoDB zajmuje około połowy pozostałej pamięci RAM. Na VPS z 2 GB pamięci oba procesy działają poprawnie podczas uruchamiania, ale dochodzi do konfliktu w momencie pojawienia się rzeczywistego ruchu. MongoDB zwiększa rozmiar pamięci cache, Node zwiększa rozmiar sterty (heap), brakuje stron pamięci dla jądra systemu, a mechanizm out-of-memory killer terminuje największy proces — zazwyczaj mongod. Kontener zwraca błąd Killed, Docker go restartuje, co skutkuje niestabilnością serwera czatu i jego awariami co kilka minut przy obciążeniu, które nie powinno stanowić problemu. 2 GB jest wystarczające do testów w dwóch osoby, ale nie jest to rozwiązanie dla zespołu. Należy zacząć od 4 GB, a przy dziesiątkach jednoczesnych użytkowników, połączeniach wideo lub rosnącej historii przesyłanych plików, należy przeznaczyć 8 GB.

Przed rozpoczęciem instalacji wymagane są trzy elementy. Nazwa domeny z rekordem A wskazującym na publiczny adres IP serwera VPS — funkcje czasu rzeczywistego Rocket.Chat oraz klienci mobilni wymagają stabilnej nazwy hosta, a nie samego adresu IP. Otwarte porty 80 i 443 w firewallu serwera oraz w firewallu sieciowym dostawcy (często jest to oddzielna konfiguracja w panelu zarządzania). Czysty system Ubuntu 24.04 KVM VPS z uprawnieniami root lub sudo. Jeśli rozważają Państwo, czy serwer czatu jest odpowiednią usługą do samodzielnego hostowania, przewodnik po tym, co warto hostować samodzielnie w 2026 przedstawia analizę opłacalności.

Zainstaluj silnik Docker oraz wtyczkę Compose

Należy używać oficjalnego repozytorium apt dla Docker. Nie należy używać pakietu docker.io dostarczanego przez Ubuntu ani przestarzałego pliku binarnego Python docker-compose. Nowoczesny Compose to wtyczka Docker wywoływana za pomocą polecenia docker compose — ze spacją, a nie myślnikiem. Starsza wersja docker-compose v1 nie jest już wspierana i błędnie obsługuje składnię healthcheck oraz zależności przedstawioną poniżej.

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

Należy potwierdzić obecność obu komponentów:

sudo docker version
sudo docker compose version

Ważnym testem jest wykonanie docker compose version, które powinno zwrócić wynik typu Docker Compose version v2.x. Jeśli wystąpi błąd docker: 'compose' is not a docker command, oznacza to nieprawidłową instalację wtyczki. Może to spowodować błędy w dalszej części procesu — należy naprawić instalację w tym miejscu.

Plik compose: MongoDB jako replica set z jednym węzłem

To jest etap, w którym najczęściej występują błędy, dlatego należy czytać uważnie. Rocket.Chat wykorzystuje change streams w MongoDB do przesyłania nowych wiadomości do połączonych klientów w czasie rzeczywistym. Funkcja change streams jest dostępna wyłącznie w konfiguracji replica set. Skierowanie Rocket.Chat na zwykły, samodzielny mongod spowoduje nawiązanie połączenia, błąd otwarcia change stream i niekończący się cykl restartów. Rozwiązanie nie jest skomplikowane: należy uruchomić pojedynczy, standardowy kontener MongoDB, ale z parametrem --replSet, a następnie zainicjować zestaw z jednym członkiem.

Należy utworzyć katalog roboczy oraz plik 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:

Niektóre wybory są celowe. Port Rocket.Chat jest publikowany na 127.0.0.1:3000, a nie na 0.0.0.0 — sama aplikacja nie posiada TLS, więc dostęp do niej powinien mieć wyłącznie reverse proxy na tej samej maszynie; przypisanie do wszystkich interfejsów wystawiłoby stronę logowania przesyłającą dane otwartym tekstem bezpośrednio do publicznego internetu. MongoDB nie jest w ogóle publikowane na hoście; jest dostępne tylko przez wewnętrzną sieć Compose pod nazwą mongodb, która jest dokładnie hostem używanym przez MONGO_URL. MONGO_URL zawiera ?replicaSet=rs0 — brak tego parametru spowoduje, że sterownik potraktuje serwer jako standalone mimo konfiguracji replica set, co uniemożliwi działanie change streams. MONGO_OPLOG_URL wskazuje na bazę danych local, w której znajduje się oplog; nowsze wersje Rocket.Chat preferują change streams, jednak ustawienie tego parametru jest bezpieczne i zapewnia kompatybilność ze starszym kodem. depends_on wykorzystuje condition: service_healthy, więc Compose czeka na odpowiedź MongoDB na zapytanie ping przed uruchomieniem Rocket.Chat — służy do tego mechanizm healthcheck.

Należy stosować konkretne tagi wersji dla obu obrazów — tutaj mongo:8.0 oraz jawna wersja Rocket.Chat, np. 8.5.1 — i nigdy nie używać :latest, co zamienia niekontrolowaną docker pull w przypadkową, niepodatną na migrację aktualizację. Przed utrwaleniem wersji należy sprawdzić aktualną stabilną wersję Rocket.Chat oraz wspierane przez nią wersje MongoDB. Rocket.Chat publikuje dokument informacyjny w formacie maszynowym dla każdej wersji: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' zwraca compatibleMongoVersions: ["8.0"] dla wersji 8.5.1, zatem mongo:8.0 jest jedynym wspieranym silnikiem, dodatkowo flaga lts informuje, czy dana wersja jest wydaniem typu long-term-support, co jest zalecane dla serwerów wymagających minimalnej interwencji administratora.

Inicjalizacja replica set

Uruchomienie stosu:

sudo docker compose up -d

Aplikacja Rocket.Chat będzie natychmiast ulegać awarii, a Docker będzie ją restartował — jest to zjawisko oczekiwane, ponieważ replica set jeszcze nie istnieje. Należy utworzyć ją ręcznie:

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

Poprawny wynik to { ok: 1 }. Po kilku sekundach pojedynczy węzeł zostanie wybrany na primary; potwierdź to poleceniem:

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

Wynik powinien wynosić PRIMARY. Kluczowym elementem tej instrukcji jest argument host: "mongodb:27017". Uruchomienie polecenia rs.initiate() bez listy członków spowoduje, że MongoDB ogłosi nazwę replica set przy użyciu wewnętrznej nazwy hosta kontenera — będzie to losowy hash, np. a1b2c3d4e5f6. Rocket.Chat, łącząc się z własnego kontenera, nie będzie mógł rozwiązać tej nazwy. Powoduje to błąd DNS w sterowniku MongoDB i nieskończoną pętlę logów MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Zawsze należy inicjować proces, używając jawnej nazwy usługi zgodnej z MONGO_URL.

Pierwsze uruchomienie: monitorowanie procesu startowego

Po ustawieniu parametru primary, kolejny restart Rocket.Chat przebiega poprawnie i rozpoczyna migracje przy pierwszym uruchomieniu. Należy monitorować logi:

sudo docker compose logs -f rocketchat

Wymagana linia to baner startowy:

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

Pierwsze uruchomienie trwa długo — aplikacja wykonuje migracje bazy danych i buduje indeksy. Należy odczekać 1 lub 2 minuty. Jeśli w logach powtarza się MongoServerSelectionError: Server selection timed out after 30000 ms z opisem topologii typu ReplicaSetNoPrimary, oznacza to, że replica set nie został zainicjowany. Jeśli powtarza się getaddrinfo ENOTFOUND z losowym hashem, oznacza to inicjalizację z błędną nazwą hosta. W obu przypadkach należy cofnąć się o jeden krok. Po pojawieniu się SERVER RUNNING aplikacja Rocket.Chat nasłuchuje na 127.0.0.1:3000. Można wtedy skonfigurować właściwą nazwę hosta oraz TLS.

Put it behind TLS

Nigdy nie należy wystawiać Rocket.Chat przez protokół HTTP. Logowanie przez http:// powoduje przekazanie hasła administratora każdemu podmiotowi w ścieżce sieciowej. Należy terminować TLS w reverse proxy na tej samej maszynie i przekierowywać ruch do 127.0.0.1:3000. Kluczowe są dwa aspekty: proxy musi przekazywać nagłówki WebSocket upgrade, ponieważ Rocket.Chat wymaga ich do działania w czasie rzeczywistym, oraz ROOT_URL kontenera musi być identyczny z publicznym adresem HTTPS wpisywanym przez użytkowników.

Należy zacząć od standardowego bloku serwera nginx HTTP, który proxyuje ruch do aplikacji i przekazuje nagłówki upgrade. Plik należy zapisać jako /etc/nginx/sites-available/rocketchat, utworzyć link symboliczny w sites-enabled i przeładować konfigurację:

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

Na początku należy pozostawić port 80 — blok z listen 443 ssl; bez certyfikatu nie przejdzie weryfikacji sudo nginx -t. Po przeładowaniu nginx (sudo nginx -t && sudo systemctl reload nginx) należy wygenerować certyfikat. Najprostsza metoda w systemie Ubuntu to Let's Encrypt TLS certificates with Certbot and nginx: certbot --nginx nadpisuje powyższy blok, dodając listen 443 ssl;, linie ssl_certificate oraz automatyczne przekierowanie z portu 80 na 443, a także planuje automatyczne odnawianie. Jeśli w jednej instancji proxy działają już inne kontenery, lepszym rozwiązaniem jest Traefik with automatic TLS for many Docker apps — należy dodać etykiety routera i usługi do usługi rocketchat, a Traefik samodzielnie obsłuży żądania i odnowi certyfikat bez konieczności tworzenia bloku nginx. W obu przypadkach należy ustawić ROOT_URL na https://chat.example.com w compose.yml i ponownie uruchomić sudo docker compose up -d, aby kontener przejął zmiany. Jeśli serwer ma być dostępny wyłącznie wewnątrz własnej sieci, a nie przez publiczny internet, należy użyć self-hosted WireGuard VPN on the VPS i przypisać proxy do adresu tunelu.

Kreator konfiguracji przy pierwszym uruchomieniu

Przejdź do https://chat.example.com i Rocket.Chat przeprowadzi Cię przez krótki proces konfiguracji. Najpierw należy utworzyć konto administratora — wymagane są: imię i nazwisko, nazwa użytkownika, adres e-mail oraz silne hasło; jest to jedyne istniejące konto, dlatego należy je zapamiętać. Następnie należy podać informacje o organizacji i serwerze — nazwę, branżę, wielkość, nazwę witryny oraz język domyślny; dane te mają charakter kosmetyczny. Następnie następuje kluczowy wybór: rejestracja tego obszaru roboczego w Rocket.Chat Cloud lub praca w trybie standalone.

Rejestracja umożliwia otrzymywanie powiadomień push w aplikacjach mobilnych poprzez bramkę Rocket.Chat oraz dostęp do dodatkowych rozszerzeń, ale wymaga nawiązania relacji z chmurą Rocket.Chat (control-plane). Tryb standalone zapewnia pełną prywatność serwera i brak zależności zewnętrznych, jednak powiadomienia push na systemach iOS i Android przestaną działać. Wynika to z faktu, że Apple i Google nie pozwalają aplikacjom budowanym samodzielnie na przechowywanie certyfikatów push — oficjalne aplikacje przesyłają powiadomienia przez bramkę chmurową. Wybierz tryb standalone, jeśli priorytetem jest prywatność, a użytkownicy korzystają z aplikacji webowej; wybierz rejestrację, jeśli powiadomienia mobilne są niezbędne. Ustawienia te można zmienić później w sekcji Admin.

Zabezpiecz system przed zapraszaniem użytkowników

Rocket.Chat domyślnie posiada włączoną funkcję open registration on. Formularz rejestracyjny jest ustawiony na Public, co umożliwia założenie konta każdemu, kto zna adres URL. Na publicznej nazwie hosta stanowi to otwarty dostęp. Należy przejść do sekcji Admin → Settings → Accounts → Registration i zmienić ustawienie Registration Form na Disabled (ręczne tworzenie kont lub zaproszenia) lub na Secret URL. W tym samym miejscu należy wyłączyć opcje Allow Anonymous Read oraz Allow Anonymous Write, chyba że wymagany jest publiczny kanał typu read-only.

Należy również określić miejsce przechowywania plików. Domyślny mechanizm File Upload wykorzystuje GridFS, który przechowuje wszystkie obrazy i załączniki bezpośrednio w bazie MongoDB. Rozwiązanie to jest proste, lecz powoduje niekontrolowany wzrost rozmiaru bazy danych oraz każdego pliku mongodump w wyniku przesyłania zrzutów ekranu przez użytkowników. W sekcji Admin → Settings → File Upload można zmienić lokalizację przechowywania na lokalny system plików lub bucket zgodny z protokołem S3 oraz ustawić limit maksymalnego rozmiaru pliku. Dla małych zespołów rozwiązanie GridFS jest wystarczające, należy jednak pamiętać, że rozmiar kopii zapasowych będzie systematycznie rosnąć.

Kopie zapasowe za pomocą mongodump

Wszystkie dane znajdują się w wolumenie mongodb_data. Nie należy kopiować wolumenu podczas pracy działającej bazy danych. Należy wykonać spójny zrzut za pomocą mongodump i przekierować wynik do pliku na hoście:

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

Ten pojedynczy skompresowany plik gzipped zawiera całe środowisko: użytkowników, kanały, wiadomości, ustawienia oraz — jeśli pliki są przechowywane w GridFS — również same pliki. Jeśli pliki są przechowywane w systemie plików lub w S3, należy wykonać osobną kopię zapasową tego magazynu. Aby przywrócić dane na nowej instalacji, należy najpierw zainicjować replica set, a następnie wykonać:

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

Należy skopiować archiwum poza serwer — do pamięci obiektowej, na inny serwer lub w inne miejsce, gdzie awaria VPS nie spowoduje utraty kopii zapasowej — i uruchamiać proces tworzenia zrzutu codziennie za pomocą cron. Kopia zapasowa, której nigdy nie przetestowano podczas przywracania, nie gwarantuje bezpieczeństwa. Należy raz przećwiczyć proces przywracania na tymczasowym VPS, aby upewnić się, że działa on poprawnie przed wystąpieniem awarii.

Upgrades: pin tags, read the notes, respect the Mongo matrix

Dwie zasady zapewniają stabilność procesu upgrade'u. Po pierwsze, aktualizuj Rocket.Chat o jedną wersję główną naraz. System wykonuje migracje schematu podczas uruchamiania i nie pozwala na przeskakiwanie wersji głównych; próba przejścia bezpośrednio z 6.x na 8.x spowoduje błąd migracji zamiast uszkodzenia danych. Zmień tag obrazu na najnowszą wersję kolejnej wersji głównej, przeczytaj release notes pod kątem zmian typu breaking changes, uruchom docker compose up -d i sprawdź w logach, czy migracja została zakończona przed kontynuowaniem prac. Po drugie, przestrzegaj macierzy wsparcia MongoDB. Każda wersja Rocket.Chat obsługuje konkretny zestaw wersji MongoDB, a curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions określa te wymagania. Podczas aktualizacji MongoDB — na przykład z 7.0 na 8.0 — należy przechodzić przez każdą wersję główną po kolei i ustawić feature-compatibility version po każdym kroku. W przypadku MongoDB 8.0 polecenie to wymaga jawnego użycia confirm: true, w przeciwnym razie system zwróci błąd z informacją o konieczności ponownego uruchomienia polecenia z flagą potwierdzenia:

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

Wykonaj mongodump przed każdą aktualizacją każdego z komponentów. To stanowi pełną procedurę zabezpieczającą.

Tryby awarii i dokładne komunikaty

Rocket.Chat wpada w pętlę restartów bezpośrednio po docker compose up, a docker compose logs rocketchat wypełnia MongoServerSelectionError. MongoDB działa, ale sterownik nie może wybrać nadrzędnego węzła (primary), a dokładny komunikat wskazuje popełniony błąd. Server selection timed out after 30000 ms z typem topologii ReplicaSetNoPrimary oznacza brak wykonania rs.initiate() — zestaw nie posiada jeszcze konfiguracji. getaddrinfo ENOTFOUND wraz z losowym hashem oznacza inicjalizację bez jawnego użycia host: "mongodb:27017", przez co MongoDB przekazało nierozwiązywalną nazwę hosta kontenera. Należy użyć sudo docker compose exec mongodb mongosh --eval 'rs.status()' do diagnostyki: jeśli wystąpi błąd MongoServerError: no replset config has been received, należy zainicjować zestaw; jeśli widoczny jest węzeł, którego name to losowy hash, należy ponownie zainicjować zestaw przy użyciu nazwy usługi.

Interfejs webowy ładuje się, ale proces logowania trwa w nieskończoność. Po otwarciu konsoli przeglądarki pojawi się WebSocket connection to 'wss://chat.example.com/websocket' failed. Przyczyną jest najczęściej niezgodność ROOT_URL lub proxy, które nie przekazuje nagłówków upgrade. Należy potwierdzić, że ROOT_URL jest identyczny z publicznym adresem, włączając https://, oraz że blok nginx location ustawia Upgrade i Connection "upgrade" z użyciem proxy_http_version 1.1. Po wprowadzeniu zmian należy ponownie uruchomić docker compose up -d.

Kontener ulega awarii, a docker compose ps wskazuje na Restarting. docker compose logs przerywa w połowie linii, a sudo dmesg | tail pokazuje Out of memory: Killed process 12345 (mongod) od oom-killer; kod wyjścia to 137. System nie posiada wystarczającej ilości pamięci RAM. Rozwiązaniem jest większy VPS — minimum 4 GB. Jako rozwiązanie tymczasowe można dodać swap i ograniczyć pamięć cache MongoDB za pomocą --wiredTigerCacheSizeGB 1 w command, jednak swap jedynie opóźnia kolejny błąd OOM przy rzeczywistym obciążeniu:

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

docker compose up zgłasza błąd Error response from daemon: driver failed programming external connectivity ... bind: address already in use. Port 3000 jest już zajęty — często przez poprzedni kontener Rocket.Chat, który nie został poprawnie zatrzymany, lub inną aplikację. Należy zidentyfikować proces za pomocą sudo ss -ltnp | grep :3000, zatrzymać dany proces lub kontener, bądź zmienić stronę hosta mapowania na 127.0.0.1:3001:3000 i zaktualizować proxy_pass w proxy, aby zachować zgodność.

FAQ

Czy Rocket.Chat rzeczywiście wymaga MongoDB replica set?

Tak, nawet w przypadku pojedynczego serwera z jedną instancją bazy danych. Rocket.Chat dostarcza wiadomości w czasie rzeczywistym przy użyciu MongoDB change streams. Funkcja change streams jest dostępna wyłącznie w trybie replica-set — samodzielny mongod nie może jej uruchomić. Nie jest wymagana wielofunkcyjna infrastruktura; należy uruchomić jeden kontener MongoDB za pomocą --replSet rs0 i zainicjować zestaw składający się z jednego elementu za pomocą rs.initiate(). Pominięcie tego kroku spowoduje brak możliwości odnalezienia węzła primary przez driver. W rezultacie Rocket.Chat wpadnie w pętlę restartów z błędem MongoServerSelectionError: Server selection timed out i nie zakończy procesu uruchamiania.

Ile pamięci RAM wymaga self-hosted Rocket.Chat?

Należy zaplanować minimum 4 GB dla celów praktycznych oraz 8 GB dla dużych zespołów. Proces Node.js zużywa około 1 do 1.5 GB, natomiast MongoDB zajmuje około połowy pozostałej pamięci RAM na cache WiredTiger. Na maszynie z 2 GB pamięci oba procesy rywalizują o zasoby, co powoduje, że mechanizm out-of-memory killer terminauje mongod przy większym obciążeniu, generując błąd Killed w logach oraz exit code 137. 2 GB wystarcza jedynie do testów oprogramowania z niewielką liczbą użytkowników testowych.

Jak skonfigurować HTTPS dla Rocket.Chat?

Należy uruchomić reverse proxy na tym samym VPS, który terminauje połączenia TLS i przekazuje ruch do 127.0.0.1:3000, a następnie ustawić ROOT_URL kontenera na publiczny adres https://. Proxy musi przekazywać nagłówki WebSocket upgrade, w przeciwnym razie proces logowania zostanie zawieszony. Najprostsza konfiguracja dla pojedynczej aplikacji to Certbot wraz z nginx; Traefik jest lepszym rozwiązaniem przy wielu kontenerach za jednym proxy, jeśli wymagane jest automatyczne zarządzanie certyfikatami.

Jak wykonać kopię zapasową self-hosted Rocket.Chat?

Należy wykonać spójny zrzut bazy danych za pomocą mongodump zamiast kopiowania wolumenu: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Archiwum zawiera użytkowników, kanały, wiadomości oraz ustawienia, a także pliki, jeśli użyto storage'u GridFS. Archiwum należy skopiować poza serwer i automatyzować proces co noc za pomocą cron. Należy regularnie przeprowadzać mongorestore na maszynie testowej, aby zweryfikować poprawność przywracania danych.

Jak zaktualizować Rocket.Chat bez błędów w MongoDB?

Aktualizację Rocket.Chat należy przeprowadzać o jedną wersję główną (major version) naraz — aplikacja wykonuje migracje podczas uruchamiania i nie pozwala na pomijanie wersji głównych. Przed zmianą tagu obrazu należy zapoznać się z dokumentacją danej wersji. Należy sprawdzić wspierane wersje MongoDB dla docelowego wydania za pomocą curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Podczas aktualizacji MongoDB należy przechodzić przez jedną wersję główną naraz i ustawiać setFeatureCompatibilityVersion za pomocą confirm: true po każdym etapie. Przed każdą operacją należy wykonać mongodump.