Mga Gabay

Ni Matt Connor 2026-07-15 · Na-update 2026-07-24

Paano i-setup ang Rocket.Chat sa Docker

Q: Paano i-back up ang self-hosted Rocket.Chat?

Gumamit ng consistent database dump gamit ang mongodump sa halip na i-copy ang volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Ang archive na iyon ay naglalaman ng mga users, channels, messages, at settings, pati na rin ang mga uploaded files kung ang storage ay nasa GridFS. I-copy ito palabas ng server, i-automate ang nightly backup gamit ang cron, at mag-practice ng mongorestore sa isang throwaway box para masiguradong gumagana ang restore.

Matutunan ang pag-deploy ng Rocket.Chat gamit ang Docker Compose at ang kailangang MongoDB replica set para maiwasan ang error sa database connection.

Ang iyong bubuuin

Isang private team chat na kontrolado mo nang lubos: Rocket.Chat na tumatakbo sa sarili mong VPS gamit ang Docker Compose, may TLS security, at ang lahat ng mensahe ay nakaimbak sa isang MongoDB database na maaari mong i-back up at ilipat. Ang Rocket.Chat ay isang mature na open-source alternative sa Slack at Teams — may channels, direct messages, threads, file sharing, at voice at video, lahat sa hardware na inuupahan at kontrolado mo. Ang application ay isang single container na handa na sa loob ng ilang minuto. Ang lahat ng posibleng error ay nasa database sa tabi nito, kaya ang karamihan sa guide na ito ay tungkol sa MongoDB, partikular na ang isang requirement na nakakagulat sa lahat sa unang pagkakataon: hindi tatakbo ang Rocket.Chat sa isang standalone MongoDB. Kailangan nito ng replica set, kahit na ang "set" na iyon ay isang single node lamang.

Prerequisites, at ang RAM math na hindi sinasabi sa inyo

Maging tapat sa pagpili ng laki ng server. Ang realistic na minimum para sa isang maliit na team ay 2 vCPU at 4 GB ng RAM. Ang Node.js process ng Rocket.Chat ay nangangailangan ng humigit-kumulang 1 hanggang 1.5 GB. Ang WiredTiger cache ng MongoDB naman ay default na kumukuha ng kalahati ng natitirang RAM. Sa isang 2 GB VPS, magkakasya ang dalawa sa simula, pero magkakabanggaan sila kapag may dumating nang totoong traffic: lalaki ang cache ng MongoDB, lalaki ang heap ng Node, mauubusan ng pages ang kernel, at papatayin ng out-of-memory killer ang pinakamalaking process — kadalasan ay ang mongod. Maglalabas ng error na Killed ang container, i-re-restart ito ng Docker, at magkakaroon ka ng chat server na nagda-down bawat ilang minuto kahit sa load na dapat ay kaya nito. Ang 2 GB ay sapat lang para sa testing ng dalawang tao; hindi ito sapat para sa isang team server. Magsimula sa 4 GB, at gumamit ng 8 GB kung inaasahan ang dose-dosenang concurrent users, video calls, o lumalaking upload history.

Kailangan mo rin ang tatlong bagay bago magsimula. Isang domain name na may A record na nakaturo sa public IP ng VPS — kailangan ng real-time features at mobile clients ng Rocket.Chat ang isang stable na hostname, hindi lang basta IP. Buksan ang Ports 80 at 443 sa server firewall at sa network firewall ng iyong provider, na hiwalay na control sa karamihan ng mga panel. At isang bagong Ubuntu 24.04 KVM VPS na may root o sudo access. Kung nagdedesisyon ka pa kung chat server ang tamang unang serbisyo na i-run, tingnan ang guide to what is worth self-hosting in 2026 para sa mga tradeoffs.

I-install ang Docker engine at ang Compose plugin

