大规模开源团队沟通：自己运行 Mattermost

hands typing a message on a phone in a dark room

每隔几年，总会有公司盯着自己的 Slack 账单，把每位用户的费用加起来，忽然意识到十年的内部对话正躺在别人的数据库里、在另一个司法辖区之下，于是开始追问有没有别的路。有的。Mattermost 是自托管方向最可信的答案，而且已经如此多年。

它同时也是部署前最常被误解的工具，因为你以为自己拿到的那个免费版本，通常并不是你最终跑起来的那个。这篇指南要讲的是 Mattermost 究竟是什么、免费版本真正包含哪些东西，以及几乎每个第一次自托管的人都会撞上的三个运维问题。

Mattermost 是什么

一个 Go 语言写的服务端、一套 PostgreSQL 数据库、一个 React 网页客户端，以及原生的桌面和移动应用。频道、话题串、文件共享、搜索、斜杠命令、入站和出站 webhook、机器人，还有一套插件框架。用过 Slack 的人一个下午就能上手，其他人也一样，而当你要求整家公司搬家时，这一点比任何功能清单都重要。

围绕这个内核的是 Playbooks，用于以检查清单驱动的事件和流程工作，以及 Calls，用于语音、视频和屏幕共享。自 v11.0 起，Playbooks 需要某个商业版本才能使用（免费的 Entry 也算）。集成目录覆盖了常见的那几位：GitLab、GitHub、Jira、Jenkins、PagerDuty。产品真正强的地方是 ChatOps，这也是它在工程和运维团队中拥趸众多的原因，同样受青睐的还有那些根本不能把流量放进商业 SaaS 的国防与公共部门机构。

架构上最关键的事实是：这一切都跑在你自己选择的基础设施上。原则与用 Matomo 自托管分析或用 Mautic 自托管营销自动化完全一致。消息在你的数据库里，文件在你的对象存储里，谁也不能不问你一声就改保留策略或者改价格。

授权的真实情况，直说

这里最容易让人糊涂，所以不妨说得直白些。

Team Edition 才是开源的那个：免费，二进制文件采用 MIT 许可，大多数自托管者多年来运行的也是它。你能得到消息、频道、话题串、搜索、集成、webhook 和插件框架。你得不到 SAML 或 AD/LDAP 单点登录、合规导出、企业级搜索、高可用集群和访客账号。v11.0（2025年10月）之后，它又失去了 GitLab 单点登录和 Playbooks，Mattermost 现在把它定位为面向小团队、爱好者和个人使用，适合激活用户少于 250 人且不需要单点登录（SSO）的场景。

Entry 是一个免费的商业版本，具备 Enterprise Advanced 的功能，但有针对整台服务器的限制：只能查看和搜索最近的 1 万条频道消息（更早的消息仍留在数据库里），没有合规功能，没有高可用，只有社区支持。Mattermost 还列出了几项据称将在未来版本中生效的上限：每月 5 次活跃的 playbook 运行、最长 40 分钟的通话、每月 1 万条推送通知。它的目标是五十人以下的团队。作为评估付费产品的方式，这挺好。作为公司对话历史的长期归宿，这很糟，因为历史上限限制的恰恰是你最终会在意的东西。

Professional、Enterprise 和 Enterprise Advanced 是付费档位。Professional 增加 SSO、MFA 和精细权限，Mattermost 把它定位于最多 250 名用户的团队。Enterprise 增加 AD/LDAP 同步、合规自动化、企业级搜索、高可用和规模化的 Playbooks。Enterprise Advanced 增加涉密信息处理、零信任控制和气隙部署，国防与政务用户就在这一档。Mattermost 已经不再公开按用户计价，所以要预留一次和销售沟通的时间。

过去，这个选择比档位清单看上去要简单，v11 改变了这一点。大约 250 人以下、用本地账号、不需要单点登录，Team Edition 依然够用。只要需要单点登录（SAML、AD/LDAP，现在连 GitLab 也算），就得用商业版本：限制够用时用 Entry，之后是 Professional 或 Enterprise。Mattermost 曾为 GitLab 登录提供的过渡办法是停留在 v10.11 长期支持版（ESR），而该版本已于 2026年8月15日结束生命周期。大型组织，或者有合规、数据保留、高可用要求的组织，应从一开始就把 Enterprise 纳入规划和预算。

