بهترین جایگزین‌های Slack برای میزبانی شخصی (Self-hosted)

کدام جایگزین Slack برای میزبانی شخصی (self-hosted) مناسب است

جایگزین‌های Slack برای میزبانی شخصی که ارزش صرف وقت برای تیم‌های کوچک را دارند، عبارتند از Mattermost، Rocket.Chat، Matrix با Synapse و Zulip. برای ابزار ارتباطی داخلی تیم روی یک سرور، از Mattermost استفاده کنید. برای یک جامعه کاربری عمومی، Zulip را اجرا کنید. زمانی که نیاز دارید با سرورهایی که متعلق به دیگران هستند ارتباط برقرار کنید، Matrix با Synapse را اجرا کنید؛ فقط در این صورت، زیرا فدراسیون (federation) تنها قابلیتی است که دیگران نمی‌توانند کپی کنند و در عین حال، همان چیزی است که وظایف شما را به عنوان مدیر سیستم تغییر می‌دهد.

لیست ویژگی‌ها این چهار مورد را از هم متمایز نمی‌کند. همه آن‌ها از کانال‌ها، رشته‌های گفتگو (threads)، جستجو، آپلود فایل و اپلیکیشن‌های موبایل پشتیبانی می‌کنند. آنچه آن‌ها را متمایز می‌کند، انتظاراتی است که هر ماه از شما دارند: حافظه، پایگاه داده‌ای که باید آن را زنده نگه دارید، مسیر ارسال اعلان‌های موبایل (push) که ممکن است کنترل مستقیمی روی آن نداشته باشید، و مجوزی (licence) که تعیین می‌کند آیا ویژگی مورد نیاز شما در نسخه پولی قرار دارد یا خیر. مقایسه زیر بر اساس این محورها، برای 10 کاربر و 100 کاربر انجام شده است.

ماهیت واقعی هر یک از این چهار مورد

Mattermost یک سرور مبتنی بر Go با پایگاه داده PostgreSQL است. شامل یک فایل اجرایی (binary)، یک پایگاه داده و یک فایل پیکربندی. این سرویس مشابه Slack عمل می‌کند و شامل قابلیت‌هایی نظیر رشته‌های گفتگو (threads) و دستورات slash است. از نظر عملیاتی، این سرویس کم‌دردسرترین گزینه در میان این چهار مورد است که خود یک مزیت محسوب می‌شود.

Rocket.Chat یک برنامه Node.js است که روی MongoDB اجرا می‌شود. این سرویس گسترده‌ترین مجموعه قابلیت‌ها را در اینجا ارائه می‌دهد، از جمله تماس‌های صوتی و تصویری و یک صندوق ورودی همه‌کاناله (omnichannel) که مکالمات مشتریان از ایمیل و شبکه‌های اجتماعی را در یک رابط کاربری واحد جمع‌آوری می‌کند. اگر دلیل انتخاب شما این صندوق ورودی است، پیش از هر چیز آن را با یک میز پشتیبانی اختصاصی Chatwoot مقایسه کنید؛ زیرا وظیفهٔ یک سرور چت برای پشتیبانی، با وظیفهٔ یک سرور چت برای همکاری تیمی متفاوت است.

Matrix یک پروتکل است، نه یک محصول. Synapse سرور مرجع آن (مبتنی بر Python و PostgreSQL) و Element کلاینتی است که اکثر کاربران از آن استفاده می‌کنند. این تنها گزینه‌ای است که در آن سرور شما می‌تواند با سرورهایی که شما مدیریت نمی‌کنید، ارتباط برقرار کند.

Zulip یک سرور پایتونی (Django به همراه Tornado) است که از PostgreSQL، RabbitMQ، memcached و Redis در پس‌زمینه استفاده می‌کند و توسط اسکریپت اختصاصی خود به عنوان یک واحد یکپارچه نصب می‌شود. مدل کاری آن بر اساس موضوعات (topics) درون کانال‌ها است، بنابراین مکالمه‌ای که در روز سه‌شنبه انجام شده، در روز جمعه نیز به‌راحتی قابل‌جستجو است. نسخه 12.0 این سرویس در آوریل 2026 منتشر شد.

میزان رم مورد نیاز و پایگاه داده برای 10 کاربر و 100 کاربر

تمام اعداد موجود در جدول زیر از مستندات رسمی پروژه استخراج شده‌اند که در اوت 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."
  }
]

