Rocket.Chat sa Docker Compose: Self-Host sa VPS

Ang bubuuin mo

Isang private team chat na ganap mong pagmamay-ari: Rocket.Chat na tumatakbo sa sarili mong VPS gamit ang Docker Compose, may TLS termination, at ang bawat mensahe ay naka-store sa MongoDB database na maaari mong i-back up at ilipat. Ang Rocket.Chat ay isang mature na open-source na alternatibo sa Slack at Teams, na may channels, direct messages, threads, file sharing, at voice at video, lahat sa hardware na nirerentahan at kinokontrol mo. Isang container lang ang application at maaari itong gumana sa loob ng ilang minuto. Ang karamihan sa aktuwal na mga problema ay nasa database na katabi nito, kaya MongoDB ang pangunahing paksa ng gabay na ito. Partikular dito ang isang requirement na kadalasang nakakagulat sa unang setup: hindi tatakbo ang Rocket.Chat gamit ang standalone MongoDB. Kailangan nito ng replica set, kahit single node lang ang "set" na iyon.

Mga Prerequisite at ang RAM math na madalas hindi sinasabi

Tantiyahin nang realistiko ang kapasidad ng server. Ang praktikal na minimum para sa maliit na team ay 2 vCPU at 4 GB ng RAM. Karaniwang nangangailangan ang Node.js process ng Rocket.Chat ng humigit-kumulang 1 hanggang 1.5 GB nang mag-isa, at bilang default, kumukuha ang WiredTiger cache ng MongoDB ng halos kalahati ng natitirang RAM. Sa 2 GB VPS, kasya ang dalawang ito sa oras ng boot, pero nagkakaproblema agad kapag dumating ang aktuwal na traffic: lumalaki ang cache ng MongoDB, lumalaki ang heap ng Node, nauubusan ng pages ang kernel, at pinapatay ng out-of-memory killer ang pinakamalaking process, karaniwan ang mongod. Ipinapakita ng container ang Killed, nire-restart ito ng Docker, at nagkakaroon ka ng chat server na bumabagsak bawat ilang minuto kapag may load na dapat ay kaya nitong hawakan. Ayos ang 2 GB para sa pagsubok kasama ang dalawang tao; hindi ito sapat para sa team server. Magsimula sa 4 GB, at gumamit ng 8 GB kung inaasahan mong magkakaroon ng dose-dosenang concurrent user, video call, o patuloy na lumalaking upload history.

Kailangan mo ring maihanda ang tatlong bagay bago magsimula. Una, isang domain name na may A record na nakaturo sa public IP ng VPS. Kailangan ng real-time features ng Rocket.Chat at ng mobile client ang stable hostname, hindi isang bare IP. Ikalawa, dapat bukas ang ports 80 at 443 sa server firewall at sa network firewall ng provider, na hiwalay na control sa karamihan ng panel. Ikatlo, kailangan ng bagong Ubuntu 24.04 KVM VPS na may root o sudo. Kung pinag-iisipan mo pa kung ang chat server ang tamang unang service na patakbuhin, inilalahad ng gabay sa mga serbisyong sulit i-self-host sa 2026 ang mga tradeoff.

I-install ang Docker engine at ang Compose plugin

Gamitin ang sariling apt repository ng Docker, hindi ang docker.io package na kasama sa Ubuntu at hindi ang lumang standalone na docker-compose Python binary. Ang modern Compose ay Docker plugin na tinatawag gamit ang docker compose na may space, hindi hyphen. End-of-life na ang lumang docker-compose v1 at hindi nito maayos na hinahawakan ang 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

Kumpirmahing parehong available ang dalawang component:

sudo docker version
sudo docker compose version

Ang mahalaga ay ang docker compose version na nagpi-print ng gaya ng Docker Compose version v2.x. Kung magbalik ito ng error na docker: 'compose' is not a docker command, hindi na-install ang plugin at magkakaroon ka ng mahirap tukuying mga failure sa susunod. Ayusin ito rito.

Ang compose file: MongoDB bilang single-node replica set

Ito ang bahaging madalas nagkakamali ang mga tao, kaya basahin ito nang dahan-dahan. Gumagamit ang Rocket.Chat ng MongoDB change streams upang itulak ang mga bagong mensahe sa mga nakakonektang client nang real time, at available lamang ang change streams sa isang replica set. Ituro ang Rocket.Chat sa isang plain standalone na mongod at makakakonekta ito, mabibigong magbukas ng change stream, at paulit-ulit na magre-restart. Hindi komplikado ang solusyon: magpatakbo ka ng isang ordinaryong MongoDB container, ngunit simulan ito gamit ang --replSet at pagkatapos ay i-initialize ang isang one-member set.

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