Gamitin ang sariling apt repository ng Docker. Huwag gamitin ang docker.io package ng Ubuntu o ang lumang standalone na docker-compose Python binary. Ang modernong Compose ay isang Docker plugin na tinatawag gamit ang docker compose — may space, hindi hyphen. Ang lumang docker-compose v1 ay end-of-life na at hindi tama ang pag-handle sa healthcheck at dependency syntax sa ibaba.

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

I-confirm na naroon ang dalawang component:

sudo docker version
sudo docker compose version

Ang pag-print ng docker compose version na katulad ng Docker Compose version v2.x ang mahalagang check. Kung mag-error ito ng docker: 'compose' is not a docker command, hindi na-install ang plugin at magkakaroon ka ng mga error mamaya — ayusin ito agad.

Ang compose file: MongoDB bilang isang single-node replica set

Ito ang bahaging madalas magkamali ang mga user, kaya basahin itong mabuti. Ginagamit ng Rocket.Chat ang MongoDB change streams para i-push ang mga bagong message sa mga connected na client nang real time. Ang change streams ay available lamang sa isang replica set. Kung ituturo ang Rocket.Chat sa isang plain standalone mongod, magkokonekta ito pero mabibigong magbukas ng change stream, kaya magkakaroon ng walang katapusang restart-loop. Ang solusyon ay simple lang: magpatakbo ng isang ordinaryong MongoDB container, pero i-start ito gamit ang --replSet at pagkatapos ay i-initialize ang isang one-member set.

Gumawa ng working directory at isang 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:

Sadyang may ilang mga piniling configuration dito. Ang Rocket.Chat port ay naka-publish sa 127.0.0.1:3000, hindi sa 0.0.0.0 — walang TLS ang app mismo, kaya ang reverse proxy lamang sa parehong machine ang dapat makakonekta rito; kung i-bind ito sa lahat ng interface, ang plaintext login page ay magiging exposed sa public internet. Ang MongoDB ay hindi naka-publish sa host; maaari lamang itong ma-access sa pamamagitan ng internal network ng Compose gamit ang pangalang mongodb, na siyang hostname na ginagamit ng MONGO_URL. Ang MONGO_URL ay may kasamang ?replicaSet=rs0 — kung tatanggalin ito, ituturing ng driver ang server bilang standalone kahit na ito ay isang replica set, at hindi pa rin gagana ang change streams. Ang MONGO_OPLOG_URL ay nakaturo sa local database kung saan matatagpuan ang oplog; mas pinapaboran ng modernong Rocket.Chat ang change streams, pero ang pag-set nito ay ligtas at para sa compatibility ng mga lumang code paths. Ang depends_on ay gumagamit ng condition: service_healthy, kaya maghihintay ang Compose hanggang sa sumagot ang MongoDB sa isang ping bago i-start ang Rocket.Chat — ito ang gamit ng healthcheck.

Gumamit ng specific na version tags sa parehong images — mongo:8.0 at isang explicit na Rocket.Chat release gaya ng 8.5.1 dito — at huwag kailanman gagamit ng :latest, dahil gagawin nitong aksidenteng upgrade ang isang unattended docker pull na hindi pwedeng i-migrate. I-check muna ang kasalukuyang stable na Rocket.Chat release at ang mga supported na MongoDB versions bago mag-pin. Naglalabas ang Rocket.Chat ng machine-readable info document para sa bawat release: ang curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' ay nagbabalik ng compatibleMongoVersions: ["8.0"] para sa 8.5.1, kaya mongo:8.0 lamang ang tanging supported na engine, kasama ang isang lts flag na magsasabi kung ang release na iyon ay isang long-term-support build na karapat-dapat i-pin para sa isang server na ayaw mong bantayan nang madalas.

I-initialize ang replica set

I-up ang stack:

sudo docker compose up -d

Mag-crash agad ang Rocket.Chat at paulit-ulit itong i-re-restart ng Docker — normal lang ito dahil hindi pa nagagawa ang replica set. I-create ito nang manual:

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

