Docker Compose ద్వారా Rocket.Chat ను హోస్ట్ చేయడం ఎలా?

మీరు ఏమి నిర్మిస్తున్నారు

మీరు పూర్తిగా నియంత్రించే ఒక ప్రైవేట్ టీమ్ చాట్: మీ స్వంత VPSలో Docker Compose ద్వారా నడుస్తున్న Rocket.Chat, దీనికి TLS termination ఉంటుంది. ప్రతి సందేశం మీరు బ్యాకప్ తీసుకోగల మరియు తరలించగల MongoDB డేటాబేస్‌లో నిక్షిప్తమై ఉంటుంది. Rocket.Chat అనేది Slack మరియు Teams కు ఒక పరిణతి చెందిన ఓపెన్-సోర్స్ ప్రత్యామ్నాయం. ఇందులో ఛానెల్‌లు, డైరెక్ట్ మెసేజ్‌లు, థ్రెడ్‌లు, ఫైల్ షేరింగ్, వాయిస్ మరియు వీడియో కాల్స్ వంటి సౌకర్యాలు మీరు అద్దెకు తీసుకున్న మరియు నియంత్రించే హార్డ్‌వేర్‌పై అందుబాటులో ఉంటాయి. అయితే, ఇది మాత్రమే నమ్మదగిన ఎంపిక కాదు. మీరు ఇంకా ఎంపిక చేసుకునే పనిలో ఉంటే, Mattermost, Rocket.Chat, Synapse మరియు Zulip ల పోలిక మీకు సహాయపడుతుంది. ఇది RAM, డేటాబేస్, మొబైల్ పుష్, SSO మరియు అప్‌గ్రేడ్‌ల వంటి భవిష్యత్తులో ఇబ్బంది కలిగించే అంశాల ఆధారంగా వీటిని పోలుస్తుంది. ఈ అప్లికేషన్ నిమిషాల్లోనే సిద్ధమయ్యే ఒకే ఒక కంటైనర్. వాస్తవానికి సమస్యలు తలెత్తే ప్రతిదీ దాని పక్కనే ఉన్న డేటాబేస్‌లోనే ఉంటుంది. కాబట్టి, ఈ గైడ్‌లో ఎక్కువ భాగం MongoDB గురించి ఉంటుంది. ముఖ్యంగా, మొదటిసారి చేసే వారికి ఆశ్చర్యం కలిగించే ఒక అవసరం ఉంది: Rocket.Chat అనేది standalone MongoDB తో నడవదు. దీనికి replica set అవసరం, ఆ "set" లో ఒకే ఒక నోడ్ ఉన్నప్పటికీ అది తప్పనిసరి.

ముందస్తు అవసరాలు, ఎవరూ చెప్పని RAM లెక్కలు

సర్వర్ సామర్థ్యాన్ని వాస్తవికంగా నిర్ణయించండి. చిన్న బృందానికి ఆచరణలో అవసరమైన కనిష్ఠ సామర్థ్యం 2 vCPU మరియు 4 GB RAM. Rocket.Chat యొక్క Node.js process కు మాత్రమే సుమారు 1 నుంచి 1.5 GB అవసరం అవుతుంది. MongoDB యొక్క WiredTiger cache డిఫాల్ట్‌గా (మొత్తం RAM నుంచి 1 GB తీసివేసిన తర్వాత మిగిలినదానిలో 50%) లేదా 0.256 GB — వీటిలో పెద్ద విలువను తీసుకుంటుంది. ఈ డిఫాల్ట్‌లో mongod మాత్రమే ఆ machine ను ఉపయోగిస్తుందని భావిస్తారు. ఇది మొత్తం RAM ఆధారంగా లెక్కించబడుతుంది. Node ఇప్పటికే ఉపయోగిస్తున్న memory ని పరిగణనలోకి తీసుకోదు. అందువల్ల 4 GB machine పై ఇది 1.5 GB, 2 GB machine పై సుమారు 0.5 GB అవుతుంది. దీనికి అదనంగా Node యొక్క heap, cache వెలుపల mongod ఉపయోగించే స్వంత memory, అలాగే operating system అవసరాలు ఉంటాయి. 2 GB VPS లో boot సమయంలో ఈ రెండూ సరిపోతాయి. కానీ వాస్తవ network traffic వచ్చిన వెంటనే అవి memory కోసం పోటీ పడతాయి. MongoDB తన cache ను పెంచుతుంది. Node తన heap ను పెంచుతుంది. Kernel వద్ద pages అయిపోతాయి. అప్పుడు out-of-memory killer పెద్ద process ను terminate చేస్తుంది. సాధారణంగా అది mongod అవుతుంది. Container Killed ను చూపిస్తుంది. Docker దాన్ని restart చేస్తుంది. తట్టుకోగలిగే load కింద కూడా ప్రతి కొన్ని నిమిషాలకు ఆగిపోయే chat server మీకు మిగులుతుంది. ఇద్దరు వ్యక్తులతో ప్రాథమికంగా పరీక్షించడానికి 2 GB సరిపోతుంది. కానీ team server కు అది సరిపోదు. 4 GB తో ప్రారంభించండి. Dozens of concurrent users, video calls లేదా పెరుగుతున్న upload history ఉంటాయని భావిస్తే 8 GB ఇవ్వండి. ఆ machine నిర్వహించాల్సిన ఇతర సేవలకు కూడా memory ను కేటాయించండి. అదే VPS పై Notion తరహా AFFiNE workspace ఉంచితే, అదే pages కోసం పోటీ పడే మరో నాలుగు containers చేరతాయి. కాబట్టి వాటి RAM, Rocket.Chat కోసం కేటాయించిన RAM కు అదనంగా ఉండాలి; దాని నుంచి తీసుకోకూడదు.

