SSD Nodes Learn 🎉 VPS $5.50/月起
指南 Matt Connor作者： Matt Connor

自架 Slack 替代方案比較：Mattermost、Rocket.Chat 等

比較 Mattermost、Rocket.Chat、Synapse 與 Zulip 的 RAM、資料庫、行動推播、SSO、升級方式和授權，採用各專案官方 sizing 數據。

應該執行哪個自架 Slack 替代方案

值得小型團隊投入時間的自架 Slack 替代方案包括 Mattermost、Rocket.Chat、採用 Synapse 的 Matrix，以及 Zulip。若要在一台伺服器上提供內部團隊工具，請使用 Mattermost。若要建立公開社群，請使用 Zulip。只有在必須與其他人管理的伺服器通訊時，才使用採用 Synapse 的 Matrix。聯邦功能是其他方案無法複製的唯一特性，也會改變系統管理工作的內容。

功能清單無法區分這 4 個方案。它們都支援頻道、討論串、搜尋、檔案上傳及行動應用程式。真正的差異在於每個月需要管理的項目：記憶體、必須持續運作的資料庫、可能無法控制的行動推播路徑，以及決定所需功能是否需要付費的授權條款。以下比較以這些面向為基準，分別評估 10 位使用者和 100 位使用者的情況。

四者實際上分別是什麼

Mattermost 是使用 Go 開發、搭配 PostgreSQL 資料庫的伺服器。它只有一個 binary、一個資料庫和一個設定檔。其操作方式類似 Slack，包含 threads 和 slash commands；在四者之中，它也是最不需要特別管理的選項，這是優點。

Rocket.Chat 是建置於 MongoDB 上的 Node.js 應用程式。它在這裡提供最完整的功能，包括語音與視訊通話，以及 omnichannel inbox，能將來自 email 和社群頻道的客戶對話集中到同一個介面。如果你是因為這個 inbox 才考慮 Rocket.Chat，請先將它與專用的 Chatwoot 客服系統比較，因為支援工作的 chat server 與團隊協作的 chat server，負責的是不同工作。

Matrix 是通訊協定，不是產品。Synapse 是參考伺服器（Python、PostgreSQL），Element 則是多數人使用的 client。這是這四個選項中唯一能讓你的伺服器與你未管理的其他伺服器通訊的選項。

Zulip 是使用 Python 開發的伺服器（Django 加上 Tornado），後端搭配 PostgreSQL、RabbitMQ、memcached 和 Redis，並由專用 script 一次完成安裝。它採用頻道內主題的模式，因此星期二的對話到了星期五仍然容易找到。Version 12.0 於 April 2026 發布。

10 位與 100 位使用者需要多少 RAM，以及使用哪個資料庫

下表中的每個數字都來自專案自己的文件，資料查閱時間為 2026 年 8 月。這些數字都不是我的測量結果，也不是自行編造。每一列採用相同基準：使用該專案公布的最小設定；若專案將資料庫分開估算，則一併計入。