May sinasadyang dahilan ang ilang setting 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 server ang dapat makaabot dito; kapag naka-bind ito sa lahat ng interface, direktang malalantad sa public internet ang plaintext login page. Hindi naka-publish sa host ang MongoDB; maaabot lamang ito sa internal network ng Compose sa pangalang mongodb, na siya ring hostname na ginagamit ng MONGO_URL. Ang MONGO_URL ang nagdadala ng ?replicaSet=rs0. Kapag inalis ito, ituturing ng driver na standalone ang server kahit replica set ito, kaya mabibigo pa rin ang change streams. Itinuturo ng MONGO_OPLOG_URL ang local database kung saan nakalagay ang oplog. Mas gusto ng modernong Rocket.Chat ang change streams, ngunit hindi nakasasama ang pagtatakda nito at nakatutulong ito sa mga lumang code path. Gumagamit ang depends_on ng condition: service_healthy, kaya naghihintay ang Compose hanggang sumagot ang MongoDB sa isang ping bago nito simulan ang Rocket.Chat. Iyan ang gamit ng healthcheck.

I-pin ang aktuwal na version tag sa parehong image, mongo:8.0, at magtakda ng tahasang Rocket.Chat release gaya ng 8.5.1 dito. Huwag kailanman gamitin ang :latest, dahil ginagawa nitong hindi sinasadyang upgrade ang unattended docker pull na hindi na maaaring i-migrate. Suriin muna ang kasalukuyang stable Rocket.Chat release at ang mga bersyon ng MongoDB na sinusuportahan nito bago mag-pin. Naglalathala ang Rocket.Chat ng machine-readable na info document para sa bawat release: ibinabalik ng curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' ang compatibleMongoVersions: ["8.0"] para sa 8.5.1, kaya mongo:8.0 lamang ang supported engine. May kasama rin itong lts flag na nagsasabi kung ang release ay long-term-support build na sulit i-pin para sa server na ayaw mong regular na bantayan. Hindi lahat ng project ay naglalathala ng versioned image. Sa ganitong sitwasyon, sa source inililipat ang pin: ang pag-self-host ng openGym workout tracker ay nangangahulugang mag-checkout ng partikular na git tag at bumuo mula rito, sa halip na sumunod sa branch na patuloy na nagbabago.

I-initialize ang replica set

Paandarin ang stack:

sudo docker compose up -d

Magsisimulang mag-crash agad ang Rocket.Chat at patuloy itong ire-restart ng Docker. Inaasahan ito dahil hindi pa umiiral ang replica set. Isagawa ito nang isang beses at mano-mano:

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

Ang tamang resulta ay { ok: 1 }. Pagkalipas ng ilang segundo, mag-eelect ang nag-iisang node bilang primary. Kumpirmahin gamit ang:

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

Dapat mong makita ang PRIMARY. Ang pinakamahalagang detalye sa buong page na ito ay ang argumentong 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 na hash gaya ng a1b2c3d4e5f6. Hindi maresolba ng Rocket.Chat, na kumokonekta mula sa sarili nitong container, ang pangalang iyon. Dahil dito, mabibigo ang DNS lookup ng MongoDB driver at paulit-ulit itong magla-log ng MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6. Palaging mag-initialize gamit ang explicit service name na tumutugma sa iyong MONGO_URL.

Unang boot: subaybayan ang pagsisimula nito

Kapag primary na ang set, malinis na makakakonekta ang Rocket.Chat sa susunod nitong restart at sisimulan nito ang mga first-run migration. Subaybayan ang logs:

sudo docker compose logs -f rocketchat

Ang linyang hinihintay mo ay ang startup banner:

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

Mabagal ang unang boot dahil nagpapatakbo ang app ng mga database migration at gumagawa ng mga index, kaya maghintay muna ng isa o dalawang minuto bago mag-alala. Kung sa halip ay paulit-ulit na lumalabas ang MongoServerSelectionError: Server selection timed out after 30000 ms na may topology description na type ReplicaSetNoPrimary, hindi pa na-initialize ang replica set; kung paulit-ulit namang lumalabas ang getaddrinfo ENOTFOUND sa isang random hash, na-initialize ito gamit ang maling host. Sa alinmang sitwasyon, 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:// at may nakasubaybay sa network path, naibigay mo na sa kanila ang admin password mo. I-terminate ang TLS sa isang reverse proxy sa parehong box 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 maayos kung wala ang mga ito, at dapat eksaktong tumugma ang ROOT_URL ng container sa public HTTPS address na tina-type ng mga user.

