Docker Compose سے Rocket.Chat خود ہوسٹ کرنے کا طریقہ

آپ کیا بنا رہے ہیں

ایک نجی ٹیم چیٹ جس کی مکمل ملکیت آپ کے پاس ہو: Rocket.Chat آپ کے اپنے VPS پر Docker Compose کے تحت چل رہا ہو، TLS کے ذریعے محفوظ ہو، اور ہر پیغام MongoDB database میں محفوظ ہو جس کا backup لے کر اسے منتقل بھی کیا جا سکے۔ Rocket.Chat ایک پختہ open-source Slack اور Teams متبادل ہے۔ اس میں channels، direct messages، threads، file sharing، voice اور video شامل ہیں، اور یہ سب ایسے hardware پر چلتا ہے جسے آپ کرائے پر لے کر خود manage کرتے ہیں۔ application ایک single container ہے جو چند منٹ میں شروع ہو جاتا ہے۔ عملی طور پر جو مسائل پیش آتے ہیں، وہ اسی کے ساتھ موجود database میں ہوتے ہیں۔ اسی لیے اس guide کا زیادہ حصہ MongoDB کے بارے میں ہے، خصوصاً اس ایک requirement کے بارے میں جو پہلی بار سب کو حیران کرتی ہے: Rocket.Chat standalone MongoDB کے ساتھ نہیں چلتا۔ اسے replica set درکار ہوتا ہے، چاہے وہ "set" صرف ایک node پر مشتمل ہو۔

شرائطِ تیاری، اور RAM کا وہ حساب جو کوئی نہیں بتاتا

سرور کے وسائل کا حقیقت پسندانہ اندازہ لگائیں۔ ایک چھوٹی ٹیم کے لیے عملی کم از کم ضرورت 2 vCPU اور 4 GB RAM ہے۔ Rocket.Chat کا Node.js process اکیلے تقریباً 1 سے 1.5 GB میموری چاہتا ہے، جبکہ MongoDB کا WiredTiger cache بطورِ طے شدہ باقی دستیاب RAM کا تقریباً نصف استعمال کرتا ہے۔ 2 GB VPS پر دونوں process boot کے وقت چل جاتے ہیں، لیکن حقیقی network traffic آتے ہی وسائل کے لیے مسابقت شروع ہو جاتی ہے: MongoDB اپنا cache بڑھاتا ہے، Node اپنا heap بڑھاتا ہے، kernel کے پاس pages ختم ہو جاتے ہیں، اور out-of-memory killer عموماً سب سے بڑے process، یعنی mongod، کو بند کر دیتا ہے۔ container Killed دکھاتا ہے، Docker اسے دوبارہ شروع کرتا ہے، اور یوں chat server اس load کے دوران ہر چند منٹ بعد بند ہو جاتا ہے جسے اسے آسانی سے سنبھال لینا چاہیے۔ دو افراد کے ساتھ ابتدائی آزمائش کے لیے 2 GB کافی ہے؛ یہ ٹیم کے لیے موزوں server نہیں ہے۔ 4 GB سے شروع کریں، اور اگر آپ کو درجنوں بیک وقت users، video calls، یا بڑھتی ہوئی upload history کی توقع ہے تو 8 GB دیں۔

شروع کرنے سے پہلے تین چیزیں موجود ہونی چاہییں۔ ایک domain name، جس کا A record VPS کے public IP کی طرف نشاندہی کرتا ہو؛ Rocket.Chat کے real-time features اور mobile clients کے لیے bare IP کے بجائے مستحکم hostname درکار ہوتا ہے۔ Ports 80 اور 443 کھلے ہوں، server firewall اور provider کے network firewall، دونوں پر؛ زیادہ تر panels میں یہ الگ control ہوتا ہے۔ اس کے علاوہ root یا sudo کے ساتھ نیا Ubuntu 24.04 KVM VPS درکار ہے۔ اگر آپ ابھی یہ طے کر رہے ہیں کہ chat server پہلی service کے طور پر چلانے کے لیے مناسب ہے یا نہیں، تو 2026 میں self-hosting کے قابل چیزوں کی guide مختلف اختیارات کے فائدے اور نقصانات واضح کرتی ہے۔

