बेहतरीन self-hosted Slack विकल्प: तुलना और गाइड

आपको कौन सा self-hosted Slack विकल्प चलाना चाहिए

एक छोटी टीम के लिए विचार करने योग्य self-hosted Slack विकल्प Mattermost, Rocket.Chat, Matrix (Synapse के साथ) और Zulip हैं। यदि आप एक ही सर्वर पर आंतरिक टीम टूल चलाना चाहते हैं, तो Mattermost का उपयोग करें। सार्वजनिक समुदाय के लिए, Zulip चलाएं। Matrix को Synapse के साथ तभी चलाएं जब आपको अन्य लोगों के स्वामित्व वाले सर्वर से बात करने की आवश्यकता हो, क्योंकि federation ही वह एकमात्र विशेषता है जिसे अन्य विकल्प कॉपी नहीं कर सकते, और यही वह चीज है जो एक प्रशासक के रूप में आपके काम को बदल देती है।

फीचर सूचियाँ इन चारों के बीच अंतर स्पष्ट नहीं करेंगी। ये सभी channels, threads, search, file uploads और mobile apps की सुविधा देते हैं। जो चीज इन्हें अलग बनाती है, वह यह है कि ये हर महीने आपसे क्या मांगते हैं: memory, एक database जिसे आपको चालू रखना है, mobile push का एक ऐसा रास्ता जिसे आप शायद नियंत्रित न कर सकें, और एक licence जो यह तय करता है कि आपकी जरूरत का फीचर भुगतान के दायरे में है या नहीं। नीचे दी गई तुलना इन आधारों पर 10 और 100 उपयोगकर्ताओं के लिए की गई है।

ये चारों वास्तव में क्या हैं

Mattermost एक PostgreSQL डेटाबेस के साथ एक Go सर्वर है। एक बाइनरी, एक डेटाबेस, एक कॉन्फ़िगरेशन फ़ाइल। यह Slack की तरह काम करता है, जिसमें थ्रेड्स और स्लैश कमांड्स शामिल हैं, और इसे संचालित करना इन चारों में सबसे आसान है, जिसे एक प्रशंसा के रूप में देखा जाना चाहिए।

Rocket.Chat MongoDB पर चलने वाला एक Node.js एप्लिकेशन है। इसमें यहाँ बताए गए विकल्पों में सबसे व्यापक फीचर सेट है, जिसमें वॉयस और वीडियो कॉल, और एक ओमनीचैनल इनबॉक्स शामिल है जो ईमेल और सोशल चैनलों से ग्राहकों की बातचीत को एक ही इंटरफ़ेस में लाता है। यदि आप केवल उस इनबॉक्स के कारण इसे देख रहे हैं, तो पहले एक समर्पित Chatwoot सपोर्ट डेस्क के साथ इसकी तुलना करें, क्योंकि सपोर्ट का काम करने वाला चैट सर्वर टीम वर्क करने वाले चैट सर्वर से अलग होता है।

Matrix एक प्रोटोकॉल है, कोई उत्पाद नहीं। Synapse इसका रेफरेंस सर्वर (Python, PostgreSQL) है और Element वह क्लाइंट है जिसे अधिकांश लोग उपयोग करते हैं। यह यहाँ एकमात्र विकल्प है जहाँ आपका सर्वर उन सर्वर्स से बात कर सकता है जिन्हें आप स्वयं नहीं चलाते हैं।

Zulip एक Python सर्वर (Django और Tornado) है, जिसके पीछे PostgreSQL, RabbitMQ, memcached और Redis काम करते हैं, जिसे इसकी अपनी स्क्रिप्ट द्वारा एक यूनिट के रूप में इंस्टॉल किया जाता है। इसका मॉडल चैनलों के भीतर टॉपिक्स का है, इसलिए मंगलवार की बातचीत शुक्रवार को भी आसानी से खोजी जा सकती है। संस्करण 12.0 अप्रैल 2026 में जारी किया गया था।

10 और 100 उपयोगकर्ताओं के लिए आवश्यक RAM और डेटाबेस

नीचे दी गई तालिका की प्रत्येक संख्या अगस्त 2026 में पढ़ी गई प्रोजेक्ट के आधिकारिक दस्तावेज़ीकरण से ली गई है। इनमें से कोई भी मेरा मापन नहीं है और न ही कोई काल्पनिक है। प्रत्येक पंक्ति का आधार समान है: प्रोजेक्ट द्वारा प्रकाशित न्यूनतम कॉन्फ़िगरेशन, जिसमें डेटाबेस को तब गिना गया है जब प्रोजेक्ट ने उसे अलग से आकार दिया है।

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