Ang tamang resulta ay { ok: 1 }. Sa loob ng ilang segundo, magiging primary ang single node; i-verify gamit ang:

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

Dapat makita ang PRIMARY. Ang pinakaimportanteng detalye sa buong pahinang ito ay ang argument na host: "mongodb:27017". Kung magpapatakbo ka ng bare rs.initiate() nang walang members list, ia-advertise ng MongoDB ang replica set gamit ang internal hostname ng container — isang random hash gaya ng a1b2c3d4e5f6. Hindi ma-re-resolve ng Rocket.Chat ang pangalang iyon mula sa sarili nitong container, kaya mag-e-error ang MongoDB driver sa DNS at mag-lo-loop nang walang hanggan habang nagi-log ng MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Laging gamitin ang explicit service name na tumutugma sa iyong MONGO_URL.

First boot: i-monitor ang pag-boot nito

Kapag primary na ang set, magkakaroon ng malinis na koneksyon ang susunod na restart ng Rocket.Chat at sisimulan ang mga first-run migration nito. I-monitor ang mga log:

sudo docker compose logs -f rocketchat

Ang linyang dapat mong hintayin ay ang startup banner:

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

Mabagal ang first boot — nagpapatakbo ang app ng database migrations at nagbu-build ng mga index, kaya maghintay ng isa o dalawang minuto bago mag-alala. Kung ang log ay paulit-ulit na MongoServerSelectionError: Server selection timed out after 30000 ms na may topology description na type ReplicaSetNoPrimary, hindi na-initiate ang replica set; kung paulit-ulit naman ang getaddrinfo ENOTFOUND sa isang random hash, na-initiate ito gamit ang maling host. Sa alinmang senaryo, bumalik sa nakaraang hakbang. Kapag nakita mo na ang SERVER RUNNING, nakikinig na ang Rocket.Chat sa 127.0.0.1:3000 at oras na para lagyan ito ng totoong hostname at TLS.

Ilagay ito sa likod ng TLS

Huwag kailanman i-expose ang Rocket.Chat gamit ang plain HTTP. Kapag nag-log in ka sa http:// nang isang beses, ibibigay mo ang iyong admin password sa sinumang nasa network path. I-terminate ang TLS sa isang reverse proxy sa parehong server at i-forward ito sa 127.0.0.1:3000. Dalawang bagay ang mahalaga: dapat i-forward ng proxy ang WebSocket upgrade headers, dahil real-time ang Rocket.Chat at hindi ito gagana nang wala ang mga ito, at dapat eksaktong tumugma ang ROOT_URL ng container sa public HTTPS address na itinatype ng mga user.

Magsimula sa isang plain HTTP nginx server block na nagpa-proxy sa app at nagfo-forward ng upgrade headers. I-save ito bilang /etc/nginx/sites-available/rocketchat, i-symlink ito sa sites-enabled, at i-reload:

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

Iwanan muna ito sa port 80 — ang isang block na may listen 443 ssl; at walang certificate ay hindi papasa sa sudo nginx -t. I-reload ang nginx (sudo nginx -t && sudo systemctl reload nginx), pagkatapos ay kumuha ng certificate. Ang pinakamadaling paraan sa Ubuntu ay ang Let's Encrypt TLS certificates with Certbot and nginx: papalitan ng certbot --nginx ang block sa itaas, idadagdag ang listen 443 ssl;, ang mga linya ng ssl_certificate, at isang automatic 80-to-443 redirect, at i-schedule na rin ang renewal para sa iyo. Kung mayroon ka nang maraming container sa likod ng isang proxy, ang Traefik with automatic TLS for many Docker apps ang mas maayos na opsyon — magdagdag ng router at service labels sa rocketchat service at hihilingin at i-re-renew ng Traefik ang certificate para sa iyo nang walang nginx block. Sa alinmang paraan, i-set ang ROOT_URL sa https://chat.example.com sa compose.yml at i-run muli ang sudo docker compose up -d para makuha ng container ang pagbabago. Kung gusto mong ang server ay ma-access lamang mula sa loob ng iyong sariling network sa halip na sa public internet, gamitin ang isang self-hosted WireGuard VPN on the VPS at i-bind ang proxy sa tunnel address.