Docker engine اور Compose plugin انسٹال کریں

Docker کا اپنا apt repository استعمال کریں۔ Ubuntu کے فراہم کردہ docker.io package کے بجائے اسے استعمال کریں، اور قدیم standalone docker-compose Python binary بھی استعمال نہ کریں۔ جدید Compose ایک Docker plugin ہے، جسے docker compose کے طور پر invoke کیا جاتا ہے۔ درمیان میں space ہوتا ہے، hyphen نہیں۔ پرانا docker-compose v1 اب end-of-life ہے اور نیچے دی گئی healthcheck اور dependency syntax کو درست طور پر handle نہیں کرتا۔

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 کا Docker Compose version v2.x جیسی output دینا ہی متعلقہ check ہے۔ اگر یہ docker: 'compose' is not a docker command error دے تو plugin انسٹال نہیں ہوا۔ بعد میں الجھن پیدا کرنے والی failures سے بچنے کے لیے اسے یہیں درست کریں۔

Compose فائل: MongoDB بطور single-node replica set

یہ وہ حصہ ہے جہاں لوگ عموماً غلطی کرتے ہیں، اس لیے اسے آہستہ پڑھیں۔ Rocket.Chat نئے پیغامات connected clients تک real time میں بھیجنے کے لیے 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 127.0.0.1:3000 پر publish کیا گیا ہے، 0.0.0.0 پر نہیں۔ ایپ خود TLS استعمال نہیں کرتی، اس لیے اسی host پر موجود reverse proxy کو ہی اس تک رسائی ہونی چاہیے؛ اسے ہر interface پر bind کرنے سے plaintext login page براہ راست public internet پر آ جائے گا۔ MongoDB کو host پر بالکل publish نہیں کیا گیا؛ یہ صرف Compose کے internal network کے ذریعے mongodb نام کے تحت دستیاب ہے، اور MONGO_URL بھی یہی hostname استعمال کرتا ہے۔ MONGO_URL، ?replicaSet=rs0 کو منتقل کرتا ہے۔ اسے چھوڑنے سے driver server کو replica set ہونے کے باوجود standalone سمجھتا ہے، اور change streams پھر بھی ناکام رہتے ہیں۔ MONGO_OPLOG_URL، local database کی طرف اشارہ کرتا ہے جہاں oplog موجود ہوتا ہے؛ جدید Rocket.Chat change streams کو ترجیح دیتا ہے، لیکن اسے set کرنا بے ضرر ہے اور پرانے code paths کو بھی درست رکھتا ہے۔ depends_on میں condition: service_healthy استعمال ہوتا ہے، اس لیے Compose MongoDB کے ping کا جواب دینے تک Rocket.Chat کو start نہیں کرتا۔ healthcheck کا مقصد یہی ہے۔

دونوں images پر حقیقی version tags مقرر کریں: mongo:8.0 اور یہاں 8.5.1 جیسی واضح Rocket.Chat release استعمال کریں۔ :latest کبھی استعمال نہ کریں، کیونکہ اس سے unattended docker pull ایک حادثاتی، ناقابلِ migration upgrade میں تبدیل ہو جاتا ہے۔ Pin مقرر کرنے سے پہلے موجودہ stable Rocket.Chat release اور اس کے supported MongoDB versions کی تصدیق کریں۔ Rocket.Chat ہر release کے لیے machine-readable معلوماتی document شائع کرتا ہے: 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 ہے جسے ایسے server کے لیے pin کرنا مناسب ہے جس کی مسلسل نگرانی آپ نہیں کرنا چاہتے۔ ہر project versioned image شائع نہیں کرتا۔ ایسی صورت میں pin source پر لاگو ہوتا ہے: self-hosting the openGym workout tracker کا مطلب ہے کہ moving branch کی پیروی کرنے کے بجائے مخصوص git tag checkout کر کے اسی سے build کریں۔

ریپلیکا سیٹ شروع کریں

Stack کو شروع کریں:

sudo docker compose up -d