Magsimula sa isang plain HTTP nginx server block na nagpo-proxy sa app at nagfo-forward ng upgrade headers. I-save ito bilang /etc/nginx/sites-available/rocketchat, gumawa ng symlink nito sa sites-enabled, at mag-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;
    }
}

Iwan muna ito sa port 80. Hindi papasa sa sudo nginx -t ang block na may listen 443 ssl; at walang certificate. I-reload ang nginx gamit ang sudo nginx -t && sudo systemctl reload nginx, pagkatapos ay mag-issue ng certificate. Sa Ubuntu, ang pinakamalinis na paraan ay ang Let’s Encrypt TLS certificates gamit ang Certbot at nginx: Binabago ng certbot --nginx ang block sa itaas nang direkta, idinadagdag ang listen 443 ssl;, ang mga linyang ssl_certificate, at automatic na 80-to-443 redirect, at itinatakda rin nito ang renewal para sa iyo. Kung nagpapatakbo ka na ng ilang container sa likod ng iisang proxy, mas maayos ang Traefik na may automatic TLS para sa maraming Docker app. Magdagdag ng router at service labels sa rocketchat service, at awtomatikong nagre-request at nagre-renew ng certificate ang Traefik para sa iyo nang walang nginx block. Anuman ang piliin mo, itakda ang ROOT_URL sa https://chat.example.com sa compose.yml at muling patakbuhin ang sudo docker compose up -d para makuha ng container ang pagbabago. Kung gusto mong ma-access ang server mula lamang sa sarili mong network at hindi mula sa public internet, ilagay ito sa likod ng self-hosted WireGuard VPN sa VPS at i-bind ang proxy sa tunnel address.

Ang first-run setup wizard

Pumunta sa https://chat.example.com at gagabayan ka ng Rocket.Chat sa isang maikling wizard. Una, ang admin account: totoong pangalan, username, email, at matibay na password. Ito ang tanging account na umiiral, kaya huwag itong mawala. Kasunod ang organisation at server info: pangalan, industriya, laki, site name, at default language. Cosmetic lamang ang mga ito; punan ang mga field at magpatuloy. Pagkatapos, piliin ang setting na talagang mahalaga: i-register ang workspace sa Rocket.Chat Cloud, o gawin itong standalone.

Kapag nag-register, mae-enable ang mobile push notifications sa pamamagitan ng gateway ng Rocket.Chat at ang add-on marketplace. Kapalit nito, magkakaroon ng control-plane relationship ang server sa cloud ng Rocket.Chat. Kapag standalone, mananatiling ganap na private at walang dependency sa external service ang server. Gayunman, hindi na gagana ang push notifications sa iOS at Android. Hindi pinapayagan ng Apple at Google na ang isang self-built app ang maghawak ng push certificates, kaya dumadaan sa cloud gateway ang official apps. Piliin ang standalone kung privacy ang pangunahing layunin at sa web app gumagamit ang iyong mga user. Piliin ang registration kung kailangang-kailangan ang mobile push. Maaari mong baguhin ang setting na ito sa ibang pagkakataon sa ilalim ng Admin.

I-lock down muna bago mag-imbita ng sinuman

Ang Rocket.Chat ay may naka-enable na open registration bilang default. Naka-set ang Registration Form sa Public, kaya makakagawa ng account ang sinumang makakita ng URL. Sa public hostname, para itong bukas na access point. Pumunta sa Admin → Settings → Accounts → Registration at itakda ang Registration Form sa Disabled, para mano-mano kang gumawa ng mga account o gumamit ng invite link, o sa Secret URL. Habang naroon ka, i-off ang Allow Anonymous Read at Allow Anonymous Write, maliban kung sadyang gusto mo ng public read-only channel. Kung nakakapagod ang paggawa ng bawat account nang mano-mano at hindi lamang ito ang serbisyong ginagamit ng team mo, ituro ang OAuth login ng Rocket.Chat sa isang self-hosted Authentik SSO server sa halip. Sa ganitong paraan, isang beses lang pinamamahalaan ang pagpasok at pag-alis ng mga user sa iisang lugar, sa halip na hiwa-hiwalay sa bawat app.