Ang first-run setup wizard

Pumunta sa https://chat.example.com at susundan ka ng Rocket.Chat sa isang maikling wizard. Una, ang admin account — kailangan ang real name, username, email, at isang malakas na password; ito lang ang tanging account na umiiral, kaya huwag itong iwawala. Kasunod ang organisation and server info — pangalan, industry, size, site name, at default language; cosmetic lamang ito, kaya punan lang at magpatuloy. Pagkatapos ay ang mahalagang desisyon: i-register ang workspace na ito sa Rocket.Chat Cloud, o panatilihin itong standalone.

Ang pag-register ay nagbibigay-daan sa mobile push notifications gamit ang gateway ng Rocket.Chat at ang add-on marketplace, ngunit may kapalit itong control-plane relationship sa cloud ng Rocket.Chat. Ang standalone ay pananatiling private at walang dependency ang server, pero hindi gagana ang iOS at Android push notifications dahil hindi papayag ang Apple at Google na ang isang self-built app ang humawak ng mga push certificate — ang mga official app ay dumadaan sa cloud gateway. Piliin ang standalone kung privacy ang pangunahing layunin at web app ang gamit ng iyong mga user; piliin ang registration kung kailangan talaga ang mobile push. Maaari mo itong baguhin sa Admin sa hinaharap.

I-lock ang access bago mag-imbita ng kahit sino

Ang Rocket.Chat ay may open registration on — default na naka-set ang Registration Form sa Public, kaya kahit sino na makakahanap ng URL ay makakagawa ng account. Ito ay nagsisilbing open door sa mga public hostname. Pumunta sa Admin → Settings → Accounts → Registration at i-set ang Registration Form sa Disabled para manu-manong paggawa ng account o via invite link, o i-set ito sa Secret URL. Habang nandoon, i-off ang Allow Anonymous Read at Allow Anonymous Write maliban kung kailangan mo talaga ng public read-only channel.

I-set din kung saan mapupunta ang mga uploads. Ang default na File Upload storage ay GridFS, kung saan ang bawat imahe at attachment ay nakaimbak sa loob mismo ng MongoDB. Simple ito, pero ibig sabihin nito ay lalaki nang walang limitasyon ang iyong database — at bawat mongodump na kukunin mo — habang nagpapasa ang mga user ng screenshots. Sa ilalim ng Admin → Settings → File Upload, maaari mong palitan ang storage sa local filesystem o sa isang S3-compatible bucket, at magtakda ng limitasyon sa maximum file size. Para sa maliliit na team, ayos lang ang GridFS; tandaan lang na lalaki ang laki ng iyong backups habang tumatagal.

Backups gamit ang mongodump

Lahat ng data ay nasa mongodb_data volume. Huwag basta i-copy ang volume habang tumatakbo ang database — gumamit ng mongodump para sa consistent dump, at i-stream ito sa isang file sa host:

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

Ang gzipped archive na ito ang kabuuan ng iyong workspace: users, channels, messages, settings, at — kung naka-set ang uploads sa GridFS — pati ang mga files. Kung inilipat mo ang uploads sa filesystem o S3, i-back up ang store na iyon nang hiwalay. I-restore ito sa isang bagong stack sa pamamagitan ng pag-initialize muna ng replica set, pagkatapos ay:

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