पंक्तियाँ एक समान नहीं हैं, और यह पहला उपयोगी निष्कर्ष है। Synapse की 1 GB, Synapse प्रक्रिया के लिए एक न्यूनतम सीमा है, जिसके साथ एक शर्त जुड़ी है: यदि आप बड़े सार्वजनिक कमरों (public rooms) में शामिल होना चाहते हैं, तो दस्तावेज़ कम से कम उतनी free RAM की मांग करते हैं। PostgreSQL इस आंकड़े से बाहर है। Mattermost की 2 GB पूरी मशीन के लिए है, जिसमें डेटाबेस शामिल है, और यह एक vCPU पर 1 से 1,000 उपयोगकर्ताओं को कवर करती है। Zulip 100 उपयोगकर्ताओं से नीचे 2 GB RAM और एक CPU, साथ ही 2 GB swap की सिफारिश करता है, और 100 उपयोगकर्ताओं या उससे अधिक के लिए 4 GB RAM और दो CPU की आवश्यकता होती है। Rocket.Chat यहाँ सबसे बड़ी संख्या प्रकाशित करता है, 8 GB, क्योंकि यह एप्लिकेशन को 4 GiB और MongoDB को 4 GiB पर आकार देता है, और यह टियर 500 समवर्ती उपयोगकर्ताओं (concurrent users) तक के लिए निर्धारित है।

दस उपयोगकर्ताओं पर, ये सभी 4 एप्लिकेशन ऐसे हार्डवेयर पर चलते हैं जिसके बारे में आपको दोबारा सोचने की आवश्यकता नहीं होगी। सौ उपयोगकर्ताओं पर उत्तर अलग हो जाते हैं: Mattermost अभी भी अपने 2 GB टियर के भीतर है, Zulip को 4 GB और दूसरे CPU की आवश्यकता है, और Rocket.Chat का सबसे छोटा प्रलेखित टियर 8 GB पर अपरिवर्तित है, क्योंकि MongoDB की मेमोरी खपत आपके उपयोगकर्ता संख्या के बजाय मशीन द्वारा निर्धारित होती है।

डेटाबेस का चुनाव आपके दैनिक प्रदर्शन की तुलना में आपके भविष्य के अपग्रेड को अधिक प्रभावित करता है। Mattermost को PostgreSQL 14 या उससे नए संस्करण की आवश्यकता है और इसने v11 से MySQL सपोर्ट को हटा दिया है (deprecated), इसलिए आज का MySQL इंस्टॉलेशन कल एक माइग्रेशन का कारण बनेगा। Synapse SQLite पर चलता है और इसके अपने दस्तावेज़ स्पष्ट रूप से कहते हैं कि SQLite केवल परीक्षण के लिए स्वीकार्य है, क्योंकि यह बड़े कमरों में खराब प्रदर्शन करता है। Rocket.Chat 8 के लिए MongoDB 8.0 की आवश्यकता है, जिसका अर्थ है कि डेटाबेस अपग्रेड और चैट अपग्रेड दो अलग प्रोजेक्ट के बजाय एक ही प्रोजेक्ट हैं।

2 GB VPS आपको वास्तव में क्या देता है

2 GB का प्लान अधिकांश प्रदाताओं (providers) के पास शुरुआती आकार है, और यह इन चार में से दो के लिए एक वास्तविक समाधान है।