ప్రారంభించే ముందు మరో మూడు విషయాలు సిద్ధంగా ఉండాలి. VPS యొక్క public IP కు చూపించే A record ఉన్న domain name అవసరం. Rocket.Chat యొక్క real-time features మరియు mobile clients కు bare IP కాకుండా స్థిరమైన hostname అవసరం. Ports 80 మరియు 443 open గా ఉండాలి. ఇవి server firewall లోనూ, మీ provider యొక్క network firewall లోనూ తెరిచి ఉండాలి. చాలా control panels లో provider network firewall వేరు అయిన నియంత్రణగా ఉంటుంది. అలాగే root లేదా sudo యాక్సెస్ ఉన్న తాజా Ubuntu 24.04 KVM VPS అవసరం. Chat server మీకు మొదట అమలు చేయాల్సిన సరైన service కాదా అని ఇంకా నిర్ణయించుకుంటే, 2026లో self-hosting చేయడం విలువైన వాటిపై guide tradeoffs ను వివరిస్తుంది.

Docker engine మరియు Compose plugin ను ఇన్‌స్టాల్ చేయండి

Ubuntu అందించే docker.io package ను లేదా పాత standalone docker-compose Python binary ను ఉపయోగించకండి. Docker యొక్క స్వంత apt repository ను ఉపయోగించండి. ఆధునిక Compose అనేది Docker plugin. దీన్ని docker compose, అంటే space తో, invoke చేయాలి; hyphen తో కాదు. పాత docker-compose v1 కు support ముగిసింది. దిగువ 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

రెండు భాగాలు అందుబాటులో ఉన్నాయో నిర్ధారించండి:

sudo docker version
sudo docker compose version

docker compose version version line ను ప్రింట్ చేయడం ముఖ్యం అయిన check. ప్రస్తుత releases Docker Compose version v5.x ను ప్రింట్ చేస్తాయి. (2026-10-10 నాటికి v5.6.0, 2 October 2026 న విడుదలైనది, latest.) పాత install ఇప్పటికీ v2.x ను ప్రింట్ చేయవచ్చు. Docker రెండింటికీ support ఇస్తుంది. Legacy v2 మరియు v3 compose file formats తో గందరగోళం రాకుండా, Compose v5 కు v2 తో functionality పరంగా సమానమని Docker వివరిస్తుంది. అందువల్ల ఈ guide కోసం రెండింటిలో ఏదైనా సరిపోతుంది. docker: 'compose' is not a docker command error వస్తే plugin install కాలేదు. తరువాత గందరగోళపరిచే failures ఎదురవుతాయి. దీన్ని ఇక్కడే సరిచేయండి.

Compose ఫైల్: MongoDB ను single-node replica setగా అమర్చడం