ساختار ردیف‌ها یکسان نیست و این اولین یافتهٔ کاربردی است. مقدار 1 گیگابایت برای Synapse، حداقل رم مورد نیاز برای پردازش Synapse است، با این شرط که مستندات تأکید دارند اگر قصد پیوستن به اتاق‌های عمومی بزرگ را دارید، باید حداقل همین مقدار رم آزاد داشته باشید. PostgreSQL در این عدد لحاظ نشده است. مقدار 2 گیگابایت برای Mattermost، کل سخت‌افزار مورد نیاز شامل پایگاه داده است و از 1 تا 1000 کاربر را روی یک vCPU پوشش می‌دهد. Zulip برای کمتر از 100 کاربر، 2 گیگابایت رم و یک CPU به همراه 2 گیگابایت swap پیشنهاد می‌دهد؛ برای 100 کاربر و بیشتر، این مقدار به 4 گیگابایت رم و دو CPU افزایش می‌یابد. Rocket.Chat بیشترین مقدار را در اینجا دارد، یعنی 8 گیگابایت، زیرا برنامه را 4 گیگابایت و MongoDB را نیز 4 گیگابایت در نظر می‌گیرد و این سطح برای حداکثر 500 کاربر همزمان رتبه‌بندی شده است.

در سطح 10 کاربر، تمام 4 سرویس روی سخت‌افزاری اجرا می‌شوند که نیازی به تأمل چندان ندارد. در سطح 100 کاربر، پاسخ‌ها متفاوت می‌شوند: Mattermost همچنان در سطح 2 گیگابایتی خود باقی می‌ماند، Zulip به 4 گیگابایت رم و CPU دوم نیاز دارد، و کوچک‌ترین سطح مستندشده برای Rocket.Chat بدون تغییر در 8 گیگابایت باقی می‌ماند، زیرا اشتهای حافظهٔ MongoDB بیشتر توسط سخت‌افزار تعیین می‌شود تا تعداد کاربران شما.

انتخاب پایگاه داده بیش از عملکرد روزانه، تعیین‌کنندهٔ ارتقاهای آیندهٔ شماست. Mattermost به PostgreSQL 14 یا جدیدتر نیاز دارد و پشتیبانی از MySQL را از نسخه v11 به بعد منسوخ کرده است؛ بنابراین نصب MySQL در حال حاضر، به معنای مهاجرت در آینده خواهد بود. Synapse روی SQLite اجرا می‌شود و مستندات آن به‌صراحت بیان می‌کنند که SQLite فقط برای تست مناسب است، زیرا در اتاق‌های بزرگ عملکرد ضعیفی دارد. Rocket.Chat 8 به MongoDB 8.0 نیاز دارد، به این معنی که ارتقای پایگاه داده و ارتقای سرویس چت، یک پروژه واحد محسوب می‌شوند نه دو پروژه مجزا.

یک VPS با 2 GB رم واقعاً چه چیزی به شما می‌دهد

پلن 2 GB در اکثر سرویس‌دهنده‌ها، حداقل اندازه ممکن است و برای دو مورد از این چهار گزینه، پاسخی واقعی محسوب می‌شود.

• Mattermost مناسب است. این تنها گزینه‌ای است که سازنده آن دقیقاً همین اندازه را برای حداکثر 1,000 کاربر، همراه با PostgreSQL روی همان سرور مستند کرده است. ده نفر کاربر روی 2 GB رم، تجربه راحتی خواهند داشت.
• Zulip با استفاده از swap مناسب است. مستندات این سرویس توصیه می‌کنند برای هر سیستمی با رم کمتر از 5 GB از swap استفاده کنید و هشدار می‌دهند که ماشین‌های دارای رم کم، هنگام ارتقا با خطاهای out of memory مواجه می‌شوند؛ جایی که tools/webpack مرحله‌ای است که با شکست مواجه می‌شود. این یک خطای واقعی است که در زمان ارتقا با آن روبرو می‌شوید، نه در زمان نصب.
• Synapse در زمان خلوتی مناسب است. هزینه رم در حالت idle کم است. مشکل اصلی جهش‌های مصرف رم است و بخشی که در ادامه درباره federation آمده، توضیح می‌دهد که این جهش‌ها از کجا ناشی می‌شوند.
• Rocket.Chat گزینه‌ای است که باید در 2 GB از آن اجتناب کرد، و دلیل آن موتور ذخیره‌سازی MongoDB است. WiredTiger اندازه کش داخلی خود را بر اساس بزرگترین مقدار بین 50 درصد از (رم منهای 1 GB) یا 256 MB تنظیم می‌کند؛ بنابراین روی یک ماشین 2 GB، حدود 512 MB را پیش از آنکه Node.js حتی شروع به کار کند، رزرو می‌کند. نتیجه این وضعیت، یک امتناع ساده نیست. سرویس نصب می‌شود، اجرا می‌شود، با افزایش تاریخچه کند می‌شود و در نهایت، kernel out of memory killer هر فرآیندی را که در آن لحظه بزرگترین باشد، متوقف می‌کند.