• Mattermost फिट बैठता है। यह एकमात्र ऐसा विकल्प है जिसके वेंडर ने उसी बॉक्स पर PostgreSQL के साथ 1,000 उपयोगकर्ताओं तक के लिए इस सटीक आकार का दस्तावेजीकरण किया है। 2 GB पर दस लोग आराम से काम कर सकते हैं।
• Zulip फिट बैठता है, swap के साथ। दस्तावेज़ 5 GB से कम RAM वाली किसी भी मशीन पर swap की अनुशंसा करते हैं और चेतावनी देते हैं कि कम RAM वाली मशीनें अपग्रेड के दौरान out of memory त्रुटियों का सामना करती हैं, जहाँ tools/webpack वह चरण है जो विफल हो जाता है। यह एक वास्तविक विफलता है जिसका सामना आप इंस्टॉलेशन के समय नहीं, बल्कि अपग्रेड के समय करेंगे।
• Synapse तब तक फिट बैठता है जब तक यह शांत है। निष्क्रिय (idle) रहने पर इसकी खपत कम होती है। समस्या स्पाइक (spike) की है, और नीचे फेडरेशन पर दिया गया अनुभाग बताता है कि यह कहाँ से आता है।
• Rocket.Chat वह है जिसे 2 GB पर टालना चाहिए, और इसका कारण MongoDB का स्टोरेज इंजन है। WiredTiger अपने आंतरिक कैश (internal cache) का आकार (RAM माइनस 1 GB) का 50% या 256 MB में से जो भी अधिक हो, उसके अनुसार निर्धारित करता है, इसलिए 2 GB की मशीन पर यह Node.js के शुरू होने से पहले ही लगभग 512 MB आरक्षित कर लेता है। परिणाम स्पष्ट इनकार नहीं होता है। यह इंस्टॉल हो जाता है, चलता है, इतिहास बढ़ने के साथ धीमा हो जाता है, और अंततः kernel का out of memory killer उस प्रक्रिया को रोक देता है जो उस समय सबसे बड़ी होती है।

निर्णय लेने से पहले जांच लें कि आपके पास वास्तव में क्या है, क्योंकि प्रदाता RAM की गणना free से अलग तरह से करते हैं:

free -h
swapon --show

याद रखें कि चैट सर्वर बॉक्स पर एकमात्र चीज नहीं है। TLS (transport layer security) termination, बैकअप और कंटेनर रनटाइम सभी को मेमोरी की आवश्यकता होती है। आप जो भी सर्वर चुनें, उसे एक ऐसे reverse proxy के पीछे रखें जिसे आप समझते हैं, जैसे Nginx, Caddy या Traefik, और यदि आप कंटेनरों के साथ तैनात (deploy) करते हैं, तो VPS के लिए Docker Compose की बुनियादी बातें वह हिस्सा हैं जिसे सबसे पहले सही करना महत्वपूर्ण है।

क्या मोबाइल ऐप्स को आपके स्वयं के पुश सर्वर की आवश्यकता है

यह वह मुख्य बिंदु है जिसे लोग deploy करने के बाद खोजते हैं, और यही वह निर्णय है जो अक्सर अंतिम उत्तर तय करता है।

इसकी कार्यप्रणाली इस प्रकार है। Apple Push Notification service (APNs) और Firebase Cloud Messaging (FCM) केवल उसी से नोटिफिकेशन स्वीकार करते हैं जिसके पास उस विशिष्ट ऐप के लिए signing credentials होते हैं। आपका सर्वर किसी ऐसे ऐप पर पुश नहीं भेज सकता जिसे आपने स्वयं build नहीं किया है। इसलिए, vendor के App Store build का उपयोग करने वाले self-hosted चैट सर्वर को अपने नोटिफिकेशन vendor के gateway को सौंपने होते हैं, और vendor ही शर्तें निर्धारित करता है।

• Mattermost. मुफ्त विकल्प https://push-test.mattermost.com पर स्थित Test Push Notification Service (TPNS) है, जिसके बारे में docs में कहा गया है कि यह production के लिए अनुशंसित नहीं है और इसमें कोई service level agreement (SLA) नहीं है। यह केवल App Store और Play Store builds के साथ काम करता है। Hosted Push Notification Service (HPNS) production-grade है और इसके लिए paid subscription की आवश्यकता होती है। तीसरा रास्ता स्वयं push proxy को compile करना है, जिसके लिए आपको अपने स्वयं के APNs और FCM credentials के साथ अपने स्वयं के ऐप builds की आवश्यकता होगी।
• Rocket.Chat. पुश के लिए workspace को Rocket.Chat Cloud के साथ register करना आवश्यक है, और community workspaces के लिए प्रति माह 10,000 पुश नोटिफिकेशन की सीमा है। यह पूरे workspace के लिए प्रतिदिन लगभग 330 नोटिफिकेशन है। जब कोटा समाप्त हो जाता है, तो महीने के reset होने तक नोटिफिकेशन आने बंद हो जाते हैं, जिसे उपयोगकर्ता ऐप के खराब होने के रूप में देखते हैं।
• Matrix with Element. Synapse एक push gateway को नोटिफिकेशन भेजता है, और आधिकारिक Element ऐप्स https://matrix.org/_matrix/push/v1/notify पर matrix.org द्वारा चलाए जा रहे gateway पर point किए गए होते हैं। payload में संदेश के टेक्स्ट के बजाय event और room identifiers होते हैं, और ऐप आपके सर्वर से content fetch करता है, इसलिए gateway को बातचीत के बजाय केवल metadata दिखाई देता है। अपना स्वयं का Sygnal gateway चलाना समर्थित है और इसका अर्थ है अपने स्वयं के ऐप्स को build और distribute करना। Android पर एक मध्यम मार्ग भी है: UnifiedPush, जिसे आप अपने द्वारा host किए गए ntfy सर्वर के साथ उपयोग कर सकते हैं।
• Zulip. मुफ्त प्लान में 10 उपयोगकर्ताओं तक के लिए मोबाइल पुश सेवा शामिल है। 10 उपयोगकर्ताओं से ऊपर आपको एक प्लान की आवश्यकता होती है, और मुफ्त Community प्लान कई गैर-व्यावसायिक संगठनों को कवर करता है। Zulip 12.0 ने, अप्रैल 2026 में, पुश payloads के लिए end-to-end encryption जोड़ा है।