Pagpasyahan mo rin kung saan ise-save ang mga upload. Ang default na File Upload storage ay GridFS, na nagse-save ng bawat image at attachment mismo sa MongoDB. Simple ito, pero nangangahulugan itong patuloy na lalaki ang database mo, pati ang bawat mongodump na ginagawa mo, habang nagpi-paste ang mga user ng screenshots. Sa Admin → Settings → File Upload, maaari mong ilipat ang storage sa local filesystem o sa isang S3-compatible bucket, at magtakda ng makatwirang maximum file size. Para sa maliit na team, sapat ang GridFS; tandaan lang na mas lalaki ang iyong mga backup sa paglipas ng panahon.

Mga Backup gamit ang mongodump

Nasa mongodb_data volume ang lahat ng data mo. Huwag basta kopyahin ang volume habang tumatakbo ang database. Gumawa ng consistent dump gamit ang mongodump, at i-stream ito sa file sa host:

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

Ang iisang gzipped archive na iyon ang buong workspace mo: users, channels, messages, settings, at, kung iniwan mo ang uploads sa GridFS, pati ang mga file. Kung inilipat mo ang uploads sa filesystem o S3, i-back up nang hiwalay ang store na iyon. Mag-restore sa 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

Kopyahin ang archive palabas ng server—sa object storage, ibang server, o kahit saan na hindi masasama ang backup kapag nagkaaberya ang VPS—at patakbuhin ang dump mula sa cron gabi-gabi. Ang backup na hindi mo pa kailanman na-restore ay pag-asa lamang, hindi backup; magsagawa ng restore nang isang beses sa throwaway VPS para matiyak mong gumagana ito bago mo ito kailanganin.

Mga upgrade: i-pin ang tags, basahin ang notes, sundin ang MongoDB matrix

Dalawang rule ang nagpapanatiling simple ng upgrades. Una, mag-upgrade ng Rocket.Chat nang tig-isang major version lang. Nagpapatakbo ito ng schema migrations sa boot at sadyang tumatangging lumaktaw ng major version; kapag sinubukan mong dumiretso mula 6.x sa 8.x, hihinto ito na may migration error sa halip na masira ang data. I-update ang image tag sa pinakabagong release ng kasunod na major version, basahin ang notes ng release para sa mga breaking change, patakbuhin ang docker compose up -d, at i-monitor ang logs hanggang matapos ang migration bago magpatuloy. Ikalawa, sundin ang MongoDB support matrix. May partikular na set ng mga MongoDB version na sinusuportahan ang bawat Rocket.Chat release, at sinasabi ng curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions kung alin ang mga ito. Kapag nag-upgrade ka ng MongoDB, halimbawa mula 7.0 sa 8.0, mag-upgrade nang tig-isang major version at itakda ang feature-compatibility version pagkatapos ng bawat hakbang. Sa MongoDB 8.0, nangangailangan ang command na iyon ng tahasang confirm: true, kung hindi ay tatanggi ito at magpapakita ng mensaheng nagsasabing patakbuhin itong muli gamit ang confirmation flag:

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

Gumawa ng mongodump bago ang bawat upgrade ng alinmang component. Iyan ang buong insurance policy.

Mga failure mode, kasama ang eksaktong strings

Nagre-restart loop ang Rocket.Chat kaagad 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 ipinapakita ng exact string kung anong mali ang nagawa mo. Ibig sabihin ng Server selection timed out after 30000 ms na may topology type na ReplicaSetNoPrimary na hindi mo kailanman pinatakbo ang rs.initiate(); wala pang config ang set. Ang getaddrinfo ENOTFOUND na sinusundan ng random hash ay nangangahulugang nag-initiate ka nang wala ang explicit na host: "mongodb:27017", kaya nag-advertise ang MongoDB ng container hostname na hindi maresolba. Mag-diagnose gamit ang sudo docker compose exec mongodb mongosh --eval 'rs.status()': kung nag-e-error ito ng MongoServerError: no replset config has been received, i-initiate ang set; kung may ipinapakitang member na ang name ay random hash, i-re-initiate gamit ang service name.

Naglo-load ang web UI pero walang katapusang umiikot ang login at hindi nakukumpleto. Buksan ang browser console at makikita mo ang WebSocket connection to 'wss://chat.example.com/websocket' failed. Halos palaging sanhi ito ng mismatch sa ROOT_URL o ng proxy na hindi nagpapasa ng upgrade headers. Tiyaking ang ROOT_URL ay eksaktong public address, kasama ang https://, at ang iyong nginx location block ay nagse-set ng Upgrade at Connection "upgrade" gamit ang proxy_http_version 1.1. Baguhin ang alinman sa mga ito at patakbuhin muli ang docker compose up -d.

