Docker Compose se Rocket.Chat kaise setup karein

आप क्या बना रहे हैं

एक निजी टीम चैट जिसका पूर्ण स्वामित्व आपके पास होगा: Docker Compose के माध्यम से आपके अपने VPS पर चलने वाला Rocket.Chat। यह TLS द्वारा सुरक्षित है, और इसके सभी संदेश एक MongoDB database में स्टोर होते हैं जिसे आप backup ले सकते हैं और move कर सकते हैं। Rocket.Chat, Slack और Teams का एक परिपक्व open-source विकल्प है — इसमें channels, direct messages, threads, file sharing, और voice एवं video की सुविधा मिलती है। यह सब आपके द्वारा किराए पर लिए गए और नियंत्रित hardware पर चलता है। यह application एक single container है जो कुछ ही मिनटों में शुरू हो जाता है। यदि कोई समस्या आती है, तो वह database में होती है, इसलिए इस guide का अधिकांश हिस्सा MongoDB के बारे में है। विशेष रूप से, एक ऐसी आवश्यकता जो पहली बार में सबको हैरान करती है: Rocket.Chat एक standalone MongoDB के साथ काम नहीं करेगा। इसे एक replica set की आवश्यकता होती है, भले ही वह "set" केवल एक single node ही क्यों न हो।

Prerequisites, aur RAM math jo koi nahi batata

Server ka size sahi se chunein. Ek chhoti team ke liye realistic minimum requirement 2 vCPU aur 4 GB RAM hai. Rocket.Chat ka Node.js process akele lagbhag 1 se 1.5 GB RAM leta hai, aur MongoDB ka WiredTiger cache default mein bachi hui RAM ka lagbhag aadha hissa le leta hai. 2 GB VPS par ye dono boot ke samay toh chal jaate hain, lekin jaise hi real traffic aata hai, ye aapas mein takrate hain: MongoDB apna cache badhata hai, Node apna heap badhata hai, kernel ke paas pages khatam ho jaate hain, aur out-of-memory killer sabse bade process ko band kar deta hai — jo aksar mongod hota hai. Container Killed print karta hai, Docker ise restart karta hai, aur aapko ek aisa chat server milta hai jo load aane par har kuch minute mein crash ho jata hai. 2 GB do logon ke liye testing ke liye theek hai; ye team server ke liye nahi hai. Kam se kam 4 GB se shuru karein, aur agar aapko dozens concurrent users, video calls, ya badhta hua upload history chahiye, toh 8 GB dein.

Shuru karne se pehle aapko teen cheezon ki zaroorat hogi. Ek domain name jisme VPS ke public IP par point karne wala A record ho — Rocket.Chat ke real-time features aur mobile clients ko ek stable hostname chahiye, sirf IP nahi. Server firewall aur aapke provider ke network firewall dono par Ports 80 aur 443 open hone chahiye, kyunki zyadaatar panels mein ye alag control hota hai. Aur ek naya Ubuntu 24.04 KVM VPS jisme root ya sudo access ho. Agar aap abhi bhi ye soch rahe hain ki kya chat server pehla service hona chahiye, toh 2026 mein kya self-host karna chahiye uska guide tradeoffs samjhata hai.

Docker engine और Compose plugin इंस्टॉल करें

Docker के अपने apt repository का उपयोग करें। Ubuntu के साथ आने वाले docker.io package या पुराने standalone docker-compose Python binary का उपयोग न करें। Modern Compose एक Docker plugin है जिसे आप docker compose के रूप में चलाते हैं — यहाँ space का उपयोग करें, hyphen का नहीं। पुराना docker-compose v1 अब end-of-life है और नीचे दिए गए healthcheck और dependency syntax को सही से हैंडल नहीं करता है।

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

पुष्टि करें कि दोनों components मौजूद हैं:

sudo docker version
sudo docker compose version