I-copy ang archive palabas ng server — sa object storage, sa ibang server, o kahit saan na hindi kasama sa VPS kung sakaling masira ito — at i-run ang dump mula sa cron gabi-gabi. Ang backup na hindi pa na-restore ay isang pag-asa lamang, hindi isang tunay na backup; subukan ang restore sa isang throwaway VPS para masiguradong gumagana ito bago mo pa ito kailanganin.

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

Dalawang panuntunan ang nagpapanatili sa upgrades na simple. Una, i-upgrade ang Rocket.Chat nang paisa-isang major version. Nagsasagawa ito ng schema migrations sa boot at sadyang hindi pinapayagan ang pagtalon sa ibang major version; kung susubukan mong pumunta mula 6.x diretso sa 8.x, hihinto ito dahil sa migration error sa halip na masira ang iyong data. I-update ang image tag sa pinakabagong release ng susunod na major version, basahin ang release notes nito para sa mga breaking changes, i-run ang docker compose up -d, at hintayin na matapos ang migration sa logs bago magpatuloy. Pangalawa, sundin ang MongoDB support matrix. Ang bawat Rocket.Chat release ay sumusuporta sa partikular na set ng mga MongoDB version, at sasabihin sa iyo ng curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions kung alin ang mga ito. Kapag mag-a-upgrade ka ng MongoDB — halimbawa, mula 7.0 patungong 8.0 — gawin ito nang paisa-isang major version at i-set ang feature-compatibility version pagkatapos ng bawat hakbang. Sa MongoDB 8.0, nangangailangan ang command na ito ng explicit na confirm: true, kung hindi ay mag-eerror ito at sasabihing i-run muli gamit ang confirmation flag:

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

Kumuha ng mongodump bago ang bawat upgrade ng alinman sa dalawang component na ito. Iyan ang iyong insurance policy.

Failure modes, with the exact strings

Nagre-restart nang paulit-ulit ang Rocket.Chat pagkatapos ng docker compose up, at napupuno ang docker compose logs rocketchat ng MongoServerSelectionError. Tumatakbo ang MongoDB pero hindi makapili ang driver ng primary, at sasabihin ng exact string kung anong pagkakamali ang nagawa mo. Ang Server selection timed out after 30000 ms na may topology type na ReplicaSetNoPrimary ay nangangahulugang hindi mo pinatakbo ang rs.initiate() — wala pang config ang set. Ang getaddrinfo ENOTFOUND na sinusundan ng random hash ay nangangahulugang nag-initiate ka nang walang explicit na host: "mongodb:27017", kaya nag-advertise ang MongoDB ng unresolvable container hostname. Gamitin ang sudo docker compose exec mongodb mongosh --eval 'rs.status()' para mag-diagnose: kung mag-error ito ng MongoServerError: no replset config has been received, i-initiate ang set; kung ipakita nito ang isang member na ang name ay random hash, i-re-initiate ito gamit ang service name.

Naglo-load ang web UI pero hindi matapos ang loading ng login. Buksan ang browser console at makikita mo ang WebSocket connection to 'wss://chat.example.com/websocket' failed. Halos laging ROOT_URL mismatch ito o proxy na hindi nagfo-forward ng upgrade headers. Siguraduhin na ang ROOT_URL ay katumbas ng exact public address kasama ang https://, at ang nginx location block mo ay naka-set ang Upgrade at Connection "upgrade" gamit ang proxy_http_version 1.1. Baguhin ang alinman sa mga ito at i-run muli ang docker compose up -d.

Patuloy na namamatay ang container at ipinapakita ng docker compose ps na Restarting ito. Napuputol ang docker compose logs sa gitna ng linya at ipinapakita ng sudo dmesg | tail ang Out of memory: Killed process 12345 (mongod) mula sa oom-killer; ang exit code ay 137. Ubos na ang RAM ng machine. Ang permanenteng solusyon ay mas malaking VPS — minimum na 4 GB. Bilang pansamantalang solusyon, magdagdag ng swap at i-cap ang cache ng MongoDB gamit ang --wiredTigerCacheSizeGB 1 sa command nito, pero ang swap ay magpapabagal lang sa susunod na OOM kapag may real load na:

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