दस उपयोगकर्ताओं पर इनमें से प्रत्येक आपको बिना किसी लागत के कार्यशील नोटिफिकेशन देता है। सौ उपयोगकर्ताओं पर, स्थिति बदल जाती है: Zulip के लिए एक प्लान की आवश्यकता होती है, Mattermost बिना SLA और बिना support के test service पर काम करना जारी रखता है, Rocket.Chat की मासिक सीमा एक बाधा बन जाती है, और Matrix अप्रभावित रहता है क्योंकि gateway उपयोग करने के लिए मुफ्त है।

कौन से विकल्प मुफ्त में सिंगल साइन-ऑन (SSO) प्रदान करते हैं

सिंगल साइन-ऑन (SSO) वह क्षेत्र है जहाँ ओपन कोर बिजनेस मॉडल सबसे स्पष्ट रूप से दिखाई देता है।

• Zulip अपने self-hosted सर्वर में SAML (security assertion markup language) और LDAP (lightweight directory access protocol) को बिना किसी अतिरिक्त शुल्क के शामिल करता है। इसके लिए कोई अलग से भुगतान वाला टियर नहीं है।
• Synapse अपनी कॉन्फ़िगरेशन फ़ाइल में OpenID Connect (OIDC), SAML और CAS को मुफ्त में सपोर्ट करता है। नए डिप्लॉयमेंट में तेजी से Matrix Authentication Service का उपयोग किया जा रहा है, जो एक अलग सर्विस है और इसमें क्लासिक Synapse ऑथेंटिकेशन से वन-वे माइग्रेशन की सुविधा है, इसलिए इस बदलाव की योजना पहले से बना लें।
• Rocket.Chat कम्युनिटी एडिशन बेसिक LDAP और SAML लॉगिन प्रदान करता है। विस्तारित यूजर एट्रिब्यूट्स को सिंक करने, ग्रुप्स और टीम्स को मैप करने, और बैकग्राउंड सिंक्रोनाइज़ेशन के लिए एंटरप्राइज लाइसेंस की आवश्यकता होती है।
• Mattermost का मुफ्त Team Edition केवल GitLab OAuth प्रदान करता है। SAML, AD/LDAP और OpenID Connect भुगतान वाले फीचर्स हैं।

यदि आप एक ही लॉगिन के पीछे कई सर्विसेज चलाने की योजना बना रहे हैं, तो उनके सामने एक self-hosted Authentik identity provider रखें और जांचें कि आपके पास मौजूद लाइसेंस पर इनमें से कौन सी चार सर्विसेज वास्तव में इसके साथ कम्युनिकेट कर सकती हैं।

Federation की वास्तविक लागत

Federation ही Matrix के अस्तित्व का मुख्य कारण है। आपका user किसी अन्य server पर host किए गए room में शामिल होता है और वहां मौजूद accounts वाले लोगों से बात करता है, ठीक वैसे ही जैसे mail servers आपस में mail का आदान-प्रदान करते हैं। इस सूची में कोई अन्य विकल्प ऐसा नहीं करता है। यदि आपको इसकी आवश्यकता है, तो इस पृष्ठ पर मौजूद कोई भी अन्य विकल्प इसका विकल्प नहीं है।