پیش از تصمیم‌گیری بررسی کنید که واقعاً چه مقدار رم در اختیار دارید، زیرا سرویس‌دهنده‌ها رم را متفاوت از free محاسبه می‌کنند:

free -h
swapon --show

به یاد داشته باشید که سرور چت تنها چیزی نیست که روی سرور شما اجرا می‌شود. TLS (transport layer security) termination، پشتیبان‌گیری‌ها و یک container runtime همگی به حافظه نیاز دارند. هر سروری را که انتخاب می‌کنید، پشت یک reverse proxy که به آن مسلط هستید، مانند Nginx، Caddy یا Traefik قرار دهید و اگر با کانتینرها مستقر می‌کنید، اصول Docker Compose برای یک VPS بخشی است که ارزش دارد از همان ابتدا به درستی پیاده‌سازی شود.

آیا اپلیکیشن‌های موبایل به سرور push اختصاصی شما نیاز دارند؟

این همان موضوعی است که کاربران پس از استقرار سرویس متوجه آن می‌شوند و اغلب تعیین‌کننده پاسخ نهایی است.

مکانیسم کار به این صورت است: سرویس Apple Push Notification (APNs) و Firebase Cloud Messaging (FCM) تنها در صورتی اعلان را می‌پذیرند که از طرف دارندهٔ اعتبارنامه‌های امضای همان اپلیکیشن خاص ارسال شده باشد. سرور شما نمی‌تواند به اپلیکیشنی که خودتان آن را بیلد نکرده‌اید، اعلان ارسال کند. بنابراین، یک سرور چت self-hosted که از نسخهٔ موجود در App Store استفاده می‌کند، باید اعلان‌های خود را به درگاه (gateway) همان فروشنده تحویل دهد و فروشنده نیز شرایط استفاده را تعیین می‌کند.

• Mattermost. مسیر رایگان، استفاده از Test Push Notification Service (TPNS) در https://push-test.mattermost.com است که طبق مستندات، برای محیط عملیاتی (production) توصیه نمی‌شود و هیچ توافق‌نامه سطح خدماتی (SLA) ندارد. این سرویس فقط با نسخه‌های App Store و Play Store کار می‌کند. سرویس Hosted Push Notification Service (HPNS) برای محیط عملیاتی مناسب است و نیاز به اشتراک پولی دارد. مسیر سوم، کامپایل کردن push proxy توسط خودتان است که در این صورت نیاز به بیلد کردن اپلیکیشن‌های اختصاصی با اعتبارنامه‌های APNs و FCM خودتان خواهید داشت.
• Rocket.Chat. سرویس push مستلزم ثبت فضای کاری (workspace) در Rocket.Chat Cloud است و فضاهای کاری جامعه کاربری (community) به 10000 اعلان push در ماه محدود شده‌اند. این تعداد برای کل فضای کاری حدود 330 اعلان در روز است. وقتی سهمیه تمام شود، اعلان‌ها تا شروع ماه بعد متوقف می‌شوند که از دید کاربران به معنای خرابی اپلیکیشن است.
• Matrix با Element. سرور Synapse اعلان‌ها را به یک push gateway می‌فرستد و اپلیکیشن‌های رسمی Element به درگاهی که matrix.org در https://matrix.org/_matrix/push/v1/notify اجرا می‌کند، متصل هستند. محموله (payload) ارسالی شامل شناسه‌های رویداد و اتاق است و نه متن پیام؛ اپلیکیشن محتوا را از سرور شما دریافت می‌کند، بنابراین درگاه فقط متادیتای پیام را می‌بیند و نه محتوای گفتگوها را. اجرای درگاه Sygnal اختصاصی پشتیبانی می‌شود، اما به معنای بیلد کردن و توزیع اپلیکیشن‌های شخصی خودتان است. در اندروید یک راه میانه وجود دارد: استفاده از UnifiedPush به همراه یک سرور ntfy که خودتان میزبانی می‌کنید.
• Zulip. طرح رایگان شامل سرویس push موبایل برای حداکثر 10 کاربر است. برای بیش از 10 کاربر نیاز به تهیه طرح دارید، اگرچه طرح رایگان Community بسیاری از سازمان‌های غیرتجاری را پوشش می‌دهد. Zulip 12.0 در آوریل 2026، رمزنگاری سرتاسری (E2EE) را برای محموله‌های push اضافه کرد.