ఇక్కడే చాలామంది తప్పులు చేస్తారు. కాబట్టి నెమ్మదిగా చదవండి. Rocket.Chat కొత్త సందేశాలను అనుసంధానమైన clientలకు real timeలో పంపడానికి MongoDB change streamsను ఉపయోగిస్తుంది. change streams replica setలో మాత్రమే అందుబాటులో ఉంటాయి. Rocket.Chat ను సాధారణ standalone mongod కు చూపిస్తే, అది connect అవుతుంది, change streamను ప్రారంభించడంలో విఫలమవుతుంది, తరువాత నిరంతరం restart loopలోకి వెళ్తుంది. దీనికి క్లిష్టమైన పరిష్కారం అవసరం లేదు: సాధారణ MongoDB containerను నడపండి. అయితే దాన్ని --replSet తో ప్రారంభించి, తరువాత 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ను 127.0.0.1:3000 కు publish చేశారు, 0.0.0.0 కు కాదు. అప్లికేషన్‌లో TLS లేదు కాబట్టి, అదే serverలోని reverse proxy మాత్రమే దాన్ని చేరాలి. ప్రతి interfaceకు bind చేస్తే plaintext login page నేరుగా public internetలోకి బహిర్గతమవుతుంది. MongoDB portను hostకు publish చేయలేదు. అది Compose యొక్క internal network ద్వారా mongodb అనే పేరుతో మాత్రమే అందుబాటులో ఉంటుంది. ఇదే hostnameను MONGO_URL ఉపయోగిస్తుంది. MONGO_URL లో ?replicaSet=rs0 ఉంటుంది. ఇది set పేరును స్పష్టంగా నిర్దేశిస్తుంది. Drivers మధ్య consistent behaviour కోసం దీన్ని సెట్ చేయాలని MongoDB సిఫారసు చేస్తుంది. దీన్ని వదిలిపెట్టడం వల్లనే సమస్య ఏర్పడదు. directConnection కు defaultగా false ఉంటుంది. అందువల్ల setను Rocket.Chat resolve చేయగల hostnameతో initiate చేసినట్లయితే, driver replica setను కనుగొని operationsను primaryకు పంపుతుంది. తదుపరి sectionలో అది అమర్చబడుతుంది. MONGO_OPLOG_URL oplog ఉన్న local databaseను సూచిస్తుంది. ఆధునిక Rocket.Chat change streamsకు ప్రాధాన్యం ఇస్తుంది. అయినప్పటికీ దీన్ని సెట్ చేయడం harmlessగా ఉంటుంది మరియు పాత code paths కూడా పనిచేసేలా చేస్తుంది. depends_on లో condition: service_healthy ఉపయోగించబడుతుంది. అందువల్ల MongoDBకు ping సమాధానం వచ్చే వరకు Compose వేచి ఉండి, తరువాత మాత్రమే Rocket.Chatను ప్రారంభిస్తుంది. healthcheck ఉద్దేశ్యం ఇదే.

రెండు imagesపై నిజమైన version tagsను pin చేయండి: mongo:8.0 మరియు ఇక్కడ చూపినట్లుగా స్పష్టమైన Rocket.Chat release 8.5.1. :latest ను ఎప్పుడూ ఉపయోగించవద్దు. అది unattended docker pull ను అనుకోకుండా జరిగే, migration చేయలేని upgradeగా మార్చుతుంది. Versionను pin చేసే ముందు ప్రస్తుత stable Rocket.Chat release మరియు అది support చేసే MongoDB versionsను తనిఖీ చేయండి. ప్రతి releaseకు Rocket.Chat machine-readable info documentను publish చేస్తుంది. curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}', 8.5.1 కోసం compatibleMongoVersions: ["8.0"] ను return చేస్తుంది. అందువల్ల supported engine mongo:8.0 మాత్రమే. అదనంగా lts flag ఉంటుంది. మీరు తరచుగా పర్యవేక్షించాల్సిన అవసరం లేని server కోసం pin చేయదగిన long-term-support build ఆ releaseనా కాదా అని ఈ flag తెలియజేస్తుంది. ప్రతి project versioned imageను publish చేయదు. అటువంటి సందర్భంలో pin sourceకు మారుతుంది: openGym workout trackerను self-host చేయడం అంటే మారుతూ ఉండే branchను అనుసరించడం కాకుండా, నిర్దిష్ట git tagను checkout చేసి దాని నుంచి build చేయడం.

Replica set ను ప్రారంభించడం

Stack ను ప్రారంభించండి:

sudo docker compose up -d

Rocket.Chat వెంటనే క్రాష్ అవ్వడం మొదలవుతుంది మరియు Docker దానిని పదేపదే రీస్టార్ట్ చేస్తుంది. Replica set ఇంకా సృష్టించబడలేదు కాబట్టి ఇది సహజమే. దీనిని ఒక్కసారి మాన్యువల్‌గా సృష్టించండి:

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

సరైన ఫలితం { ok: 1 }. కొన్ని సెకన్లలోనే ఈ single node తనను తాను primary గా ఎన్నుకుంటుంది; దీనిని నిర్ధారించడానికి ఇలా చేయండి:

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

మీకు PRIMARY కనిపించాలి. ఈ మొత్తం పేజీలో అత్యంత ముఖ్యమైన అంశం host: "mongodb:27017" ఆర్గ్యుమెంట్. మీరు మెంబర్స్ లిస్ట్ లేకుండా కేవలం rs.initiate() అని రన్ చేస్తే, MongoDB ఆ replica set ను కంటైనర్ యొక్క అంతర్గత హోస్ట్ నేమ్ (ఉదాహరణకు a1b2c3d4e5f6 వంటి ఒక random hash) తో ప్రకటిస్తుంది. Rocket.Chat తన సొంత కంటైనర్ నుండి కనెక్ట్ అయ్యేటప్పుడు ఆ పేరును రిజాల్వ్ చేయలేదు, దీనివల్ల MongoDB డ్రైవర్ DNS ఫెయిల్యూర్ చూపిస్తూ MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 అని లాగ్ చేస్తూ లూప్‌లో పడిపోతుంది. ఎల్లప్పుడూ మీ MONGO_URL కి సరిపోయే explicit సర్వీస్ నేమ్‌తోనే initiate చేయండి.