ChartRAM in the smallest deployment each project documents (vendor figures, August 2026)
The data behind this chart
[
  {
    "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 程序的最低需求，但附帶一項條件：若要加入大型公開聊天室，文件要求至少要有這麼多 可用 RAM。PostgreSQL 不包含在這個數字中。Mattermost 的 2 GB 是整台機器的需求，包含資料庫，且在單一 vCPU 上適用於 1 到 1,000 位使用者。Zulip 的文件指出，使用者少於 100 位時需要 2 GB 和 1 顆 CPU，另加 2 GB swap；使用者達到 100 位以上時，則需要 4 GB 和 2 顆 CPU。Rocket.Chat 在此處公布的數字最大，為 8 GB，因為其規模估算為應用程式 4 GiB、MongoDB 4 GiB，而此級距可支援最多 500 位同時使用者。

使用者為 10 位時，這些服務都能在不需特別考量的硬體上運作。使用者增加到 100 位時，差異就會出現：Mattermost 仍在其 2 GB 級距內，Zulip 需要 4 GB 和第 2 顆 CPU，而 Rocket.Chat 文件記載的最小級距仍是 8 GB，因為 MongoDB 的記憶體需求取決於機器，而不是使用者人數。

資料庫選擇對未來升級的影響，大於對日常效能的影響。Mattermost 需要 PostgreSQL 14 或更新版本，並從 v11 開始淘汰 MySQL 支援，因此今天安裝 MySQL，明天就可能需要進行遷移。Synapse 可使用 SQLite，但其文件明確指出，SQLite 僅適合測試，因為在大型聊天室中的效能不佳。Rocket.Chat 8 需要 MongoDB 8.0，因此資料庫升級與聊天服務升級會成為同一項工作，而不是兩項工作。

2 GB VPS 實際上能支援什麼

2 GB 方案是多數供應商提供的入門規格，而且對以下 4 個服務中的 2 個確實可行。

  • Mattermost 可以使用。 這是唯一一個供應商文件明確記載可使用該規格的服務，最多支援 1,000 位使用者，且 PostgreSQL 可與其部署在同一台伺服器。10 個人在 2 GB 上使用也很充裕。
  • Zulip 可以使用，但需要 swap。 文件建議 RAM 少於 5 GB 時啟用 swap，並警告低 RAM 主機在升級期間可能發生 out of memory 錯誤，此時 tools/webpack 是失敗的步驟。這是升級時實際會遇到的故障，不是安裝時的故障。
  • Synapse 在負載低時可以使用。 閒置時的記憶體用量很小。問題在於突發用量，下一節的 federation 說明了突發用量的來源。
  • Rocket.Chat 是 2 GB 規格應避免的服務，原因在於 MongoDB 的儲存引擎。WiredTiger 會將內部快取設定為 (RAM minus 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、備份與 container runtime 都需要記憶體。請將選定的伺服器放在 你熟悉的反向代理，例如 Nginx、Caddy 或 Traefik 後方；如果使用 containers 部署，則應先正確處理 VPS 的 Docker Compose 基礎。

行動應用程式需要自行架設 push server 嗎

這是部署後才會發現的關鍵差異，也是最常決定答案的因素。

運作方式如下。Apple Push Notification service (APNs) 和 Firebase Cloud Messaging (FCM) 只接受持有該應用程式簽署憑證者發出的通知。您的伺服器無法向您未建置的應用程式發送 push。因此，使用供應商 App Store 版本的自架聊天伺服器，必須將通知交給供應商的 gateway，而條件也由供應商決定。

  • Mattermost。 免費方案是使用 https://push-test.mattermost.com 的 Test Push Notification Service (TPNS)。文件指出不建議用於 production，且不提供服務等級協議 (SLA)。它只能搭配 App Store 和 Play Store 版本使用。Hosted Push Notification Service (HPNS) 適用於 production，但需要付費訂閱。第三種方式是自行編譯 push proxy；這需要使用您自己的 APNs 和 FCM 憑證建置自有應用程式。
  • Rocket.Chat。 Push 必須先向 Rocket.Chat Cloud 註冊 workspace，且 community workspace 每月最多只能發送 10,000 則 push notification。換算下來，整個 workspace 每天約 330 則。額度用完後，必須等到下個月重置才會恢復通知；對使用者而言，這會像是應用程式故障。
  • Matrix 搭配 Element。 Synapse 會將通知傳送到 push gateway，而官方 Element 應用程式則指向由 matrix.org 執行、位於 https://matrix.org/_matrix/push/v1/notify 的 gateway。payload 會攜帶事件與 room 識別碼，而不是訊息內容；應用程式再從您的伺服器取得內容，因此 gateway 看到的是中繼資料，而非對話內容。您可以自行執行 Sygnal gateway，但這表示必須建置並發布自己的應用程式。在 Android 上，還有折衷方案：搭配您自行架設的 ntfy server 使用 UnifiedPush。
  • Zulip。 免費方案包含最多 10 位使用者的行動 push service。超過 10 位使用者後需要訂閱方案；免費的 Community plan 適用於許多非商業組織。Zulip 12.0 在 2026 年 4 月加入了 push payload 的端對端加密。

使用 10 位使用者時，這些方案都能免費提供可用的通知功能。到了 100 位使用者，情況就不同：Zulip 需要訂閱方案；Mattermost 仍可使用沒有 SLA 且不提供支援的測試服務；Rocket.Chat 的每月上限會成為限制；Matrix 則不受影響，因為 gateway 可免費使用。

哪些產品免費提供單一登入

單一登入（SSO）最能清楚呈現開放核心商業模式的差異。

  • Zulip 在自架伺服器中免費提供 SAML（security assertion markup language）與 LDAP（lightweight directory access protocol）。不需要另外購買其他方案。
  • Synapse 可在自身設定檔中免費支援 OpenID Connect（OIDC）、SAML 與 CAS。較新的部署方式逐漸改用 Matrix Authentication Service。這是獨立服務，且只能從傳統 Synapse 驗證單向遷移，因此應預先規劃遷移，而不是等到需要時才發現。
  • Rocket.Chat Community Edition 提供基本的 LDAP 與 SAML 登入。同步額外使用者屬性、對應群組與團隊，以及背景同步功能都需要 enterprise licence。
  • Mattermost 免費的 Team Edition 只提供 GitLab OAuth，沒有其他選項。SAML、AD/LDAP 與 OpenID Connect 都是付費功能。

如果你打算讓多個服務共用一次登入，請在這些服務前方部署 自架的 Authentik identity provider，並確認你持有的授權方案允許這 4 個服務實際連線至它。

聯邦功能的實際代價

聯邦功能是 Matrix 存在的理由。使用者可加入由其他人的伺服器託管的聊天室，並與帳號位於該伺服器上的使用者交談，就像郵件伺服器彼此交換郵件一樣。這裡沒有其他選項能做到這點。如果你需要聯邦功能，本頁其他方案都無法替代它。

這也是 Synapse 屬於不同類型工作負載的原因。使用者加入聯邦聊天室時，你的伺服器會保留該聊天室狀態與事件的副本，也會快取其他伺服器使用者發布的媒體，包括頭像、圖片與檔案。因此，磁碟用量會受到你未建立的聊天室，以及未在你伺服器上擁有帳號的人員所影響。這就是 Synapse 安裝的媒體儲存區，通常會比自家使用者傳送的訊息總量大得多的原因。這也是文件特別針對加入大型公開聊天室附加記憶體條件的原因。

請在第一天設定保留政策，不要等到磁碟已滿才設定：

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse 在 1.61 版加入了 media_retention，並可分別設定本機與遠端媒體的保留期限。遠端媒體屬於快取，因此使用者再次要求已清除的檔案時，Synapse 會向原始伺服器重新要求該檔案。本機媒體不屬於快取，因此較短的 local_media_lifetime 會永久刪除自家使用者上傳的檔案。

坦白說，如果使用者只彼此交談，聯邦功能不會帶來任何好處，卻會增加磁碟用量、網路頻寬需求，並使升級流程更加複雜。請將它關閉，或選擇其他伺服器。

升級方式

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 旗標會在安裝期間將伺服器註冊至行動推播服務。此時程式會要求你接受服務條款，因此請在開始前先閱讀條款。

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 的流程可預期。 替換 binary、重新啟動，啟動時就會執行遷移。自 2025 年 8 月發布的版本起，Extended Support Release (ESR) 版本軌道每 9 個月發布一次，並提供 12 個月支援。ESR 到 ESR 的升級路徑經過測試。一次跳過數個 ESR 也受支援，但未經測試。實際上，這表示需要由你自行測試。

Rocket.Chat 會將 3 項升級綁在一起。 截至 2026 年 8 月，8.x 系列是目前版本；8.7.0 已於 2026 年 8 月 6 日發布，且要求 MongoDB 8.0 與相容的 Node.js 版本。跳過主要版本，可能導致應用程式拒絕開啟資料庫。Rocket.Chat Docker Compose 安裝指南會替你將這些版本固定在一起，這也是此處採用容器路徑的主要理由。

Synapse 需要先閱讀文件。 每個版本都有升級說明。你必須閱讀所經過每個版本的說明，而不只是最終升級到的版本。升級後，Synapse 會針對資料庫執行背景更新。在小型伺服器上，這些作業可能讓機器持續緩慢數小時。這是預期行為，不是故障。

以白話說明授權條款

Mattermost 以 MIT 授權發布其編譯後的 Team Edition 建置版本，但原始碼採用 AGPLv3 或商業授權；儲存庫中部分內容則採用 Mattermost Source Available License，在 production 環境執行時需要付費授權。Rocket.Chat 除了 ee/ 目錄之外採用 MIT 授權；這些目錄各自使用 enterprise 授權。Synapse 在 1.99.0 版本改用 AGPLv3。貢獻者會簽署 CLA，讓 Element 能針對該授權提供例外並收取費用。Zulip 採用 Apache 2.0，且沒有 enterprise 目錄，因此其 SSO 說明不需要另外標註例外。

實際上，只有在你打算修改伺服器，並以服務形式提供給其他人使用時，AGPL 才會直接影響你。對小型團隊而言，更重要的是 open core 的界線，也就是免費建置版本缺少哪些功能。Zulip 缺少的功能最少，Mattermost 最多。

應該選哪一個

內部團隊工具。 Mattermost。它的文件化資源占用量最小，升級流程最不容易出問題，介面也很熟悉，無須額外說明。SSO 成為必要條件的當天，請預留付費方案的預算，因為多數團隊最後都會走到這一步。

社群伺服器。 Zulip。Topics 能讓忙碌的公開頻道在數個月後仍保持可讀性，SAML 和 LDAP 不需額外付費，升級只需執行一個命令。如果你的社群更接近貼文與回覆，而不是即時聊天，請先比較 自架論壇軟體，因為論壇更容易被搜尋引擎索引，也完全不需要 push 基礎架構。若你需要語音、視訊與全通路功能，且能提供其文件要求的 8 GB 記憶體，請改選 Rocket.Chat。

必須互通的網路。 Matrix 搭配 Synapse 與 Element。接受媒體資料持續增加，從第一天就設定保留期限，提供 PostgreSQL 與比預期更多的磁碟空間，並充分利用與你無法控制的伺服器通訊所帶來的價值。如果團隊從不進行聯邦，卻為此選擇 Synapse，就等於白白承擔這些成本。

FAQ

小型團隊適合哪個最佳的自架 Slack 替代方案？

對大多數內部團隊而言，Mattermost 是合適的選擇。其文件指出，在同一台機器上使用 PostgreSQL 時，1 個 vCPU 與 2 GB RAM 可支援 1 到 1,000 名使用者，因此符合多數供應商提供的入門級 VPS 方案。限制在於單一登入：免費的 Team Edition 僅支援 GitLab OAuth，而 SAML、AD/LDAP 與 OpenID Connect 都需要付費方案。如果免費 SSO 比類似 Slack 的介面更重要，請改用 Zulip。

我可以在 2 GB VPS 上執行自架聊天伺服器嗎？

Mattermost 可以；Zulip 也可以，但應加入 swap，因為 Zulip 官方文件建議在低於 5 GB RAM 時使用 swap。Rocket.Chat 則可能讓你失望，因為 MongoDB 的 WiredTiger 引擎會將 (RAM 減去 1 GB) 的 50% 與 256 MB 兩者中較大者配置給快取，因此 2 GB 主機約有 512 MB 會在應用程式啟動前被占用。它可能可以完成安裝，但隨著歷史訊息增加會逐漸效能下降，最後因記憶體不足而被終止。Rocket.Chat 公開的最低方案是應用程式 4 GiB，加上 MongoDB 4 GiB。

自架聊天伺服器需要自己的行動推播通知伺服器嗎？

通常不需要，因為 Apple 的 APNs 與 Google 的 FCM 只接受由應用程式簽署者發出的通知，因此供應商的應用程式會使用供應商的閘道。各產品的條款不同。Mattermost 提供沒有 SLA 的免費測試服務，以及付費代管服務。Rocket.Chat 將社群工作區限制為每月 10,000 則推播通知，超過後會停止傳送，直到月份重設。Zulip 免費提供最多 10 名使用者的推播功能，超過此人數則需要升級方案。Matrix homeserver 會透過 Element 應用程式使用的閘道推送通知，且不收費。只有在你也發佈自己的應用程式建置版本時，才需要自有閘道。

團隊從不與其他伺服器通訊，還應該自架 Matrix 和 Synapse 嗎？

不應該。Federation 是 Synapse 的用途，也是讓它更難以執行的原因。加入其他伺服器上的房間時，會將對方的狀態拉取到本機，並把其媒體檔案快取到磁碟，因此儲存空間會因與自有使用者無關的原因持續增加。請先使用簡短的 remote_media_lifetime 設定 media_retention，避免這種情況發生。只與自身通訊的團隊會承擔運維成本，卻得不到 Federation 的好處；Mattermost 或 Zulip 能以較少硬體完成相同工作。

哪個自架 Slack 替代方案提供免費的單一登入？

Zulip 和 Synapse。Zulip 在自架伺服器中免費提供 SAML 與 LDAP；Synapse 的設定支援 OpenID Connect、SAML 與 CAS，而較新的安裝方式則改用獨立的 Matrix Authentication Service。Rocket.Chat 的 community edition 提供基本的 LDAP 與 SAML 登入，但將屬性同步、群組對應與背景同步列為 enterprise licence 功能。Mattermost 的免費 Team Edition 僅支援 GitLab OAuth。

#chat#matrix#mattermost#rocket-chat#self-hosting