docker compose up fails with Error response from daemon: driver failed programming external connectivity ... bind: address already in use. May gumagamit na ng port 3000 — madalas ay isang nakaraang Rocket.Chat container na hindi maayos na huminto, o isa pang app. Hanapin ito gamit ang sudo ss -ltnp | grep :3000, i-stop ang process o container na iyon, o baguhin ang host side ng mapping sa 127.0.0.1:3001:3000 at i-update ang proxy_pass ng iyong proxy para tumugma.

FAQ

Kailangan ba talaga ng Rocket.Chat ng MongoDB replica set?

Oo, kahit para sa isang server na may iisang database node lang. Gumagamit ang Rocket.Chat ng MongoDB change streams para sa real-time messaging. Ang change streams ay feature na para sa replica-set lamang — hindi makakapag-open ng change stream ang isang standalone mongod. Hindi mo kailangan ng maraming machine; magpatakbo lang ng isang MongoDB container gamit ang --replSet rs0 at i-initialize ang isang one-member set gamit ang rs.initiate(). Kapag nilaktawan ang step na ito, hindi mahahanap ng driver ang primary, kaya magkakaroon ng restart-loop ang Rocket.Chat kasama ang MongoServerSelectionError: Server selection timed out at hindi matatapos ang booting.

Gaano karaming RAM ang kailangan ng self-hosted Rocket.Chat?

Maglaan ng 4 GB bilang practical minimum at 8 GB para sa mga busy na team. Gumagamit ang Node process ng Rocket.Chat ng humigit-kumulang 1 hanggang 1.5 GB. Ang MongoDB naman ay kumakain ng halos kalahati ng natitirang RAM para sa WiredTiger cache. Sa isang 2 GB na server, magkakabanggaan ang dalawa at papatayin ng out-of-memory killer ang mongod sa ilalim ng totoong load, na magpapakita ng Killed sa logs at exit code 137. Ang 2 GB ay sapat lamang para sa pag-evaluate ng software gamit ang ilang test users.

Paano ilalagay ang Rocket.Chat sa likod ng HTTPS?

Magpatakbo ng reverse proxy sa parehong VPS para i-terminate ang TLS at i-forward ang request sa 127.0.0.1:3000, at i-set ang ROOT_URL ng container sa iyong public https:// address. Dapat i-forward ng proxy ang WebSocket upgrade headers, kung hindi ay magha-hang ang login. Ang Certbot na may nginx ang pinakasimpleng single-app setup; mas malinis naman ang Traefik kung nagpapatakbo ka ng maraming container sa likod ng isang proxy at gusto mo ng automatic certificate management.

Paano i-back up ang self-hosted Rocket.Chat?

Gumamit ng consistent database dump gamit ang mongodump sa halip na i-copy ang volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Ang archive na iyon ay naglalaman ng mga users, channels, messages, at settings, pati na rin ang mga uploaded files kung ang storage ay nasa GridFS. I-copy ito palabas ng server, i-automate ang nightly backup gamit ang cron, at mag-practice ng mongorestore sa isang throwaway box para masiguradong gumagana ang restore.

Paano i-upgrade ang Rocket.Chat nang hindi nasisira ang MongoDB?

I-upgrade ang Rocket.Chat nang paisa-isang major version — nagpapatakbo ito ng migrations sa boot at hindi pinapayagang lumaktaw ng major versions — at basahin ang release notes ng bawat bersyon bago i-update ang pinned image tag. Suriin kung anong mga MongoDB version ang supported ng target release gamit ang curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Kapag maglilipat ng MongoDB, gawin ito nang paisa-isang major version at i-set ang setFeatureCompatibilityVersion gamit ang confirm: true pagkatapos ng bawat hakbang. Laging mag-take ng mongodump muna.

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