怎么搭建

小规模部署

对于几十人到几百人的团队，一台配置合理的 VPS 真的就够了。Mattermost 自己的建议把一到一千用户放在一个 vCPU 加 2GB 内存上，这跟所有厂商的最低配置一样乐观。给它四核 8GB，你就再也不会想起它。

技术栈是 Mattermost、PostgreSQL，再加一个终结 TLS 的反向代理。Traefik 配 Let's Encrypt 是最省事的：

services:
  mattermost:
    image: mattermost/mattermost-team-edition:release-11.7
    restart: unless-stopped
    environment:
      - MM_SQLSETTINGS_DRIVERNAME=postgres
      - MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:your_secure_password@db:5432/mattermost?sslmode=disable
      - MM_SERVICESETTINGS_SITEURL=https://chat.example.com
    volumes:
      - mm_data:/mattermost/data
      - mm_config:/mattermost/config
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=mmuser
      - POSTGRES_PASSWORD=your_secure_password
      - POSTGRES_DB=mattermost
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  mm_data:
  mm_config:
  db_data:

在邀请任何人之前，先把 SiteURL 设对。写错或者干脆没设的 SiteURL 会让推送通知、OAuth 回调和链接预览全都出问题，事后排查很烦，现在避免却毫不费力。

有一条提醒值得重复，因为厂商自己也这么说：容器用来评估和跑小型生产环境没问题，但这条路本身不提供集群和高可用。如果你需要这两样，就直接装在 Linux 上，或者用 Kubernetes operator。按照官方 Docker 指南的建议，把镜像固定在某条版本线上：示例用的是当前的长期支持版（ESR）11.7，因为 latest 会在 v12 发布当天切换过去。

生产部署

v11 的最低要求是 PostgreSQL 14。定于 2026年10月14日发布的 v12.0 会把它提高到 PostgreSQL 15，所以请从 15 或更高版本起步（上面的示例用的是 16）。MySQL 支持已随 2025年10月的 v11.0 终止，新部署不再有 MySQL 这个选项。Amazon Aurora PostgreSQL 受支持，在 AWS 上是理智的托管选择。如果直接装在 Linux 上，请注意 v11.11（2026年9月）是最后一个支持 RHEL 7 和 RHEL 8 的版本。

从第一天起就把文件放进兼容 S3 的对象存储。本地文件系统能用，也是默认值，同时它也正是那个悄悄让你的服务器带上状态、让备份变得庞大、让迁移变得痛苦的东西。以后再换意味着搬文件、改路径。安装时就换，意味着填几个配置项。

要高可用就需要 Enterprise 档：负载均衡后面挂多个应用节点、一份共享对象存储，以及带只读副本的数据库。要做大规模搜索则需要 Elasticsearch 或 OpenSearch，同样属于 Enterprise。PostgreSQL 的全文搜索应付几百人和几百万条消息绰绰有余，而且 CJK 搜索现在在 PostgreSQL 上默认可用，这在过去恰恰是购买搜索附加组件的真实理由。

会出问题的三件事

上面这些文档里都有。下面这些是人们在生产环境里才发现的。

推送通知并不是你以为的那种免费

移动推送必须走苹果和谷歌的网络，这意味着必须有东西持有签名证书。Mattermost 运营着一个 Test Push Notification Service，开箱即用，并且明确说明不适用于生产。Hosted Push Notification Service 才是生产用的那个，它随付费许可一起提供。

第三种选择是自己跑 push proxy。文档很完整，也完全做得到，但这意味着你要用自己的 Firebase 和 APNs 凭据构建并分发自己的移动应用，那是一段和应用商店的关系加上一套发布流程，不是一个下午的事。

在推向手机之前就决定走三条路中的哪一条，而不是等第一个人来问为什么只有应用开着才收得到消息。仅这一项，就比其他任何原因更常让 Mattermost 迁移半途而废。