अगर docker compose version Docker Compose version v2.x जैसा कुछ प्रिंट करता है, तो यह सही है। यदि docker: 'compose' is not a docker command के साथ error आता है, तो इसका मतलब है कि plugin इंस्टॉल नहीं हुआ है। इससे बाद में अन्य जटिल errors आएंगे — इसे अभी ठीक करें।

Compose file: Single-node replica set के रूप में MongoDB

लोग अक्सर यहाँ गलती करते हैं, इसलिए इसे ध्यान से पढ़ें। Rocket.Chat, connected clients को real time में नए messages भेजने के लिए MongoDB change streams का उपयोग करता है। Change streams केवल replica set पर ही उपलब्ध होते हैं। यदि आप Rocket.Chat को एक plain standalone mongod पर point करते हैं, तो यह connect तो हो जाएगा, लेकिन change stream खोलने में विफल रहेगा और लगातार restart-loop में फँस जाएगा। इसका समाधान सरल है: आप एक साधारण MongoDB container चलाएँ, लेकिन इसे --replSet के साथ start करें और फिर एक one-member set को initialise करें।

एक working directory और 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:

यहाँ कुछ विकल्प जानबूझकर चुने गए हैं। Rocket.Chat port, 0.0.0.0 के बजाय 127.0.0.1:3000 पर publish किया गया है — app में स्वयं TLS नहीं है, इसलिए केवल उसी box पर मौजूद reverse proxy ही इससे connect होनी चाहिए; इसे हर interface पर bind करने से plaintext login page सीधे public internet पर आ जाएगा। MongoDB host पर बिल्कुल भी publish नहीं किया गया है; इसे केवल Compose के internal network पर mongodb नाम से एक्सेस किया जा सकता है, जो कि वही hostname है जिसे MONGO_URL उपयोग करता है। MONGO_URL में ?replicaSet=rs0 शामिल है — इसे हटाने पर driver server को standalone मानेगा भले ही वह replica set हो, और change streams फिर भी fail हो जाएंगे। MONGO_OPLOG_URL उस local database की ओर इशारा करता है जहाँ oplog स्थित होता है; modern Rocket.Chat change streams को प्राथमिकता देता है, लेकिन इसे set करना सुरक्षित है और पुराने code paths को सही रखता है। depends_on में condition: service_healthy का उपयोग किया गया है, इसलिए Compose Rocket.Chat को start करने से पहले MongoDB के ping का उत्तर देने तक प्रतीक्षा करता है — healthcheck इसी काम के लिए है।

दोनों images पर real version tags का उपयोग करें — यहाँ mongo:8.0 और Rocket.Chat का एक explicit release जैसे 8.5.1 — और कभी भी :latest का उपयोग न करें, क्योंकि यह एक unattended docker pull को accidental और un-migratable upgrade में बदल देता है। Pin करने से पहले current stable Rocket.Chat release और उसके द्वारा supported MongoDB versions की जाँच करें। Rocket.Chat प्रत्येक release के लिए एक machine-readable info document publish करता है: curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' के लिए 8.5.1 हेतु compatibleMongoVersions: ["8.0"] मिलता है, इसलिए mongo:8.0 ही एकमात्र supported engine है, साथ ही एक lts flag भी मिलता है जो बताता है कि क्या वह release long-term-support build है जिसे आप बिना supervision वाले server के लिए pin करना चाहते हैं।

Replica set को initialise करें

Stack को start करें:

sudo docker compose up -d

Rocket.Chat तुरंत crash होना शुरू हो जाएगा और Docker इसे बार-बार restart करता रहेगा — यह अपेक्षित है, क्योंकि replica set अभी मौजूद नहीं है। इसे एक बार manually बनाएँ:

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

सही result { ok: 1 } है। कुछ ही seconds में single node खुद को primary elect कर लेगा; इसे इस command से confirm करें:

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