మొదటి బూట్: సర్వీస్ ప్రారంభాన్ని గమనించడం

సెట్ ప్రైమరీగా మారిన తర్వాత, Rocket.Chat తదుపరి రీస్టార్ట్ సజావుగా కనెక్ట్ అవుతుంది మరియు మొదటిసారి రన్ అయ్యే మైగ్రేషన్లను ప్రారంభిస్తుంది. లాగ్స్‌ను ఇలా అనుసరించండి:

sudo docker compose logs -f rocketchat

మీరు వేచి చూడాల్సిన లైన్ స్టార్టప్ బ్యానర్:

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

మొదటి బూట్ నెమ్మదిగా ఉంటుంది, ఎందుకంటే అప్లికేషన్ డేటాబేస్ మైగ్రేషన్లను రన్ చేసి ఇండెక్సులను నిర్మిస్తుంది, కాబట్టి ఆందోళన చెందే ముందు ఒకటి లేదా రెండు నిమిషాలు వేచి ఉండండి. ఒకవేళ లాగ్ MongoServerSelectionError: Server selection timed out after 30000 ms ను ReplicaSetNoPrimary రకానికి చెందిన టోపాలజీ వివరణతో పదేపదే చూపిస్తుంటే, రెప్లికా సెట్ ప్రారంభించబడలేదని అర్థం; ఒకవేళ అది ఏదైనా రాండమ్ హ్యాష్‌పై getaddrinfo ENOTFOUND ను పదేపదే చూపిస్తుంటే, అది తప్పు హోస్ట్‌తో ప్రారంభించబడిందని అర్థం. ఏది ఏమైనా, ఒక అడుగు వెనక్కి వెళ్లండి. మీరు SERVER RUNNING ను చూసిన తర్వాత, Rocket.Chat 127.0.0.1:3000 పై వింటున్నట్లు (listening) అర్థం, ఇప్పుడు దానికి ముందు సరైన హోస్ట్‌నేమ్ మరియు TLS ను అమర్చాల్సిన సమయం ఆసన్నమైంది.

TLS వెనుక ఉంచండి

Rocket.Chat ను ఎప్పుడూ plain HTTP పై ఉంచవద్దు. మీరు http:// ద్వారా ఒక్కసారి లాగిన్ అయినా, మీ అడ్మిన్ పాస్‌వర్డ్ నెట్‌వర్క్‌లో ఎవరికైనా దొరికే ప్రమాదం ఉంది. అదే సర్వర్‌లో reverse proxy ద్వారా TLS termination చేసి, ఆ ట్రాఫిక్‌ను 127.0.0.1:3000 కు ఫార్వర్డ్ చేయండి. ఇక్కడ రెండు విషయాలు ముఖ్యం: Rocket.Chat రియల్-టైమ్ అప్లికేషన్ కాబట్టి, WebSocket upgrade headers ను proxy తప్పనిసరిగా ఫార్వర్డ్ చేయాలి, లేకపోతే అది పనిచేయదు. అలాగే, కంటైనర్ యొక్క ROOT_URL, వినియోగదారులు టైప్ చేసే పబ్లిక్ HTTPS అడ్రస్‌తో ఖచ్చితంగా సరిపోలాలి.