Calls 需要的不只是一个端口

Calls 有两种模式。集成模式把媒体服务跑在 Mattermost 服务端内部，推荐用于约五十名活跃用户以下。超过这个量就该上 rtcd，一个把通话媒体流从主服务器上剥离出去、可以横向扩展的独立服务。rtcd 需要 Enterprise。

无论哪种方式，客户端都必须通过 UDP 的 8443 端口连到媒体服务，而这个端口必须在跑媒体服务的那台主机上打开。你的 nginx 反向代理不会转发它，因为 nginx 根本不在 UDP 的链路上。那些「通话连不上」的帖子里，有一半最后都归结为一条从来没加过的防火墙规则。

在免费档，你能得到的是有时长限制的一对一通话，而不是不限量的群组通话。如果全公司视频是硬性要求，就把它算进成本。

总得有人来运维

诚实的成本比较不是许可费对零。而是许可费对基础设施再加上那个打补丁的人。Mattermost 每月发布一个功能版本（截至 2026年10月10日，最新是 11.11，长期支持版是 11.7），出于安全考虑你会想保持更新，而升级会带来数据库迁移，这些最好在非生产环境里先试一遍。

对于本来就在跑自有基础设施的团队，这属于边际工作量，账算下来毫无悬念。对于一家十个人、没有运维能力的公司，一张 SaaS 账单可能真的比那些搭进去的周二下午更便宜。诚实面对你属于哪一种。

从 Slack 搬出来

Mattermost 提供了从 Slack 导出文件导入的路径，它确实能用，但有些前提值得提前知道。公开频道的消息和用户迁移得不错。私有频道和私信取决于你的 Slack 套餐究竟允许导出什么。话题串、附件、自定义表情和集成都需要额外照看，其中一些得重建。

行得通的做法是：把历史作为可检索的归档导入，把切换日当作一次干净的开始。想要一比一复刻 Slack 的每一个行为，正是两周的迁移变成两个季度的迁移的方式。

让两套系统并行两周，先搬一个团队，并在一开始就公开定下关停日期。聊天工具的迁移是败在社会层面，而不是技术层面。

欧洲视角

对于欧盟的公司，这不只是钱的问题。自托管把内部沟通放进了一条你能控制的边界之内，这同时改变了好几场对话的形状：GDPR 的数据传输分析、NIS2 的供应链审查，以及在公共采购中越来越常出现、并且构成《云与人工智能发展法案》全部主题的主权问题。

内部聊天是一家公司所拥有的密度最高的机密材料集合之一。里面有事故细节、客户名称、本不该被粘贴却还是被粘贴进来的凭据，以及每一场正在进行的商业谈判。当有人问这些数据住在哪里时，能用一个地域和一个机柜来回答，而不是一份子处理者名单，这本身就值点什么。

什么时候别折腾

如果公司只有十五个人、合规要求很轻、也没人愿意接手一台服务器，就用 SaaS。省下的钱抵不上花掉的注意力。

如果你需要和一个你本来就住在里面的生态做深度集成，那就认真看看会失去什么。身处 Microsoft 365 环境里的团队，会白得到很多你得重建的东西。

而如果推动力只是某个大嗓门对某家厂商的反感，而不是关于成本、控制权或司法辖区的真实需求，那么迁移会卡在六成左右的采用率上，对一个沟通工具来说，这是最糟的结局。

我们能帮上什么

我们为在欧洲经营的公司部署和运维自托管的开源基础设施，包括那些一点也不光鲜的部分：push proxy、对象存储迁移、升级路径，以及那个能让聊天工具真正扎根的身份集成。

如果你想要一套尺寸合适的 Mattermost 部署、一次由做过这件事的人规划的 Slack 迁移，或者一个关于自托管对你的团队是否划算的诚实答案，请写信到 office@c9group.dev。关于我们的基础设施工作，详见 AWS 成本优化页面。

如果你正在组装一整套自托管技术栈，同样的道理也适用于分析和营销自动化。

发布日期：2026年8月8日（更新日期：2026年10月10日） 分类：协作、开源、隐私