आपको PRIMARY दिखना चाहिए। इस पूरे page पर सबसे महत्वपूर्ण detail host: "mongodb:27017" argument है। यदि आप बिना members list के bare rs.initiate() चलाते हैं, तो MongoDB container के internal hostname के तहत replica set को advertise करता है — जो a1b2c3d4e5f6 जैसा एक random hash होता है। Rocket.Chat, अपने स्वयं के container से connect करते समय, उस name को resolve नहीं कर पाता है, इसलिए MongoDB driver DNS fail कर देता है और MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 log करते हुए loop में चलता रहता है। हमेशा उस explicit service name के साथ शुरुआत करें जो आपके MONGO_URL से match करता हो।

First boot: इसकी प्रक्रिया देखें

जब set primary हो जाता है, तो Rocket.Chat का अगला restart सफलतापूर्वक जुड़ जाता है और अपनी first-run migrations शुरू कर देता है। Logs को फॉलो करें:

sudo docker compose logs -f rocketchat

आपको इस startup banner का इंतज़ार करना है:

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

First boot में समय लगता है — app database migrations चलाता है और indexes बनाता है, इसलिए चिंता करने से पहले एक या दो मिनट प्रतीक्षा करें। यदि log के बजाय MongoServerSelectionError: Server selection timed out after 30000 ms बार-बार ReplicaSetNoPrimary topology description के साथ आता है, तो इसका मतलब है कि replica set initiate नहीं हुआ है; यदि यह किसी random hash पर getaddrinfo ENOTFOUND दोहराता है, तो इसे गलत host के साथ initiate किया गया था। दोनों ही स्थितियों में, एक कदम पीछे जाएँ। जब आपको SERVER RUNNING दिखाई दे, तो Rocket.Chat 127.0.0.1:3000 पर listening मोड में है और अब इसके आगे real hostname और TLS लगाने का समय है।

इसे TLS के पीछे रखें

Rocket.Chat को कभी भी plain HTTP पर expose न करें। यदि आप एक बार http:// के माध्यम से log in करते हैं, तो आप अपना admin password रास्ते में मौजूद किसी भी व्यक्ति को दे देते हैं। उसी machine पर एक reverse proxy के माध्यम से TLS terminate करें और 127.0.0.1:3000 पर forward करें। दो बातें महत्वपूर्ण हैं: proxy को WebSocket upgrade headers forward करने चाहिए, क्योंकि Rocket.Chat real-time है और इनके बिना काम नहीं करेगा, और container का ROOT_URL बिल्कुल उसी public HTTPS address से मेल खाना चाहिए जो users टाइप करते हैं।

एक plain HTTP nginx server block से शुरुआत करें जो app को proxy करे और upgrade headers को forward करे। इसे /etc/nginx/sites-available/rocketchat के रूप में save करें, इसे sites-enabled में symlink करें, और 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;
    }
}

अभी इसे port 80 पर ही रहने दें — listen 443 ssl; के साथ और बिना certificate वाला block sudo nginx -t को भी pass नहीं होगा। nginx (sudo nginx -t && sudo systemctl reload nginx) को reload करें, फिर certificate issue करें। Ubuntu पर सबसे आसान तरीका Let's Encrypt TLS certificates with Certbot and nginx है: certbot --nginx ऊपर दिए गए block को replace कर देता है, जिसमें listen 443 ssl;, ssl_certificate lines, और एक automatic 80-to-443 redirect जुड़ जाता है, और यह आपके लिए renewal schedule कर देता है। यदि आप पहले से ही एक proxy के पीछे कई containers चला रहे हैं, तो Traefik with automatic TLS for many Docker apps एक बेहतर विकल्प है — rocketchat service में router और service labels जोड़ें और Traefik आपके लिए certificate request और renew कर देगा, इसमें nginx block की आवश्यकता नहीं होगी। किसी भी स्थिति में, compose.yml में ROOT_URL को https://chat.example.com पर सेट करें और sudo docker compose up -d को फिर से चलाएँ ताकि container बदलाव को अपना ले। यदि आप चाहते हैं कि server public internet के बजाय केवल आपके अपने network से ही reachable हो, तो इसे self-hosted WireGuard VPN on the VPS के साथ front करें और proxy को tunnel address पर bind करें।

