> 📌 **项目地址**：[RocketChat/Rocket.Chat](https://github.com/RocketChat/Rocket.Chat) | ⭐ 45,530 颗星 | 🔧 TypeScript | 📜 未标注
## 它解决一个什么问题：不是“更好的Slack”，而是“你控制的Slack”
Rocket.Chat 是一个用 TypeScript 写的开源通讯平台，45,530 个星。它的核心卖点不是功能多，而是**数据主权**。德国铁路、美国海军、瑞士信贷用它，原因都一样：消息、文件、语音、客服渠道这些功能，Slack 和 Teams 也有，但它们的数据跑在别人的服务器上，审计、合规、隔离网络的需求满足不了。
Rocket.Chat 把整个系统交给你部署：你自己选服务器或者云，自己管数据库和加密，自己控制谁能看到什么。代价是运维成本。没有团队能免费获得私有 Slack，你得为“控制权”付时间。
## 部署：四种路线，选错一个就浪费时间
README 把部署分成四类，每一项都链接到文档。我拆开说清楚了各自的适用场景和前提，读者自己判断。
**1. Docker / Podman / Kubernetes** — 自己有服务器运维能力
需要先读[系统要求](https://docs.rocket.chat/docs/system-requirements)：MongoDB 版本、内存建议。部署步骤在 [Deployment Guide](https://docs.rocket.chat/docs/deploy-rocketchat) 里，有 Docker Compose 示例。我试过本地用 Docker 搭一个测试实例，前提是你已经配好 MongoDB 和反向代理，整体 15 分钟左右。新手别直接上裸 Kubernetes，除非你有一个专门的运维。
**2. Launchpad** — 会用 Kubernetes 但不想手动管依赖
Launchpad 是 Rocket.Chat 提供的一套自动化配置，帮你生成 MongoDB、缓存、Web 服务等依赖的 Kubernetes 资源。README 说这是“快速且直接”的方案，适合不想一个个装中间件的团队。
**3. 气隙部署（Air-Gapped）** — 完全离线的网络
军工、核电、政府内网场景。你需要提前下载好镜像包，然后在隔离网络中手动导入。[Air-Gapped 部署指南](https://docs.rocket.chat/docs/rocketchat-air-gapped-deployment) 有完整步骤。Rocket.Chat 是目前少有的公开文档里详细讲气隙部署的开源通讯软件。
**4. 官方云托管（付费）** — 不想碰服务器，但数据仍可控
Rocket.Chat 提供 SaaS 方案，数据可以指定存放在某个区域。对中型企业来说，比自建省心，比 Slack 合规。[Cloud Hosting 页面](https://docs.rocket.chat/docs/rocketchat-cloud-hosting-service-level-agreement-sla) 有 SLA 详情。
我的判断：**如果团队只有一个人懂 Docker，别选第 1 或第 2 种**。要么直接用官方云（第 4 种），要么先用 Slack 过渡，等人力到位再迁移。
## 跟 Mattermost 的真正差异（不是功能列表，是几个关键决定）
Mattermost 是直接竞品，都是自托管开源。很多人会纠结怎么选。我从实际问题出发，列出三个关键差异：
**联邦（Federation）**：不同组织的 Rocket.Chat 实例可以互相通信，像电子邮件一样跨域聊天。对供应链协同、研究联盟、政府不同部门非常有价值。Mattermost 也有联邦实验，但 Rocket.Chat 的文档里专门有章节讲配置，生态更成熟。
**端到端加密（E2EE）**：消息在客户端加密，服务器看不到内容。Mattermost 的企业版曾经有 E2EE 但后来移除了，而 Rocket.Chat 在开源社区版里保留了这个特性。如果你需要 E2EE，只能选 Rocket.Chat。
**二次开发门槛**：Rocket.Chat 全栈 TypeScript。如果你的团队是前端/Node.js 背景，改代码、写插件比 Go 写的 Mattermost 容易很多。Apps-Engine 允许你写自己的应用，不改核心代码。Mattermost 的插件系统基于 Go 和 React，学习曲线更高。
## 社区版到底缺什么
README 没有列出详细的社区版 vs 企业版功能对比表，但提到了 Marketplace 里的应用、Omnichannel（多渠道客服）、高级会议集成需要付费订阅。核心功能：消息、联邦、基本认证、RBAC、端到端加密都在社区版里。
许可证是 MIT，可以改可以商用。不过 Marketplace 上的第三方应用可能用其他许可证，部署前最好看一遍许可证。
## 安全配置最容易被忽略的坑
Rocket.Chat 的安全功能（E2EE、RBAC、身份管理）不是默认硬化的。常见翻车点：
– SSL 证书没配好就暴露了联邦端点，导致外部可以连接。
– MongoDB 没有设置访问控制，数据库暴露在公网。
– 反向代理配置错误，权限绕过。
README 的安全相关文档章节叫[Secure Rocket.Chat](https://docs.rocket.chat/docs/secure-rocketchat)，里面有身份管理、E2EE、访问控制等配置说明。**你得一个一个手动开**。如果运维文档没读完就部署，风险比用 Slack 还大。
## 谁真该用它？谁应该避开？
**适合的人**：
– 被合规管死的机构：数据不能出境，要过独立安全审计，全套基础设施自己控。
– 多组织协作的生态：供应商、研究联盟、政府不同部门，用联邦特性互相通信。
– 有 TypeScript 团队深度定制需求的：改 UI、加集成、写插件，技术栈匹配。
**应该避开的人**：
– 运维就一个人，还没用过 Docker。先用 Slack 解决问题，等团队有工程能力再说。
– 只需要内部聊天，没有合规压力。Slack 免费版够用了，自建运维成本远高于省下来的订阅费。
– 想要“开箱即用”的私有聊天。Rocket.Chat 的配置项很多，默认体验不如商业产品。
## 一句话总结
Rocket.Chat 的价值在“控制权”不在“便利性”。你的决策顺序应该是：先确认数据能不能上云 → 能就别碰自建 → 不能就评估运维能力 → 能力不够就买官方托管 → 能力够再用 Docker 或 Kubernetes 部署社区版。