ముందుగా అప్లికేషన్‌కు proxy చేసే మరియు upgrade headers ను ఫార్వర్డ్ చేసే plain HTTP nginx సర్వర్ బ్లాక్‌తో ప్రారంభించండి. దీన్ని /etc/nginx/sites-available/rocketchat గా సేవ్ చేసి, 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; మరియు సర్టిఫికేట్ లేని బ్లాక్ sudo nginx -t పరీక్షలో నెగ్గదు. Nginx ను reload చేయండి (sudo nginx -t && sudo systemctl reload nginx), ఆపై సర్టిఫికేట్ జారీ చేయండి. Ubuntu లో దీనికి అత్యంత సులభమైన మార్గం Certbot మరియు nginx తో Let's Encrypt TLS సర్టిఫికేట్లు: certbot --nginx పైన ఉన్న బ్లాక్‌ను ఉన్నచోటే మారుస్తుంది, listen 443 ssl; ను, ssl_certificate లైన్లను జోడిస్తుంది మరియు 80-to-443 ఆటోమేటిక్ రీడైరెక్ట్‌ను ఏర్పాటు చేస్తుంది, అలాగే ఇది సర్టిఫికేట్ రెన్యూవల్‌ను కూడా షెడ్యూల్ చేస్తుంది. మీరు ఇప్పటికే ఒకే proxy వెనుక అనేక కంటైనర్లను నడుపుతుంటే, అనేక Docker అప్లికేషన్ల కోసం ఆటోమేటిక్ TLS తో Traefik మరింత మెరుగైన ఎంపిక. rocketchat సర్వీస్‌కు router మరియు service లేబుల్స్‌ను జోడిస్తే, Traefik మీ కోసం సర్టిఫికేట్‌ను అభ్యర్థించి రెన్యూ చేస్తుంది, దీనికి nginx బ్లాక్ అవసరం ఉండదు. ఏ పద్ధతిని ఎంచుకున్నా, compose.yml లో ROOT_URL ను https://chat.example.com గా సెట్ చేసి, sudo docker compose up -d ను మళ్ళీ రన్ చేయండి, తద్వారా కంటైనర్ ఈ మార్పును గుర్తిస్తుంది. సర్వర్ పబ్లిక్ ఇంటర్నెట్ నుండి కాకుండా, మీ సొంత నెట్‌వర్క్ లోపల నుండి మాత్రమే అందుబాటులో ఉండాలంటే, దాని ముందు VPS పై self-hosted WireGuard VPN ను ఉంచి, proxy ని tunnel అడ్రస్‌కు bind చేయండి.

మొదటి రన్ సెటప్ విజార్డ్

https://chat.example.com కు వెళ్లండి. Rocket.Chat మిమ్మల్ని చిన్న విజార్డ్ ద్వారా దశలవారీగా నడిపిస్తుంది. మొదట admin account వివరాలను నమోదు చేయాలి: అసలు పేరు, username, email మరియు బలమైన password. ఇది ఉన్న ఏకైక account కాబట్టి, దీనిని కోల్పోవద్దు. తరువాత organisation and server info నమోదు చేయాలి: పేరు, పరిశ్రమ, పరిమాణం, site name మరియు default language. ఇవి రూపకల్పనకు సంబంధించిన వివరాలు మాత్రమే. వాటిని నమోదు చేసి ముందుకు వెళ్లండి. తరువాత నిజంగా ముఖ్యమైన ఎంపిక ఉంటుంది: ఈ workspace ను Rocket.Chat Cloud తో register this workspace చేయాలా, లేదా standalone గా ఉంచాలా.

నమోదు చేస్తే Rocket.Chat gateway ద్వారా mobile push notifications మరియు add-on marketplace అందుబాటులోకి వస్తాయి. అయితే Rocket.Chat cloud తో control-plane సంబంధం ఏర్పడుతుంది. Gateway ద్వారా పంపే push notifications మీ workspace యొక్క నెలవారీ పరిమితిలో లెక్కించబడతాయి. Standalone ఎంపిక server ను పూర్తిగా private గా, బాహ్య dependencies లేకుండా ఉంచుతుంది. అయితే అధికారిక iOS మరియు Android apps కు push notifications రావడం ఆగిపోతుంది. Rocket.Chat documentation ప్రకారం, ఆ apps దాని cloud gateway తో మాత్రమే పనిచేస్తాయి. నమోదు చేయని workspace పై ఆ gateway పనిచేయదు. దీనికి ప్రత్యామ్నాయం మీ స్వంత white-labeled mobile app build ఉపయోగించడం. Push settings లో gateway ను ఆపివేయండి. మీ స్వంత APNs certificates మరియు Firebase Cloud Messaging credentials నమోదు చేయండి. తరువాత అధికారిక app కు బదులుగా మీ app ను users install చేయాలి. Privacy ప్రధాన ఉద్దేశ్యమైతే, users web app నే ఉపయోగిస్తే, లేదా మీ స్వంత mobile app విడుదల చేయడానికి సిద్ధంగా ఉంటే standalone ఎంచుకోండి. అధికారిక apps లో push notifications తప్పనిసరిగా కావాలంటే registration ఎంచుకోండి. తరువాత Admin కింద ఈ ఎంపికను మార్చవచ్చు.

ఎవరికైనా అనుమతి ఇచ్చే ముందు భద్రపరచండి