First-run setup wizard

https://chat.example.com और Rocket.Chat पर जाएँ। Rocket.Chat आपको एक छोटा wizard दिखाएगा। सबसे पहले, admin account — एक real name, username, email, और एक strong password; यह एकमात्र account है, इसलिए इसे न भूलें। इसके बाद, organisation and server info — name, industry, size, site name, और default language; यह केवल जानकारी के लिए है, इसे भरें और आगे बढ़ें। फिर सबसे महत्वपूर्ण विकल्प: Rocket.Chat Cloud के साथ इस workspace को register करें, या इसे standalone रखें।

Registration करने से Rocket.Chat's gateway और add-on marketplace के माध्यम से mobile push notifications सक्षम हो जाते हैं, लेकिन इसके लिए Rocket.Chat's cloud के साथ एक control-plane relationship बनाना पड़ता है। Standalone रखने से server पूरी तरह private और dependency-free रहता है, लेकिन iOS और Android push notifications काम करना बंद कर देंगे, क्योंकि Apple और Google self-built app को push certificates रखने की अनुमति नहीं देते — official apps cloud gateway के माध्यम से route होते हैं। यदि privacy आपकी प्राथमिकता है और आपके users web app का उपयोग करते हैं, तो standalone चुनें; यदि mobile push अनिवार्य है, तो registration चुनें। आप बाद में Admin के अंतर्गत इसे बदल सकते हैं।

किसी को भी आमंत्रित करने से पहले सुरक्षा सुनिश्चित करें

Rocket.Chat डिफ़ॉल्ट रूप से open registration on के साथ आता है — Registration Form Public पर सेट है, इसलिए URL पाने वाला कोई भी व्यक्ति अकाउंट बना सकता है। पब्लिक hostname पर यह एक खुले दरवाजे की तरह है। Admin → Settings → Accounts → Registration पर जाएं और Registration Form को Disabled पर सेट करें, ताकि आप अकाउंट मैन्युअल रूप से या इनवाइट लिंक के माध्यम से बना सकें, या इसे Secret URL पर सेट करें। जब आप वहां हों, तो Allow Anonymous Read और Allow Anonymous Write को बंद कर दें, जब तक कि आप विशेष रूप से एक पब्लिक read-only चैनल न चाहते हों।

यह भी तय करें कि अपलोड की गई फाइलें कहाँ स्टोर होंगी। डिफ़ॉल्ट File Upload स्टोरेज GridFS है, जो हर इमेज और अटैचमेंट को MongoDB के अंदर ही स्टोर करता है। यह सरल है, लेकिन इसका मतलब है कि जैसे-जैसे लोग स्क्रीनशॉट पेस्ट करेंगे, आपका डेटाबेस — और आपका हर mongodump — लगातार बढ़ता जाएगा। Admin → Settings → File Upload के अंतर्गत आप स्टोरेज को local filesystem या S3-compatible bucket पर स्विच कर सकते हैं, और एक उचित maximum file size सेट कर सकते हैं। एक छोटी टीम के लिए GridFS ठीक है; बस ध्यान रखें कि समय के साथ आपके backups का आकार बढ़ता जाएगा।

mongodump के साथ Backups

आपका सारा data mongodb_data volume में रहता है। चलते हुए database के volume को सीधे copy न करें — mongodump का उपयोग करके एक consistent dump लें, जिसे host पर एक file में stream किया गया हो:

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

वह single gzipped archive आपका पूरा workspace है: users, channels, messages, settings, और — यदि आपने uploads को GridFS पर रखा है — तो files भी। यदि आपने uploads को filesystem या S3 पर move किया है, तो उस store का backup अलग से लें। एक fresh stack पर restore करने के लिए पहले replica set को initialise करें, फिर:

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