در مقیاس 10 کاربر، همه این سرویس‌ها اعلان‌های فعال را بدون هزینه در اختیار شما قرار می‌دهند. در مقیاس 100 کاربر، وضعیت تغییر می‌کند: Zulip نیاز به طرح پولی دارد، Mattermost با سرویس آزمایشی و بدون SLA و پشتیبانی به کار خود ادامه می‌دهد، محدودیت ماهانه Rocket.Chat به یک مانع جدی تبدیل می‌شود و Matrix تحت تأثیر قرار نمی‌گیرد زیرا استفاده از درگاه آن رایگان است.

کدام‌یک قابلیت Single sign-on را به‌صورت رایگان ارائه می‌دهند

مدل کسب‌وکار open core در حوزه Single sign-on (SSO) بیش از هر جای دیگری خود را نشان می‌دهد.

• Zulip: پروتکل‌های SAML (security assertion markup language) و LDAP (lightweight directory access protocol) را بدون هزینه در نسخه self-hosted ارائه می‌دهد. هیچ سطح کاربری جداگانه‌ای برای خرید وجود ندارد.
• Synapse: از OpenID Connect (OIDC)، SAML و CAS به‌صورت رایگان در فایل پیکربندی خود پشتیبانی می‌کند. در پیاده‌سازی‌های جدیدتر، استفاده از Matrix Authentication Service رواج یافته است؛ این یک سرویس مجزا با قابلیت مهاجرت یک‌طرفه از احراز هویت کلاسیک Synapse است، بنابراین پیش از مواجهه با آن، برای این تغییر برنامه‌ریزی کنید.
• Rocket.Chat: نسخه community از ورود پایه LDAP و SAML پشتیبانی می‌کند. همگام‌سازی ویژگی‌های پیشرفته کاربر، نگاشت گروه‌ها و تیم‌ها، و همگام‌سازی در پس‌زمینه نیازمند لایسنس enterprise است.
• Mattermost: نسخه رایگان Team Edition فقط از GitLab OAuth پشتیبانی می‌کند. قابلیت‌های SAML، AD/LDAP و OpenID Connect جزو ویژگی‌های پولی هستند.

اگر قصد دارید چندین سرویس را پشت یک سیستم ورود واحد اجرا کنید، یک سرویس‌دهنده هویت Authentik به صورت self-hosted را در مقابل آن‌ها قرار دهید و بررسی کنید که کدام‌یک از این چهار سرویس با لایسنسی که در اختیار دارید، قابلیت اتصال به آن را دارند.

هزینه واقعی فدراسیون برای شما

فدراسیون دلیل اصلی وجود Matrix است. کاربر شما به اتاقی که روی سرور شخص دیگری میزبانی می‌شود ملحق شده و با افرادی که حساب‌هایشان در آنجا قرار دارد صحبت می‌کند، درست مانند نحوه تبادل ایمیل توسط سرورهای ایمیل. هیچ گزینه دیگری در اینجا این کار را انجام نمی‌دهد. اگر به این قابلیت نیاز دارید، هیچ چیز دیگری در این صفحه جایگزین آن نخواهد بود.

این موضوع همچنین دلیلی است که Synapse نوع متفاوتی از بار کاری محسوب می‌شود. هنگامی که کاربر شما به یک اتاق فدراسیون‌شده ملحق می‌شود، سرور شما نسخه‌ای از وضعیت آن اتاق و رویدادهایش را دریافت می‌کند و رسانه‌هایی که کاربران در سرورهای دیگر ارسال می‌کنند، مانند آواتارها، تصاویر و فایل‌ها را کش می‌کند. بنابراین، میزان استفاده از دیسک شما توسط اتاق‌هایی که خودتان ایجاد نکرده‌اید و افرادی که در سرور شما حساب کاربری ندارند، تعیین می‌شود. به همین دلیل است که نصب‌های Synapse، فضای ذخیره‌سازی رسانه‌ای بسیار بزرگ‌تر از حجم پیام‌های ارسالی توسط کاربران خودشان ایجاد می‌کنند. همچنین به همین دلیل است که ملحق شدن به یک اتاق عمومی بزرگ، عملیاتی است که مستندات برای آن شرط حافظه خاصی را تعیین کرده‌اند.