Rocket.Chat డిఫాల్ట్‌గా open registration on తో వస్తుంది, అంటే Registration Form సెట్టింగ్ Public లో ఉంటుంది, కాబట్టి URL తెలిసిన ఎవరైనా ఖాతాను సృష్టించగలరు. పబ్లిక్ హోస్ట్‌నేమ్ ఉన్నప్పుడు ఇది భద్రతాపరంగా ప్రమాదకరం. Admin → Settings → Accounts → Registration కు వెళ్లి Registration Form ను Disabled కు మార్చండి, దీనివల్ల మీరు ఖాతాలను మాన్యువల్‌గా లేదా ఇన్వైట్ లింక్ ద్వారా సృష్టించవచ్చు, లేదా దానిని Secret URL కు సెట్ చేయవచ్చు. అక్కడే ఉన్నప్పుడు, మీకు ప్రత్యేకంగా పబ్లిక్ రీడ్-ఓన్లీ ఛానల్ అవసరం లేకపోతే Allow Anonymous Read మరియు Allow Anonymous Write ఆప్షన్లను ఆఫ్ చేయండి. ప్రతి ఖాతాను మాన్యువల్‌గా సృష్టించడం కష్టమనిపిస్తే మరియు మీ టీమ్ ఇతర సేవల కోసం కూడా లాగిన్ అవుతుంటే, Rocket.Chat యొక్క OAuth లాగిన్‌ను self-hosted Authentik SSO server కు మళ్లించండి. దీనివల్ల కొత్తగా చేరేవారు లేదా వెళ్ళిపోయేవారి వివరాలను ప్రతి యాప్‌లో విడిగా కాకుండా, ఒకే చోట నిర్వహించవచ్చు.

అప్‌లోడ్‌లు ఎక్కడికి వెళ్లాలో కూడా నిర్ణయించుకోండి. డిఫాల్ట్ File Upload స్టోరేజ్ GridFS, ఇది ప్రతి ఇమేజ్ మరియు అటాచ్‌మెంట్‌ను నేరుగా MongoDB లోనే నిల్వ చేస్తుంది. ఇది సరళంగా ఉన్నప్పటికీ, ప్రజలు స్క్రీన్‌షాట్‌లను పంపే కొద్దీ మీ డేటాబేస్ మరియు మీరు తీసుకునే ప్రతి mongodump పరిమాణం అపరిమితంగా పెరుగుతుంది. Admin → Settings → File Upload లో మీరు స్టోరేజ్‌ను లోకల్ ఫైల్‌సిస్టమ్ లేదా S3-compatible బకెట్‌కు మార్చుకోవచ్చు మరియు ఫైల్ పరిమాణంపై తగిన పరిమితిని విధించవచ్చు. మీ టీమ్ అప్పుడప్పుడు పంపే స్క్రీన్‌షాట్‌లకు బదులుగా పూర్తి ఫోటో లైబ్రరీలను మార్పిడి చేసుకుంటుంటే, వాటిని చాట్ డేటాబేస్‌లో కాకుండా ప్రత్యేక ఫోటో సర్వర్‌లో ఉంచడం మంచిది. PhotoPrism మరియు Immich ల మధ్య పోలిక ద్వారా, ప్రతి దానికి అవసరమైన RAM మరియు బ్యాకప్ కమాండ్ల గురించి తెలుసుకోవచ్చు. చిన్న టీమ్ అయితే GridFS సరిపోతుంది; కానీ కాలక్రమేణా మీ బ్యాకప్‌ల పరిమాణం పెరుగుతుందని గుర్తుంచుకోండి.

mongodump తో బ్యాకప్‌లు

మీ డేటా అంతా mongodb_data వాల్యూమ్‌లో ఉంటుంది. రన్ అవుతున్న డేటాబేస్ నుండి నేరుగా వాల్యూమ్‌ను కాపీ చేయవద్దు, mongodump ఉపయోగించి స్థిరమైన (consistent) డంప్‌ను తీసుకోండి, దీనిని హోస్ట్ మెషీన్‌లోని ఫైల్‌కు స్ట్రీమ్ చేయండి:

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

ఆ ఒక్క gzipped ఆర్కైవ్ మీ మొత్తం వర్క్‌స్పేస్: ఇందులో యూజర్లు, ఛానెల్‌లు, సందేశాలు, సెట్టింగ్‌లు ఉంటాయి; ఒకవేళ మీరు అప్‌లోడ్‌లను GridFS లో ఉంచినట్లయితే, ఆ ఫైళ్లు కూడా ఇందులో ఉంటాయి. మీరు అప్‌లోడ్‌లను ఫైల్‌సిస్టమ్‌కు లేదా S3 కి తరలించినట్లయితే, ఆ స్టోర్‌ను విడిగా బ్యాకప్ చేయండి. కొత్త స్టాక్‌పై రీస్టోర్ చేయడానికి, ముందుగా replica set ను ఇనిషియలైజ్ చేసి, ఆపై ఇలా చేయండి:

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