Rocket.Chat فوراً crash ہونا شروع ہو جائے گا اور Docker اسے مسلسل restart کرتا رہے گا۔ یہ متوقع ہے، کیونکہ ابھی 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" argument ہے۔ اگر آپ members list کے بغیر سادہ rs.initiate() چلاتے ہیں تو MongoDB replica set کو container کے internal hostname کے تحت advertise کرتا ہے، مثلاً a1b2c3d4e5f6 جیسا random hash۔ اپنے container سے connect کرتے وقت Rocket.Chat اس نام کو resolve نہیں کر سکتا، اس لیے MongoDB driver اس پر DNS failure کے بعد مسلسل loop میں رہتا ہے اور MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6 log کرتا رہتا ہے۔ ہمیشہ اپنے MONGO_URL سے مطابقت رکھنے والے explicit service name کے ساتھ initiate کریں۔

پہلا boot: startup کی نگرانی کریں

جب set primary بن جائے گا تو Rocket.Chat کا اگلا restart کامیابی سے connect ہو جائے گا اور پہلی بار کی migrations شروع کر دے گا۔ logs کی نگرانی کریں:

sudo docker compose logs -f rocketchat

جس line کا انتظار کرنا ہے وہ startup banner ہے:

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

پہلا 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 کر رہا ہوگا، اور اب اس کے سامنے حقیقی hostname اور TLS رکھنے کا وقت ہے۔

اسے TLS کے پیچھے رکھیں

Rocket.Chat کو کبھی بھی plain HTTP پر براہ راست دستیاب نہ کریں۔ http:// کے ذریعے لاگ ان کرنے پر آپ اپنا admin password راستے میں موجود ہر شخص کے حوالے کر دیتے ہیں۔ اسی سرور پر موجود 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 سے match ہونا چاہیے جو صارفین درج کرتے ہیں۔

ایک سادہ HTTP nginx server block سے آغاز کریں جو app کو proxy کرے اور upgrade headers forward کرے۔ اسے /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; اور certificate کے بغیر block sudo nginx -t بھی پاس نہیں کرے گا۔ nginx کو reload کریں (sudo nginx -t && sudo systemctl reload nginx)، پھر certificate جاری کریں۔ Ubuntu پر صاف ترین طریقہ Certbot اور nginx کے ساتھ Let's Encrypt TLS certificates ہے: certbot --nginx اوپر والے block کو وہیں rewrite کرتا ہے، listen 443 ssl;، ssl_certificate lines اور خودکار 80-to-443 redirect شامل کرتا ہے، اور آپ کے لیے renewal schedule کر دیتا ہے۔ اگر آپ پہلے ہی ایک proxy کے پیچھے متعدد containers چلا رہے ہیں تو متعدد Docker apps کے لیے automatic TLS کے ساتھ Traefik زیادہ منظم انتخاب ہے۔ rocketchat service میں router اور service labels شامل کریں، پھر Traefik آپ کے لیے certificate کی درخواست اور renewal کر دے گا، اور nginx block کی ضرورت نہیں رہے گی۔ دونوں صورتوں میں compose.yml میں ROOT_URL کو https://chat.example.com پر set کریں اور sudo docker compose up -d دوبارہ چلائیں تاکہ container یہ تبدیلی حاصل کر لے۔ اگر آپ چاہتے ہیں کہ server public internet کے بجائے صرف آپ کے اپنے network کے اندر سے قابل رسائی ہو تو اسے VPS پر self-hosted WireGuard VPN کے ذریعے سامنے رکھیں اور proxy کو tunnel address پر bind کریں۔

پہلی مرتبہ چلانے کا سیٹ اپ وزارڈ