यही कारण है कि Synapse एक अलग प्रकार का workload है। जब आपका user किसी federated room में शामिल होता है, तो आपका server उस room की state और उसके events की एक copy ले लेता है, और यह उन media files को cache करता है जिन्हें अन्य servers के users post करते हैं: avatars, images और files। आपकी disk का उपयोग उन rooms द्वारा बढ़ता है जिन्हें आपने नहीं बनाया है और उन लोगों द्वारा जो आपके server पर account नहीं रखते हैं। यही कारण है कि Synapse installations का media store उनके अपने users द्वारा भेजे गए messages की मात्रा से कहीं अधिक बड़ा हो जाता है। यही कारण है कि किसी बड़े public room में शामिल होना वह विशिष्ट operation है जिसके लिए docs में memory की शर्त जोड़ी गई है।

Disk भर जाने के दिन के बजाय पहले दिन ही retention policy सेट करें:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse ने version 1.61 में media_retention प्राप्त किया, जिसमें local और remote media के लिए अलग-अलग lifetimes हैं। Remote media एक cache है, इसलिए यदि कोई user किसी हटाए गए file को दोबारा मांगता है, तो Synapse उसे उस server से फिर से request करता है जहाँ से वह आई थी। Local media cache नहीं है, इसलिए एक छोटी local_media_lifetime आपके अपने users द्वारा upload की गई files को स्थायी रूप से हटा देती है।

ईमानदार सारांश: यदि आपके users केवल आपस में ही बात करते हैं, तो federation आपको कुछ नहीं देता है और आपसे disk, bandwidth और एक कठिन upgrade path की कीमत वसूलता है। इसे बंद कर दें, या कोई दूसरा server चुनें।

अपग्रेड कैसे होते हैं

Zulip सबसे आसान है। केवल एक स्क्रिप्ट, और यदि कोई बड़ा डेटाबेस माइग्रेशन न हो, तो डॉक्यूमेंटेड डाउनटाइम 30 सेकंड से कम है। इंस्टॉल और अपग्रेड की प्रक्रिया इस प्रकार है, जिसे आप सर्वर पर चलाएंगे:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

इंस्टॉलर को root के रूप में चलाएं। --push-notifications फ्लैग इंस्टॉलेशन के दौरान सर्वर को मोबाइल पुश सर्विस के साथ रजिस्टर करता है, और यह उस समय आपसे सेवा की शर्तों (terms of service) को स्वीकार करने के लिए कहता है, इसलिए शुरू करने से पहले उन्हें पढ़ लें।

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

बाद के अपग्रेड उसी tarball और एक कमांड के साथ होते हैं:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost अनुमानित है। बाइनरी को बदलें, रीस्टार्ट करें, और माइग्रेशन स्टार्टअप पर चलते हैं। अगस्त 2025 के रिलीज के बाद से, Extended Support Release (ESR) ट्रैक हर 9 महीने में आता है और 12 महीने का सपोर्ट देता है, और ESR से ESR अपग्रेड ही टेस्ट किया गया रास्ता है। एक साथ कई ESR छोड़ना समर्थित तो है लेकिन टेस्ट नहीं किया गया है, जिसका व्यावहारिक अर्थ यह है कि आप ही इसे टेस्ट कर रहे हैं।

Rocket.Chat तीन अपग्रेड को एक साथ जोड़ता है। अगस्त 2026 तक 8.x लाइन वर्तमान है, जिसमें 6 अगस्त 2026 को 8.7.0 रिलीज हुआ था, और इसके लिए MongoDB 8.0 और एक मेल खाने वाला Node.js वर्जन चाहिए। एक मेजर वर्जन छोड़ने के कारण ही लोग ऐसी स्थिति में पहुँच जाते हैं जहाँ एप्लिकेशन डेटाबेस को खोलने से मना कर देता है। Rocket.Chat Docker Compose इंस्टॉल गाइड इन सबको आपके लिए पिन कर देता है, जो यहाँ कंटेनर रूट चुनने का मुख्य तर्क है।

Synapse के लिए पढ़ना जरूरी है। हर रिलीज के साथ अपग्रेड नोट्स होते हैं, और आपको उन सभी वर्जन के नोट्स पढ़ने चाहिए जिनसे आप गुजरते हैं, न कि केवल उस वर्जन के जहाँ आप पहुँचते हैं। अपग्रेड के बाद, Synapse डेटाबेस पर बैकग्राउंड अपडेट चलाता है। छोटे सर्वर पर ये मशीन को घंटों तक धीमा रख सकते हैं, और यह एक खराबी के बजाय अपेक्षित व्यवहार है।