Paulit-ulit na namamatay ang isang container at ipinapakita ng docker compose ps na Restarting ito. Napuputol sa kalagitnaan ng linya ang docker compose logs, at ipinapakita ng sudo dmesg | tail ang Out of memory: Killed process 12345 (mongod) mula sa oom-killer; 137 ang exit code. Kapos sa RAM ang server. Ang tamang solusyon ay mas malaking VPS, na may minimum na 4 GB. Bilang pansamantalang hakbang, magdagdag ng swap at limitahan ang cache ng MongoDB gamit ang --wiredTigerCacheSizeGB 1 sa command nito, pero ipinagpapaliban lamang ng swap ang susunod na OOM kapag nasa aktuwal na load:

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

Nagfa-fail ang docker compose up dahil sa Error response from daemon: driver failed programming external connectivity ... bind: address already in use. May gumagamit na ng port 3000, kadalasan ay dating Rocket.Chat container na hindi malinis na nag-stop, o ibang 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 upang tumugma.

FAQ

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

Oo, kahit isang server lang na may isang database node. Nagde-deliver ang Rocket.Chat ng mga mensahe nang real time gamit ang MongoDB change streams, at feature lamang ng replica set ang change streams. Hindi makakapagbukas nito ang standalone na mongod. Hindi mo kailangan ng maraming machine; magpatakbo ka ng isang MongoDB container na sinimulan gamit ang --replSet rs0, at mag-initialize ng one-member set gamit ang rs.initiate(). Kapag nilaktawan mo ang hakbang na ito, hindi kailanman makakahanap ng primary ang driver. Dahil dito, paulit-ulit na nagre-restart ang Rocket.Chat gamit ang MongoServerSelectionError: Server selection timed out at hindi natatapos ang pag-boot nito.

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

Maglaan ng 4 GB bilang praktikal na minimum at 8 GB para sa busy na team. Gumagamit ang Node process ng Rocket.Chat ng humigit-kumulang 1 hanggang 1.5 GB, at inaangkin ng MongoDB ang halos kalahati ng natitirang RAM para sa WiredTiger cache nito. Sa isang 2 GB na machine, nagkukulang ang memory para sa dalawang ito. Dahil dito, tine-terminate ng out-of-memory killer ang mongod kapag may totoong load. Lumalabas ang Killed sa logs, kasama ang exit code 137. Sapat lamang ang 2 GB para suriin ang software gamit ang ilang test user.

Paano ko ilalagay ang Rocket.Chat sa likod ng HTTPS?

Magpatakbo ng reverse proxy sa parehong VPS na nagsasagawa ng TLS termination at nagfo-forward sa 127.0.0.1:3000. Itakda ang ROOT_URL ng container sa iyong public https:// address. Dapat i-forward ng proxy ang WebSocket upgrade headers. Kung hindi, magha-hang ang login. Ang Certbot na may nginx ang pinakasimpleng setup para sa isang app. Mas malinis gamitin ang Traefik kung maraming container ang pinapatakbo mo sa likod ng isang proxy at gusto mo ng awtomatikong certificate management.

Paano ako magba-back up ng self-hosted Rocket.Chat?

Gumawa ng consistent database dump gamit ang mongodump sa halip na kopyahin ang volume: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz. Naglalaman ang archive na iyon ng mga user, channel, mensahe, at setting, pati ng mga na-upload na file kung nanatili sa GridFS ang storage. Kopyahin ito palabas ng server, i-automate gabi-gabi gamit ang cron, at magsagawa ng mongorestore sa isang disposable machine upang matiyak mong gumagana talaga ang restore.

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

I-upgrade ang Rocket.Chat nang tig-isang major version. Nagpapatakbo ito ng mga migration sa boot at tumatangging mag-skip ng major version. Basahin ang release notes ng bawat release bago baguhin ang pinned image tag. Suriin kung aling mga bersyon ng MongoDB ang sinusuportahan ng target release mo gamit ang curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions. Kapag nag-upgrade ka ng MongoDB, gawin ito nang tig-isang major version at itakda ang setFeatureCompatibilityVersion gamit ang confirm: true pagkatapos ng bawat hakbang. Palaging gumawa muna ng mongodump.