https://chat.example.com پر جائیں۔ Rocket.Chat آپ کو ایک مختصر وزارڈ کے مراحل سے گزارے گا۔ پہلے admin account بنائیں۔ اس میں اصل نام، username، email اور مضبوط password شامل ہیں۔ یہ واحد موجود account ہوگا، اس لیے اسے ضائع نہ کریں۔ اس کے بعد organisation and server info درج کریں: نام، industry، size، 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 تعلق قائم ہوتا ہے۔ Standalone رکھنے سے server مکمل طور پر private اور dependency-free رہتا ہے، لیکن iOS اور Android push notifications کام کرنا بند کر دیتی ہیں۔ اس کی وجہ یہ ہے کہ Apple اور Google self-built app کو push certificates رکھنے کی اجازت نہیں دیتے، جبکہ official apps cloud gateway کے ذریعے notifications بھیجتی ہیں۔ اگر privacy بنیادی مقصد ہے اور آپ کے users web app استعمال کرتے ہیں تو standalone منتخب کریں۔ اگر mobile push ناگزیر ہے تو registration منتخب کریں۔ بعد میں Admin کے تحت یہ انتخاب تبدیل کیا جا سکتا ہے۔

سب کو مدعو کرنے سے پہلے اسے محفوظ بنائیں

Rocket.Chat میں بطور ڈیفالٹ open registration فعال ہوتی ہے۔ Registration Form کی قدر Public مقرر ہوتی ہے، اس لیے URL تلاش کرنے والا کوئی بھی شخص اکاؤنٹ بنا سکتا ہے۔ Public hostname پر یہ ایک کھلا راستہ ہے۔ Admin → Settings → Accounts → Registration پر جائیں اور Registration Form کو Disabled پر مقرر کریں، تاکہ آپ اکاؤنٹس خود بنائیں یا invite link کے ذریعے بنوائیں، یا اسے Secret URL پر مقرر کریں۔ اسی دوران Allow Anonymous Read اور Allow Anonymous Write کو بھی بند کر دیں، جب تک کہ آپ خاص طور پر public read-only channel نہ چاہتے ہوں۔ اگر ہر اکاؤنٹ خود بنانا مشکل لگتا ہے اور آپ کی ٹیم کسی دوسری service میں بھی login کرتی ہے تو Rocket.Chat کے OAuth login کو self-hosted Authentik SSO server سے منسلک کریں۔ اس طرح نئے شامل ہونے والے اور رخصت ہونے والے صارفین کو ہر ایپ میں الگ الگ manage کرنے کے بجائے ایک ہی جگہ manage کیا جا سکے گا۔

یہ بھی طے کریں کہ uploads کہاں محفوظ ہوں گی۔ ڈیفالٹ File Upload storage، GridFS ہے، جو ہر image اور attachment کو خود MongoDB کے اندر محفوظ کرتا ہے۔ یہ طریقہ سادہ ہے، لیکن اس کا مطلب ہے کہ آپ کا database اور آپ کے بنائے ہوئے ہر mongodump وقت کے ساتھ بڑھتے رہیں گے، کیونکہ لوگ screenshots paste کرتے رہیں گے۔ Admin → Settings → File Upload کے تحت آپ storage کو local filesystem یا S3-compatible bucket پر منتقل کر سکتے ہیں اور file size کی مناسب زیادہ سے زیادہ حد مقرر کر سکتے ہیں۔ چھوٹی ٹیم کے لیے GridFS مناسب ہے؛ بس یہ سمجھ لیں کہ وقت کے ساتھ آپ کے backups بڑے ہوتے جائیں گے۔

mongodump کے ساتھ بیک اپس

آپ کا تمام ڈیٹا 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

یہ واحد gzipped archive آپ کے پورے workspace پر مشتمل ہے: users، channels، messages، settings، اور اگر uploads کو GridFS پر رکھا گیا ہو تو files بھی۔ اگر آپ نے uploads کو filesystem یا S3 پر منتقل کیا ہے تو اس store کا الگ بیک اپ لیں۔ تازہ stack پر restore کرنے کے لیے پہلے replica set کو initialise کریں، پھر:

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

Archive کو box سے باہر copy کریں: object storage، کسی دوسرے server یا کسی بھی ایسی جگہ جہاں VPS کے بند ہونے سے backup ضائع نہ ہو۔ Dump کو cron سے ہر رات چلائیں۔ ایسا backup جسے آپ نے کبھی restore نہ کیا ہو، backup نہیں بلکہ محض امید ہے؛ کسی throwaway VPS پر ایک بار restore کی مشق کریں تاکہ ضرورت پڑنے سے پہلے یقین ہو جائے کہ یہ کام کرتا ہے۔