Archive को server से बाहर copy करें — object storage, दूसरा server, या ऐसी कोई जगह जहाँ VPS के खराब होने पर backup भी न खो जाए — और nightly cron से dump run करें। वह backup जिसे आपने कभी restore नहीं किया, वह केवल एक उम्मीद है, backup नहीं; एक throwaway VPS पर एक बार restore का अभ्यास करें ताकि ज़रूरत पड़ने पर आपको पता हो कि यह काम करता है।

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

Upgrades को सरल बनाए रखने के लिए दो नियम हैं। पहला, Rocket.Chat को एक बार में केवल एक major version तक upgrade करें। Boot के समय यह schema migrations चलाता है और सीधे major version बदलने से मना कर देता है; यदि आप 6.x से सीधे 8.x पर जाने का प्रयास करेंगे, तो डेटा corrupt होने के बजाय यह migration error के साथ रुक जाएगा। Image tag को अगले major version के latest release पर बदलें, breaking changes के लिए उस release के notes पढ़ें, docker compose up -d चलाएं, और आगे बढ़ने से पहले logs में migration पूरा होते हुए देखें। दूसरा, MongoDB support matrix का पालन करें। Rocket.Chat का प्रत्येक release MongoDB के विशिष्ट versions को support करता है, और curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions आपको बताता है कि कौन से। जब आप MongoDB को upgrade करते हैं — जैसे 7.0 से 8.0 — तो एक बार में केवल एक major version बढ़ाएं और प्रत्येक step के बाद feature-compatibility version सेट करें। MongoDB 8.0 पर इस command के लिए explicit confirm: true की आवश्यकता होती है, अन्यथा यह confirmation flag के साथ इसे पुन: चलाने का संदेश देकर रुक जाएगा:

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

दोनों में से किसी भी component के upgrade से पहले mongodump लें। यही आपकी पूरी insurance policy है।

Failure modes, with the exact strings

docker compose up के तुरंत बाद Rocket.Chat restart-loops में चला जाता है, और docker compose logs rocketchat में MongoServerSelectionError भर जाता है। MongoDB चल रहा है लेकिन driver primary को select नहीं कर पा रहा है। exact string आपको आपकी गलती बता देगी। topology type ReplicaSetNoPrimary के साथ Server selection timed out after 30000 ms का मतलब है कि आपने rs.initiate() नहीं चलाया है — set में अभी कोई config नहीं है। getaddrinfo ENOTFOUND के बाद एक random hash का मतलब है कि आपने बिना explicit host: "mongodb:27017" के शुरुआत की है, इसलिए MongoDB ने एक unresolvable container hostname advertise किया है। sudo docker compose exec mongodb mongosh --eval 'rs.status()' से diagnose करें: यदि MongoServerError: no replset config has been received error आता है, तो set को initiate करें; यदि किसी member का name एक random hash दिखाता है, तो service name के साथ re-initiate करें।

Web UI लोड होता है लेकिन login हमेशा के लिए घूमता रहता है और पूरा नहीं होता। Browser console खोलें, वहां आपको WebSocket connection to 'wss://chat.example.com/websocket' failed दिखाई देगा। यह लगभग हमेशा ROOT_URL mismatch या proxy की समस्या है जो upgrade headers को forward नहीं कर रहा है। पुष्टि करें कि ROOT_URL में https:// सहित exact public address है, और आपका nginx location block, proxy_http_version 1.1 के साथ Upgrade और Connection "upgrade" सेट करता है। इनमें से किसी को भी बदलें और docker compose up -d को फिर से चलाएं।

एक container बार-बार बंद हो रहा है और docker compose ps दिखाता है कि यह Restarting है। docker compose logs बीच में ही कट जाता है और sudo dmesg | tail oom-killer से Out of memory: Killed process 12345 (mongod) दिखाता है; exit code 137 है। System में RAM खत्म हो गई है। स्थायी समाधान एक बड़ा VPS है — कम से कम 4 GB। अस्थायी समाधान के रूप में swap जोड़ें और MongoDB के cache को उसकी command में --wiredTigerCacheSizeGB 1 के साथ limit करें, लेकिन real load के दौरान swap केवल अगले OOM को टालता है:

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