ఈ ఆర్కైవ్‌ను సర్వర్ వెలుపల, ఆబ్జెక్ట్ స్టోరేజ్, మరొక సర్వర్ లేదా VPS విఫలమైనా బ్యాకప్ సురక్షితంగా ఉండే మరేదైనా చోట కాపీ చేయండి. ఈ డంప్ ప్రక్రియను ప్రతిరోజూ రాత్రి cron ద్వారా రన్ చేయండి. మీరు ఎప్పుడూ రీస్టోర్ చేసి చూడని బ్యాకప్ కేవలం ఒక ఆశ మాత్రమే, అది నిజమైన బ్యాకప్ కాదు; మీకు అవసరమైనప్పుడు ఇబ్బంది కలగకుండా, ఒకసారి తాత్కాలిక VPS పై రీస్టోర్ చేసి ప్రాక్టీస్ చేయండి.

అప్‌గ్రేడ్‌లు: tags ను pin చేయండి, notes చదవండి, MongoDB matrix ను పాటించండి

అప్‌గ్రేడ్‌లను సమస్యలేమీ లేకుండా నిర్వహించడానికి రెండు నియమాలు పాటించాలి. మొదటిది, Rocket.Chat ను ఒక్కసారి ఒక major version చొప్పున మాత్రమే అప్‌గ్రేడ్ చేయాలి. ఇది boot సమయంలో schema migrations అమలు చేస్తుంది. Rocket.Chat అప్‌గ్రేడ్ documentation ప్రకారం major versions మధ్య ఎల్లప్పుడూ వరుసగా అప్‌డేట్ చేయాలి. Major versions ను దాటితే తీవ్రమైన compatibility సమస్యలు రావచ్చని అది హెచ్చరిస్తుంది. Software స్వయంగా మిమ్మల్ని ఆపుతుందని నమ్మవద్దు. 6.x నుంచి నేరుగా 8.x కు చేసే jump ను సురక్షితంగా నిరాకరిస్తామని దాని documentation లో ఎక్కడా హామీ లేదు. Migration మధ్యలో విఫలమైతే దాని lock అలాగే మిగిలి, manual repair అవసరం అవుతుంది. Image tag ను తదుపరి major version యొక్క తాజా release కు మార్చండి. ఆ release లోని breaking changes గురించి notes చదవండి. docker compose up -d ను run చేయండి. తరువాత ముందుకు వెళ్లే ముందు logs లో migration పూర్తయిందో monitor చేయండి. రెండవది, MongoDB support matrix ను పాటించాలి. ప్రతి Rocket.Chat release నిర్దిష్ట MongoDB versions సమితికి support ఇస్తుంది. ఏ versions support అవుతున్నాయో curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions తెలియజేస్తుంది. MongoDB ను మార్చేటప్పుడు, ఉదాహరణకు 7.0 నుంచి 8.0 కు మారేటప్పుడు, ఒక్కసారి ఒక major version చొప్పున మాత్రమే ముందుకు వెళ్లాలి. ప్రతి మార్పు తర్వాత feature-compatibility version ను సెట్ చేయాలి. MongoDB 8.0లో ఆ command కు స్పష్టమైన confirm: true అవసరం. లేకపోతే confirmation flag తో మళ్లీ run చేయమని message చూపిస్తూ command విఫలమవుతుంది:

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

ఏ component ను అప్‌గ్రేడ్ చేసే ముందు అయినా mongodump తీసుకోండి. ఇదే మొత్తం రక్షణ.

వైఫల్య పరిస్థితులు, ఖచ్చితమైన stringలతో

docker compose up తర్వాత వెంటనే Rocket.Chat restart loopలోకి వెళ్తుంది, మరియు docker compose logs rocketchat లో MongoServerSelectionError నిండుతుంది. MongoDB నడుస్తున్నప్పటికీ driver primaryని select చేయలేకపోతోంది. మీరు చేసిన తప్పు ఏమిటో exact string తెలియజేస్తుంది. ReplicaSetNoPrimary topology typeతో ఉన్న Server selection timed out after 30000 ms అంటే మీరు ఇంకా rs.initiate() అమలు చేయలేదు; setకు configuration లేదు. getaddrinfo ENOTFOUND తర్వాత random hash కనిపిస్తే, మీరు స్పష్టమైన host: "mongodb:27017" లేకుండా initiate చేశారు. అందువల్ల MongoDB పరిష్కరించలేని container hostnameను ప్రకటించింది. 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తో మళ్లీ initiate చేయండి.