سیاست نگهداری (retention policy) را از همان روز اول تنظیم کنید، نه روزی که دیسک پر می‌شود:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse در نسخه 1.61 قابلیت media_retention را به دست آورد که دارای طول عمرهای جداگانه برای رسانه‌های محلی و راه دور است. رسانه راه دور یک کش است، بنابراین اگر کاربری دوباره درخواست فایلی را بدهد که پاک شده است، Synapse آن را مجدداً از سروری که از آن آمده درخواست می‌کند. رسانه محلی کش نیست، بنابراین یک local_media_lifetime کوتاه، فایل‌های آپلود شده توسط کاربران خودتان را برای همیشه حذف می‌کند.

خلاصه صادقانه: اگر کاربران شما فقط با یکدیگر صحبت می‌کنند، فدراسیون هیچ مزیتی برای شما ندارد و فقط هزینه دیسک، پهنای باند و مسیر ارتقای سنگین‌تری را به شما تحمیل می‌کند. آن را خاموش کنید یا سرور دیگری انتخاب کنید.

ارتقاها چگونه انجام می‌شوند

Zulip ساده‌ترین است. تنها یک اسکریپت نیاز است و زمان توقف مستندشده آن کمتر از 30 ثانیه است، مگر اینکه یک migration بزرگ دیتابیس در میان باشد. نصب و ارتقا به این صورت است که توسط شما روی سرور اجرا می‌شود:

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 سرور را در حین نصب با سرویس push موبایل ثبت می‌کند و از شما می‌خواهد که شرایط خدمات را در همان لحظه بپذیرید، بنابراین پیش از شروع آن‌ها را مطالعه کنید.

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 قابل پیش‌بینی است. فایل باینری را جایگزین کنید، سرویس را restart کنید و migrationها در زمان startup اجرا می‌شوند. از زمان انتشار نسخه‌های آگوست 2025، مسیر Extended Support Release (ESR) هر 9 ماه یک‌بار با 12 ماه پشتیبانی عرضه می‌شود و ارتقا از ESR به ESR مسیر تست‌شده است. پرش از چندین نسخه ESR به‌طور هم‌زمان پشتیبانی می‌شود اما تست نشده است، که در عمل به این معناست که خود شما مسئول تست آن هستید.

Rocket.Chat سه ارتقا را با هم ترکیب می‌کند. از آگوست 2026، سری 8.x نسخه جاری است و نسخه 8.7.0 در 6 آگوست 2026 منتشر شده است؛ این نسخه به MongoDB 8.0 و نسخه Node.js منطبق نیاز دارد. پرش از یک نسخه اصلی (major version) دلیلی است که باعث می‌شود کاربران با دیتابیسی مواجه شوند که برنامه از باز کردن آن خودداری می‌کند. راهنمای نصب Rocket.Chat با Docker Compose این موارد را برای شما ثابت (pin) می‌کند، که دلیل اصلی انتخاب روش container در اینجا است.

Synapse نیاز به مطالعه دارد. هر نسخه دارای یادداشت‌های ارتقا است و شما باید یادداشت‌های مربوط به هر نسخه‌ای که از آن عبور می‌کنید را بخوانید، نه فقط نسخه‌ای که به آن می‌رسید. پس از ارتقا، Synapse به‌روزرسانی‌های پس‌زمینه را روی دیتابیس اجرا می‌کند. در یک سرور کوچک، این فرآیند می‌تواند دستگاه را برای ساعت‌ها کند نگه دارد و این رفتار مورد انتظار است، نه یک خطا.

شرایط مجوز به زبان ساده