लाइसेंस की शर्तें, सरल शब्दों में

Mattermost अपने compiled Team Edition builds को MIT लाइसेंस के तहत वितरित करता है, जबकि source code को AGPLv3 या व्यावसायिक लाइसेंस के तहत पेश किया जाता है। repository के कुछ हिस्से Mattermost Source Available License के अंतर्गत आते हैं, जिन्हें production में चलाने के लिए भुगतान किए गए लाइसेंस की आवश्यकता होती है। Rocket.Chat, ee/ निर्देशिकाओं को छोड़कर MIT लाइसेंस के अंतर्गत है, जो अपने स्वयं के enterprise लाइसेंस का पालन करती हैं। Synapse संस्करण 1.99.0 के साथ Apache 2.0 से AGPLv3 पर स्थानांतरित हो गया है, और योगदानकर्ता एक CLA पर हस्ताक्षर करते हैं जो Element को उस लाइसेंस के अपवाद बेचने की अनुमति देता है। Zulip, Apache 2.0 लाइसेंस के अंतर्गत है और इसमें कोई enterprise निर्देशिका नहीं है, यही कारण है कि इसकी SSO सुविधा के साथ कोई तारांकन (asterisk) नहीं है।

व्यावहारिक अर्थ: AGPL आपके लिए केवल तभी मायने रखता है यदि आप सर्वर को संशोधित करने और इसे दूसरों को सेवा के रूप में प्रदान करने की योजना बना रहे हैं। एक छोटी टीम के लिए जो बात कहीं अधिक मायने रखती है वह है open core लाइन, जिसका अर्थ है कि मुफ्त build में कौन सी सुविधाएँ गायब हैं। Zulip में सबसे कम सुविधाएँ गायब हैं, और Mattermost में सबसे अधिक।

आपको किसका चयन करना चाहिए

एक आंतरिक टीम टूल। Mattermost। इसका documented footprint सबसे छोटा है, इसके upgrades सबसे सरल हैं, और इसका interface इतना परिचित है कि इसे समझाने की आवश्यकता नहीं होती। जिस दिन SSO की आवश्यकता हो, उस दिन के लिए एक paid plan की योजना बनाकर रखें, क्योंकि अधिकांश टीमों के लिए वह दिन आ ही जाता है।

एक कम्युनिटी सर्वर। Zulip। इसके topics एक व्यस्त public channel को महीनों बाद भी पढ़ने योग्य बनाए रखते हैं, SAML और LDAP के लिए कोई शुल्क नहीं लगता, और upgrade केवल एक command का काम है। यदि आपकी कम्युनिटी live chat की तुलना में posts और replies के अधिक करीब है, तो पहले self-hosted forum software की तुलना करें, क्योंकि एक forum search में बेहतर index होता है और उसे किसी push infrastructure की आवश्यकता नहीं होती। जब आपको voice, video और omnichannel features चाहिए हों और आप इसे 8 GB RAM दे सकें, जैसा कि इसके documentation में मांगा गया है, तब Rocket.Chat चुनें।

एक नेटवर्क जिसे interoperate करना आवश्यक है। Synapse और Element के साथ Matrix। media growth को स्वीकार करें, पहले दिन ही retention set करें, इसे PostgreSQL दें और अपनी सोच से अधिक disk space प्रदान करें, और उन servers से बात करने का वास्तविक लाभ उठाएं जिन्हें आप नियंत्रित नहीं करते। ऐसी टीम के लिए Synapse चुनना जो कभी federate नहीं करती, बिना किसी कारण के उस लागत को चुकाना है।

FAQ

छोटी टीम के लिए सबसे अच्छा self-hosted Slack विकल्प कौन सा है?