Web UI load అవుతుంది, కానీ login నిరంతరం తిరుగుతూ పూర్తికాదు. Browser console తెరిస్తే WebSocket connection to 'wss://chat.example.com/websocket' failed కనిపిస్తుంది. ఇది దాదాపు ఎల్లప్పుడూ ROOT_URL mismatch వల్ల లేదా upgrade headersను forward చేయని proxy వల్ల జరుగుతుంది. ROOT_URL లో https:// సహా ఖచ్చితమైన 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. Serverలో RAM సరిపోవడం లేదు. సరైన పరిష్కారం పెద్ద VPS ఉపయోగించడం; కనీసం 4 GB RAM అవసరం. తాత్కాలికంగా swap జోడించండి. అలాగే MongoDB cacheను దాని command లోని --wiredTigerCacheSizeGB తో పరిమితం చేయండి. విలువను default కంటే తక్కువగా ఉంచాలి, ఎక్కువగా కాదు. ఉదాహరణకు 4 GB serverలో 1 (default 1.5), 2 GB serverలో 0.3 (default సుమారు 0.5) ఉపయోగించవచ్చు. అయితే నిజమైన 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 తో విఫలమవుతుంది. Port 3000ను ఇప్పటికే మరొక ప్రక్రియ ఉపయోగిస్తోంది. సాధారణంగా సరిగ్గా ఆగని పాత Rocket.Chat container లేదా మరొక application దీనికి కారణం. sudo ss -ltnp | grep :3000 తో దాన్ని కనుగొనండి. ఆ process లేదా containerను ఆపండి. ప్రత్యామ్నాయంగా mappingలో host వైపు portను 127.0.0.1:3001:3000 కు మార్చి, దానికి సరిపోయేలా మీ proxyలోని proxy_pass ను update చేయండి.

FAQ

Rocket.Chat కు నిజంగా MongoDB replica set అవసరమా?

అవును. ఒక database node ఉన్న single server అయినా ఇది అవసరం. MongoDB change streams ను ఉపయోగించి Rocket.Chat messages ను real time లో అందిస్తుంది. change streams అనేది replica set కు మాత్రమే అందుబాటులో ఉన్న feature. standalone mongod ను ఉపయోగించి దాన్ని తెరవలేరు. మీకు అనేక machines అవసరం లేదు. --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 అవసరం?

ఆచరణలో కనీసంగా 4 GB, busy team కోసం 8 GB కేటాయించండి. Rocket.Chat యొక్క Node process సుమారు 1 నుంచి 1.5 GB ఉపయోగిస్తుంది. MongoDB యొక్క default WiredTiger cache మొత్తం RAM నుంచి 1 GB తీసివేసిన విలువలో సగంగా ఉంటుంది. ఇతర processes ఏవీ లేవన్నట్లు ఇది memory ను కేటాయిస్తుంది. 2 GB box లో ఆ cache, Node heap, mongod యొక్క overhead పరస్పరం memory కోసం పోటీ పడతాయి. నిజమైన load ఉన్నప్పుడు out-of-memory killer mongod ను terminate చేస్తుంది. Logs లో Killed కనిపిస్తుంది, exit code 137 వస్తుంది. ఇద్దరు test users తో software ను పరీక్షించడానికి మాత్రమే 2 GB సరిపోతుంది.

Rocket.Chat ను HTTPS వెనుక ఎలా ఉంచాలి?

TLS ను terminate చేసి 127.0.0.1:3000 కు forward చేసే reverse proxy ను అదే VPS పై నడపండి. Container లోని ROOT_URL ను మీ public https:// address కు సెట్ చేయండి. Proxy WebSocket upgrade headers ను forward చేయాలి. లేకపోతే login నిలిచిపోతుంది. Single-app setup కోసం nginx తో Certbot సరళమైన ఎంపిక. ఒకే proxy వెనుక అనేక containers నడిపి, certificate management ను automatic గా చేయాలనుకుంటే 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. మీరు storage ను GridFS లోనే ఉంచితే, ఆ archive లో users, channels, messages, settings తో పాటు uploaded files కూడా ఉంటాయి. దాన్ని server వెలుపల copy చేయండి. cron తో ప్రతి రాత్రి దీనిని automate చేయండి. Restore నిజంగా పనిచేస్తుందో నిర్ధారించుకోవడానికి throwaway box పై mongorestore ను practice చేయండి.

MongoDB ను పాడుచేయకుండా Rocket.Chat ను ఎలా upgrade చేయాలి?

Rocket.Chat ను ఒక major version చొప్పున upgrade చేయండి. ఇది boot సమయంలో migrations నడుపుతుంది. Major versions ను దాటితే severe compatibility issues రావచ్చని దాని documentation హెచ్చరిస్తుంది; మిమ్మల్ని ఆపుతుందని హామీ ఇవ్వదు. Pinned image tag ను మార్చే ముందు ప్రతి release యొక్క notes చదవండి. మీ target release ఏ MongoDB versions కు support ఇస్తుందో curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions తో తనిఖీ చేయండి. MongoDB ను upgrade చేసేటప్పుడు కూడా ఒక major version చొప్పున ముందుకు వెళ్లండి. ప్రతి దశ తర్వాత confirm: true తో setFeatureCompatibilityVersion ను సెట్ చేయండి. ముందుగా ఎల్లప్పుడూ mongodump తీసుకోండి.