نرم‌افزار Mattermost نسخه‌های کامپایل‌شده Team Edition خود را تحت مجوز MIT توزیع می‌کند، در حالی که سورس‌کد آن تحت مجوز AGPLv3 یا یک مجوز تجاری ارائه می‌شود. بخش‌هایی از مخزن این نرم‌افزار تحت مجوز Mattermost Source Available License قرار دارند که برای اجرا در محیط عملیاتی (production) نیازمند خرید مجوز است. نرم‌افزار Rocket.Chat به جز دایرکتوری‌های ee/ که دارای مجوز سازمانی (enterprise) اختصاصی خود هستند، تحت مجوز MIT منتشر می‌شود. Synapse از نسخه 1.99.0 مجوز خود را از Apache 2.0 به AGPLv3 تغییر داد و مشارکت‌کنندگان توافق‌نامه‌ای (CLA) را امضا می‌کنند که به Element اجازه می‌دهد استثنائاتی برای آن مجوز بفروشد. Zulip تحت مجوز Apache 2.0 است و دایرکتوری سازمانی ندارد؛ به همین دلیل است که قابلیت SSO در آن هیچ شرط یا ستاره‌ای ندارد.

برداشت کاربردی: مجوز AGPL تنها در صورتی برای شما اهمیت دارد که قصد داشته باشید سرور را تغییر دهید و آن را به عنوان یک سرویس به دیگران ارائه کنید. آنچه برای یک تیم کوچک اهمیت بسیار بیشتری دارد، مدل open core است؛ یعنی اینکه چه قابلیت‌هایی در نسخه رایگان وجود ندارند. Zulip کمترین محدودیت و Mattermost بیشترین محدودیت را در این زمینه دارند.

کدام را انتخاب کنید

یک ابزار تیمی داخلی. Mattermost. این ابزار کمترین ردپای مستندشده را دارد، به‌روزرسانی‌های آن بسیار بی‌دردسر است و رابط کاربری آشنایی دارد که نیازی به آموزش ندارد. برای روزی که SSO به یک الزام تبدیل می‌شود، بودجه‌ای برای طرح‌های پولی در نظر بگیرید، زیرا این نیاز برای اکثر تیم‌ها دیر یا زود پیش می‌آید.

یک سرور اجتماعی. Zulip. قابلیت Topics باعث می‌شود یک کانال عمومی شلوغ حتی ماه‌ها بعد هم خوانا باقی بماند، SAML و LDAP در آن رایگان هستند و به‌روزرسانی تنها با یک دستور انجام می‌شود. اگر جامعهٔ شما بیشتر به پست و پاسخ شباهت دارد تا چت زنده، ابتدا نرم‌افزارهای انجمن‌ساز self-hosted را بررسی کنید، زیرا انجمن‌ها در موتورهای جستجو بهتر ایندکس می‌شوند و اصلاً نیازی به زیرساخت push ندارند. اگر به قابلیت‌های صوتی، تصویری و omnichannel نیاز دارید و می‌توانید 8 GB رم مورد نیاز مستندات آن را تأمین کنید، Rocket.Chat را انتخاب کنید.

شبکه‌ای که باید تعامل‌پذیر باشد. Matrix به همراه Synapse و Element. رشد حجم رسانه‌ها را بپذیرید، از همان روز اول سیاست نگهداری (retention) را تنظیم کنید، آن را به PostgreSQL متصل کنید، فضای دیسک بیشتری از آنچه فکر می‌کنید در نظر بگیرید و از مزایای واقعی گفتگو با سرورهایی که تحت کنترل شما نیستند بهره‌مند شوید. انتخاب Synapse برای تیمی که هرگز از قابلیت federation استفاده نمی‌کند، صرف هزینه برای هیچ است.

FAQ

بهترین جایگزین Slack برای تیم‌های کوچک که می‌توان آن را روی سرور شخصی میزبانی کرد چیست؟

برای اکثر تیم‌های داخلی، Mattermost بهترین گزینه است. مستندات این سرویس نشان می‌دهد که برای 1 تا 1,000 کاربر، تنها به یک vCPU و 2 GB رم (به همراه PostgreSQL روی همان ماشین) نیاز دارد؛ بنابراین با پلن‌های پایه VPS که اکثر ارائه‌دهندگان می‌فروشند، سازگار است. نکته مهم در مورد Single Sign-On (SSO) این است که نسخه رایگان Team Edition فقط از GitLab OAuth پشتیبانی می‌کند و برای استفاده از SAML، AD/LDAP و OpenID Connect باید هزینه پرداخت کنید. اگر قابلیت SSO رایگان برای شما اولویت بیشتری نسبت به رابط کاربری شبیه به Slack دارد، از Zulip استفاده کنید.