اپ گریڈز: tags pin کریں، notes پڑھیں، Mongo matrix کی پابندی کریں

دو اصول اپ گریڈز کو معمول کے مطابق رکھتے ہیں۔ پہلا، Rocket.Chat کو ہر بار صرف ایک major version اپ گریڈ کریں۔ یہ boot کے وقت schema migrations چلاتا ہے اور جان بوجھ کر major versions کو چھوڑ کر آگے بڑھنے سے انکار کرتا ہے؛ اگر آپ 6.x سے براہِ راست 8.x پر جانے کی کوشش کریں گے تو یہ data خراب کرنے کے بجائے migration error کے ساتھ رک جائے گا۔ image tag کو اگلے major کی latest release پر تبدیل کریں، اس release کی notes میں breaking changes پڑھیں، docker compose up -d چلائیں، اور آگے بڑھنے سے پہلے logs میں migration مکمل ہونے کی نگرانی کریں۔ دوسرا، MongoDB support matrix کی پابندی کریں۔ ہر Rocket.Chat release، MongoDB versions کے ایک مخصوص set کو support کرتی ہے، اور curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions آپ کو بتاتا ہے کہ کون سے versions supported ہیں۔ جب MongoDB کو منتقل کریں، مثلاً 7.0 سے 8.0 تک، تو ایک وقت میں صرف ایک major version آگے بڑھیں اور ہر مرحلے کے بعد feature-compatibility version set کریں۔ MongoDB 8.0 میں اس command کے لیے واضح طور پر confirm: true درکار ہوتا ہے، ورنہ یہ ایک message کے ساتھ انکار کر دیتی ہے جس میں confirmation flag کے ساتھ اسے دوبارہ چلانے کو کہا جاتا ہے:

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

کسی بھی component کو اپ گریڈ کرنے سے پہلے mongodump لیں۔ یہی مکمل حفاظتی انتظام ہے۔

ناکامی کی صورتیں، درست strings کے ساتھ

docker compose up کے فوراً بعد Rocket.Chat restart loop میں چلا جاتا ہے، اور docker compose logs rocketchat میں MongoServerSelectionError بھر جاتا ہے۔ MongoDB چل رہا ہے، لیکن driver primary منتخب نہیں کر پا رہا۔ درست string بتاتی ہے کہ غلطی کہاں ہوئی۔ Server selection timed out after 30000 ms میں topology type ReplicaSetNoPrimary ہو تو اس کا مطلب ہے کہ آپ نے کبھی rs.initiate() نہیں چلایا؛ set میں ابھی configuration موجود نہیں۔ getaddrinfo ENOTFOUND کے بعد random hash ظاہر ہو تو اس کا مطلب ہے کہ آپ نے واضح host: "mongodb:27017" کے بغیر initialization کیا، اس لیے MongoDB نے ایسا container hostname ظاہر کیا جسے resolve نہیں کیا جا سکتا۔ sudo docker compose exec mongodb mongosh --eval 'rs.status()' سے تشخیص کریں: اگر اس میں MongoServerError: no replset config has been received کا error آئے تو set کو initiate کریں؛ اگر اس میں ایسا member دکھائی دے جس کا name random hash ہو تو service name کے ساتھ دوبارہ initiate کریں۔

Web UI لوڈ ہو جاتا ہے، لیکن login ہمیشہ گھومتا رہتا ہے اور مکمل نہیں ہوتا۔ Browser console کھولیں۔ وہاں WebSocket connection to 'wss://chat.example.com/websocket' failed نظر آئے گا۔ اس کی تقریباً ہمیشہ وجہ ROOT_URL کا mismatch یا ایسا proxy ہوتا ہے جو upgrade headers forward نہیں کر رہا۔ تصدیق کریں کہ ROOT_URL بالکل درست public address کے برابر ہو، جس میں https:// بھی شامل ہو، اور یہ کہ آپ کے nginx کے location block میں Upgrade اور Connection "upgrade" کو proxy_http_version 1.1 کے ساتھ set کیا گیا ہو۔ کسی بھی تبدیلی کے بعد docker compose up -d دوبارہ چلائیں۔