ज्यादातर आंतरिक टीमों के लिए Mattermost सबसे बेहतर है। इसका documentation 1 vCPU और 2 GB RAM वाले सर्वर पर 1 से 1,000 users तक को सपोर्ट करने की पुष्टि करता है, जिसमें PostgreSQL भी उसी मशीन पर चल सकता है। इसलिए यह अधिकांश providers द्वारा बेचे जाने वाले entry-level VPS प्लान के लिए उपयुक्त है। इसकी सीमा single sign-on (SSO) है: इसका मुफ्त Team Edition केवल GitLab OAuth को सपोर्ट करता है, जबकि SAML, AD/LDAP और OpenID Connect के लिए paid प्लान की आवश्यकता होती है। यदि Slack जैसा इंटरफ़ेस होने से ज्यादा महत्वपूर्ण मुफ्त SSO है, तो Zulip का उपयोग करें।

क्या मैं 2 GB VPS पर self-hosted chat server चला सकता हूँ?

Mattermost को हाँ, और Zulip को भी हाँ, बशर्ते आप swap memory का उपयोग करें (जिसकी सलाह Zulip का अपना documentation 5 GB से कम RAM होने पर देता है)। Rocket.Chat आपको निराश कर सकता है, क्योंकि इसका MongoDB का WiredTiger engine अपने cache के लिए (RAM minus 1 GB) का 50% या 256 MB में से जो भी अधिक हो, उसे आरक्षित कर लेता है। इस प्रकार, एप्लिकेशन शुरू होने से पहले ही 2 GB में से लगभग 512 MB RAM खर्च हो जाती है। यह इंस्टॉल तो हो जाएगा, लेकिन जैसे-जैसे chat history बढ़ेगी, प्रदर्शन गिरता जाएगा और अंत में यह out of memory error के कारण बंद हो जाएगा। Rocket.Chat का न्यूनतम अनुशंसित स्तर 4 GiB ऐप के लिए और 4 GiB MongoDB के लिए है।

क्या self-hosted chat servers को अपने स्वयं के mobile push notification server की आवश्यकता होती है?

आमतौर पर नहीं, क्योंकि Apple का APNs और Google का FCM केवल उसी से नोटिफिकेशन स्वीकार करते हैं जिसने ऐप को sign किया है, इसलिए vendor का ऐप vendor के ही gateway का उपयोग करता है। इनकी शर्तें अलग-अलग हैं। Mattermost बिना किसी SLA के एक मुफ्त test service और एक paid hosted service प्रदान करता है। Rocket.Chat कम्युनिटी वर्कस्पेस के लिए प्रति माह 10,000 push notifications की सीमा तय करता है, जिसके बाद महीने के reset होने तक नोटिफिकेशन डिलीवरी रुक जाती है। Zulip 10 users तक मुफ्त push सुविधा देता है और उससे अधिक के लिए प्लान की आवश्यकता होती है। Matrix homeservers बिना किसी अतिरिक्त लागत के Element ऐप्स द्वारा उपयोग किए जाने वाले gateway के माध्यम से push भेजते हैं। आपको अपने स्वयं के gateway की आवश्यकता केवल तभी होती है जब आप अपना स्वयं का ऐप build distribute करते हैं।

क्या मुझे ऐसी टीम के लिए Matrix और Synapse को self-host करना चाहिए जो कभी अन्य सर्वरों से बात नहीं करती?

नहीं। Federation ही Synapse का मुख्य उद्देश्य है, और यही इसे चलाने में भारी (resource-heavy) बनाता है। अन्य सर्वरों पर rooms में शामिल होने से उनका state और media आपके disk पर cache हो जाता है, जिससे आपके अपने users के बिना भी storage बढ़ती रहती है। ऐसा होने से पहले media_retention को कम remote_media_lifetime के साथ सेट करें। जो टीम केवल आपस में बात करती है, उसे इसके operational खर्च तो उठाने पड़ेंगे लेकिन इसका कोई लाभ नहीं मिलेगा। Mattermost या Zulip कम hardware पर वही काम बेहतर तरीके से कर सकते हैं।

किस self-hosted Slack विकल्प में मुफ्त single sign-on उपलब्ध है?

Zulip और Synapse। Zulip के self-hosted सर्वर में SAML और LDAP बिना किसी अतिरिक्त लागत के शामिल हैं। Synapse अपने configuration में OpenID Connect, SAML और CAS को सपोर्ट करता है, और नए इंस्टॉलेशन अब अलग Matrix Authentication Service की ओर बढ़ रहे हैं। Rocket.Chat का community edition बुनियादी LDAP और SAML लॉगिन तो देता है, लेकिन attribute sync, group mapping और background sync को enterprise licence के पीछे रखा गया है। Mattermost का मुफ्त Team Edition केवल GitLab OAuth को सपोर्ट करता है।