docker compose up में Error response from daemon: driver failed programming external connectivity ... bind: address already in use error आता है। Port 3000 पहले से ही किसी process द्वारा उपयोग किया जा रहा है — अक्सर यह एक पिछला Rocket.Chat container होता है जो ठीक से बंद नहीं हुआ, या कोई अन्य app। इसे sudo ss -ltnp | grep :3000 से ढूंढें, उस process या container को रोकें, या mapping के host side को 127.0.0.1:3001:3000 में बदलें और अपने proxy के proxy_pass को उसके अनुसार update करें।

FAQ

क्या Rocket.Chat को वास्तव में MongoDB replica set की आवश्यकता है?

हाँ, एक डेटाबेस नोड वाले सिंगल सर्वर के लिए भी। Rocket.Chat, MongoDB change streams का उपयोग करके real time में संदेश भेजता है। change streams केवल replica-set-only फीचर है — एक standalone mongod इसे नहीं खोल सकता। आपको कई मशीनों की आवश्यकता नहीं है; आप --replSet rs0 के साथ शुरू किया गया एक MongoDB container चला सकते हैं और rs.initiate() के साथ एक one-member set को initialise कर सकते हैं। यदि आप इस स्टेप को छोड़ देते हैं, तो driver को primary नहीं मिलता है, जिससे Rocket.Chat MongoServerSelectionError: Server selection timed out के साथ restart-loop में चला जाता है और boot होना पूरा नहीं कर पाता।

Self-hosted Rocket.Chat को कितने RAM की आवश्यकता है?

व्यावहारिक न्यूनतम (practical minimum) के रूप में 4 GB और व्यस्त टीम के लिए 8 GB का अनुमान लगाएं। Rocket.Chat का Node process लगभग 1 से 1.5 GB का उपयोग करता है और MongoDB अपने WiredTiger cache के लिए शेष RAM का लगभग आधा हिस्सा लेता है। इसलिए 2 GB वाले box पर दोनों आपस में टकराते हैं और real load के दौरान out-of-memory killer mongod को terminate कर देता है, जिससे logs में Killed और exit code 137 दिखाई देता है। 2 GB केवल कुछ test users के साथ software का मूल्यांकन करने के लिए पर्याप्त है।

मैं Rocket.Chat को HTTPS के पीछे कैसे रखूँ?

उसी VPS पर एक reverse proxy चलाएं जो TLS को terminate करे और 127.0.0.1:3000 को forward करे, और container के ROOT_URL को अपने public https:// address पर सेट करें। Proxy को WebSocket upgrade headers को forward करना चाहिए, अन्यथा login अटक जाएगा। nginx के साथ Certbot सबसे सरल single-app setup है; यदि आप एक proxy के पीछे कई containers चलाते हैं और automatic certificate management चाहते हैं, तो Traefik अधिक बेहतर है।

मैं self-hosted Rocket.Chat का backup कैसे लूँ?

Volume को copy करने के बजाय mongodump के साथ एक consistent database dump लें: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz। उस archive में users, channels, messages, और settings शामिल होते हैं, साथ ही अपलोड की गई files भी यदि आपने storage को GridFS पर रखा है। इसे server से बाहर copy करें, cron के साथ nightly automate करें, और एक throwaway box पर mongorestore का अभ्यास करें ताकि आपको पता हो कि restore वास्तव में काम करता है।

मैं MongoDB को खराब किए बिना Rocket.Chat को upgrade कैसे करूँ?

Rocket.Chat को एक बार में एक major version तक upgrade करें — यह boot पर migrations चलाता है और majors को skip करने से मना कर देता है — और pinned image tag को बदलने से पहले प्रत्येक release के notes पढ़ें। curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions के साथ जांचें कि आपका target release कौन से MongoDB versions को support करता है, और जब आप MongoDB को move करें, तो एक बार में एक major step लें और प्रत्येक hop के बाद confirm: true के साथ setFeatureCompatibilityVersion सेट करें। हमेशा पहले mongodump लें।