کوئی container بار بار بند ہو جاتا ہے اور docker compose ps میں Restarting دکھائی دیتا ہے۔ docker compose logs درمیانِ line رک جاتا ہے، جبکہ sudo dmesg | tail میں oom-killer کی طرف سے Out of memory: Killed process 12345 (mongod) دکھائی دیتا ہے؛ exit code 137 ہوتا ہے۔ سرور میں RAM ناکافی ہے۔ اصل حل بڑا VPS استعمال کرنا ہے، کم از کم 4 GB۔ عارضی حل کے طور پر swap شامل کریں اور MongoDB کے cache کو اس کے command میں --wiredTigerCacheSizeGB 1 کے ذریعے محدود کریں، لیکن حقیقی 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 پہلے ہی کسی 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 کی ضرورت ہے؟

جی ہاں، ایک database node والے single server کے لیے بھی۔ Rocket.Chat پیغامات real time میں deliver کرنے کے لیے MongoDB change streams استعمال کرتا ہے، اور change streams صرف replica set میں دستیاب feature ہیں۔ Standalone mongod اسے کھول نہیں سکتا۔ آپ کو متعدد machines کی ضرورت نہیں؛ ایک MongoDB container کو --replSet rs0 کے ساتھ start کریں اور rs.initiate() سے one-member set initialise کریں۔ یہ مرحلہ چھوڑنے پر driver کو primary نہیں ملتا، اس لیے Rocket.Chat MongoServerSelectionError: Server selection timed out کے ساتھ restart loop میں چلا جاتا ہے اور boot مکمل نہیں کر پاتا۔

self-hosted Rocket.Chat کے لیے کتنی RAM درکار ہے؟

عملی minimum کے طور پر 4 GB اور مصروف team کے لیے 8 GB رکھیں۔ Rocket.Chat کا Node process تقریباً 1 سے 1.5 GB استعمال کرتا ہے، جبکہ MongoDB باقی RAM کا تقریباً نصف اپنی WiredTiger cache کے لیے مختص کرتا ہے۔ اس لیے 2 GB کے server پر دونوں کے درمیان RAM کے لیے مقابلہ ہوتا ہے، اور حقیقی 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 پر set کریں۔ Proxy کو WebSocket upgrade headers forward کرنے چاہییں، ورنہ login رک جائے گا۔ ایک single-app setup کے لیے nginx کے ساتھ Certbot آسان ترین طریقہ ہے۔ اگر آپ ایک proxy کے پیچھے متعدد containers چلاتے ہیں اور certificate management خودکار چاہتے ہیں تو Traefik زیادہ صاف حل ہے۔

self-hosted Rocket.Chat کا backup کیسے لوں؟

Volume copy کرنے کے بجائے mongodump سے database کا consistent dump لیں: docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz۔ اس archive میں users، channels، messages اور settings شامل ہوتے ہیں، اور اگر storage کو GridFS پر رہنے دیا ہو تو uploaded files بھی شامل ہوتی ہیں۔ Archive کو server سے باہر copy کریں، cron کے ذریعے اسے ہر رات خودکار بنائیں، اور کسی عارضی server پر mongorestore کی مشق کریں تاکہ تصدیق ہو جائے کہ restore واقعی کام کرتا ہے۔

MongoDB کو توڑے بغیر Rocket.Chat کو کیسے upgrade کروں؟

Rocket.Chat کو ایک وقت میں ایک major version upgrade کریں۔ یہ boot کے وقت migrations چلاتا ہے اور major versions skip کرنے سے انکار کرتا ہے۔ Pinned image tag تبدیل کرنے سے پہلے ہر release کی notes پڑھیں۔ curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions سے معلوم کریں کہ آپ کا target release کن MongoDB versions کو support کرتا ہے۔ MongoDB upgrade کرتے وقت بھی ایک وقت میں ایک major version آگے بڑھیں، اور ہر مرحلے کے بعد confirm: true کے ساتھ setFeatureCompatibilityVersion set کریں۔ ہمیشہ پہلے mongodump لیں۔