آیا می‌توانم یک سرور چت شخصی را روی یک VPS با 2 GB رم اجرا کنم؟

برای Mattermost بله، و برای Zulip نیز در صورتی که swap اضافه کنید (که مستندات خود Zulip برای رم کمتر از 5 GB توصیه کرده است)، امکان‌پذیر است. Rocket.Chat گزینه‌ای است که شما را ناامید خواهد کرد؛ زیرا موتور WiredTiger در MongoDB، مقدار بزرگ‌تر بین «50 درصد از (رم منهای 1 GB)» یا 256 MB را برای کش خود رزرو می‌کند. این یعنی حدود 512 MB از رم 2 GB شما قبل از شروع برنامه اشغال می‌شود. این سرویس نصب می‌شود، اما با افزایش تاریخچه پیام‌ها، کارایی آن کاهش یافته و در نهایت با خطای Out of Memory متوقف می‌شود. حداقل سخت‌افزار پیشنهادی Rocket.Chat برای برنامه 4 GiB و برای MongoDB نیز 4 GiB است.

آیا سرورهای چت شخصی به سرور اختصاصی برای Push Notification موبایل نیاز دارند؟

معمولاً خیر؛ زیرا APNs اپل و FCM گوگل فقط اعلان‌هایی را می‌پذیرند که توسط امضاکننده برنامه ارسال شده باشد، بنابراین برنامه ارائه‌دهنده از درگاه (gateway) همان ارائه‌دهنده استفاده می‌کند. شرایط در سرویس‌های مختلف متفاوت است. Mattermost یک سرویس تست رایگان بدون SLA و یک سرویس میزبانی‌شده پولی ارائه می‌دهد. Rocket.Chat سقف 10,000 اعلان در ماه را برای ورک‌اسپیس‌های انجمن (community) در نظر گرفته است و پس از آن، ارسال اعلان تا شروع ماه بعد متوقف می‌شود. Zulip برای حداکثر 10 کاربر، اعلان رایگان ارائه می‌دهد و برای تعداد بیشتر نیاز به خرید پلن دارد. هوم‌سرورهای Matrix از طریق درگاهی که توسط برنامه‌های Element استفاده می‌شود، اعلان‌ها را بدون هزینه ارسال می‌کنند. شما تنها در صورتی به درگاه اختصاصی نیاز دارید که بیلد اختصاصی خودتان از برنامه را منتشر کنید.

آیا برای تیمی که هرگز با سرورهای دیگر ارتباط برقرار نمی‌کند، باید Matrix و Synapse را روی سرور شخصی میزبانی کنم؟

خیر. فدراسیون (Federation) هدف اصلی Synapse است و همین ویژگی باعث سنگین‌تر شدن اجرای آن می‌شود. عضویت در اتاق‌های سرورهای دیگر باعث می‌شود وضعیت (state) آن‌ها دریافت و رسانه‌هایشان روی دیسک شما کش شود؛ بنابراین فضای ذخیره‌سازی شما به دلایلی که به کاربران خودتان مربوط نیست، اشغال می‌شود. قبل از وقوع این اتفاق، media_retention را با یک remote_media_lifetime کوتاه تنظیم کنید. تیمی که فقط با اعضای خود در ارتباط است، هزینه‌های عملیاتی سنگین را متحمل می‌شود بدون اینکه از مزایای آن بهره‌مند شود؛ در حالی که Mattermost یا Zulip همان کار را با سخت‌افزار کمتری انجام می‌دهند.

کدام جایگزین Slack برای میزبانی شخصی، قابلیت Single Sign-On رایگان دارد؟

Zulip و Synapse. Zulip قابلیت‌های SAML و LDAP را بدون هزینه اضافی در سرور میزبانی‌شده شخصی ارائه می‌دهد. Synapse نیز در تنظیمات خود از OpenID Connect، SAML و CAS پشتیبانی می‌کند و در نصب‌های جدیدتر به سمت استفاده از Matrix Authentication Service مجزا حرکت کرده است. نسخه Community از Rocket.Chat از ورود پایه LDAP و SAML پشتیبانی می‌کند، اما همگام‌سازی ویژگی‌ها (attribute sync)، نگاشت گروه‌ها و همگام‌سازی پس‌زمینه را پشت لایسنس Enterprise قرار داده است. نسخه رایگان Team Edition از Mattermost فقط از GitLab OAuth پشتیبانی می‌کند.