关于我们服务作品文章
← Back to Articles

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

hands typing a message on a phone in a dark room

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

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

Mattermost 是什么

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

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

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

授权的真实情况，直说

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

Team Edition 才是开源的那个。MIT 许可、免费、没有用户数上限，也是大多数自托管者实际运行的版本。你能得到消息、频道、话题串、搜索、集成、webhook 和插件框架。你得不到 SAML 或 AD/LDAP 单点登录、合规导出、企业级搜索、高可用集群和访客账号。

Entry 是一个免费的商业版本。它解锁了高级功能集，但给你设了上限：消息历史有限、playbook 运行次数有限、只有社区支持，目标是五十人以下的团队。作为评估付费产品的方式，这挺好。作为公司对话历史的长期归宿，这很糟，因为历史上限限制的恰恰是你最终会在意的东西。

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

大多数团队面对的选择，比档位清单看上去要简单。如果你需要对接自己的身份提供方做 SAML，那就要付费。如果本地账号或 GitLab OAuth 能凑合，Team Edition 撑起的组织规模会大得让你意外。

怎么搭建

小规模部署

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

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

services:
  mattermost:
    image: mattermost/mattermost-team-edition:latest
    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。

生产部署

PostgreSQL 14 或更高。MySQL 支持从 v11 起进入弃用流程，所以现在新建的系统不要从 MySQL 起步。Amazon Aurora PostgreSQL 受支持，在 AWS 上是理智的托管选择。

从第一天起就把文件放进兼容 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 发布频繁，出于安全考虑你会想保持更新，而升级会带来数据库迁移，这些最好在非生产环境里先试一遍。

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

从 Slack 搬出来

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

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

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

欧洲视角

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

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

什么时候别折腾

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

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

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

我们能帮上什么

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

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

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

发布日期：2026年8月8日 分类：协作、开源、隐私

← Back to All Articles