海外云服务器搭建 Rocket.Chat 即时通讯完整教程：自建团队 IM + 视频会议 + 全端 App（2026最新版）

Meta Description: 海外云服务器自建 Rocket.Chat 实时通讯平台完整教程：从零部署这套开源 Slack 替代品，覆盖服务器选型、官方 Docker Compose 一键部署、MongoDB 8.0 副本集硬性要求、Traefik 自动 HTTPS 与 Nginx 反代双路线、S3/MinIO 附件外置、内建 Grafana 监控、备份升级与 12 条常见问题 FAQ，另附服务器配置推荐表与服务商价格参考表。

> 关键词：Rocket.Chat 搭建、自建即时通讯、开源 Slack 替代、海外云服务器聊天服务器、Rocket.Chat Docker 部署、MongoDB 副本集、团队 IM 自建、Rocket.Chat 教程、Nginx 反代 Rocket.Chat、自建聊天平台

前言：为什么团队需要一台"自己的"聊天服务器

一句话答案：Rocket.Chat 是开源世界里最接近 Slack 的自建方案——原生支持频道、私聊、语音视频会议、文件共享，以及 Web / Windows / macOS / Linux / iOS / Android 全平台客户端，官方只推荐 Docker 一种部署方式，所以你只需要一台 2 核 4G 的海外云服务器加一条 Docker Compose 命令，就能把"团队所有对话"搬回自己的硬盘上。

这件事的价值，在于它解决的是"用别人的聊天工具"永远解决不了的四件事：

- 数据主权。Slack、飞书、企业微信里的每一条消息、每一个上传的文件都躺在别人的服务器上，导出能力受套餐档位限制，账号一旦欠费或被封，聊天记录的去向不归你管。自建之后，数据库、附件、备份全部在你自己手里，随时可以整站打包搬走。 - 可控与合规。有些团队因为业务原因必须让沟通数据落在指定地域（比如客户要求"数据不出口"），用公有云 IM 无法满足；自建方案可以选香港 / 新加坡 / 东京节点，机房里只有你自己的一台机器在存这些数据。 - 成本曲线。Slack 按人按月收费，团队从 10 人涨到 50 人，账单翻五倍；而自建的边际成本几乎是一条平线——人多了只是把 2 核 4G 换成 4 核 8G，月费从二十几美元到四十几美元。 - 可编程。Rocket.Chat 自带 Webhook、REST API 和 Apps Engine，你可以把告警机器人、构建通知、工单系统直接接进频道里。这一点对已经自建了 GitLab / Harbor / Uptime Kuma 的团队尤其重要——让机器人在群里喊一声，比让所有人去盯一个仪表盘有效得多。

如果你手上已经有一台海外云服务器在跑 WordPress 独立博客、Discourse 论坛 或 GitLab CE，想给团队补上一个"实时拉个群说事"的地方——这篇教程就是为这个需求写的。推荐用阿里云国际版 / AWS / 腾讯云国际版部署，通过 5.chengzicloud.cloud 购买享折扣；由于 Rocket.Chat 背后是一个MongoDB 数据库 + 消息中间件 + 应用进程的组合，对内存的敏感度远高于普通博客站，选机器时请把"4GB 内存起步 + SSD 云盘"当成硬门槛而不是可选项。

本文给出可直接复制执行的完整命令，以 Ubuntu 22.04 / 24.04 LTS 为主线，并单独说明 CentOS 7 / RHEL 的差异。内容顺序是：先划边界（Rocket.Chat 和你已经装过的东西各管什么）→ 再讲官方硬性要求与三条"官方明确说做不到"的红线 → 服务器配置与价格参考 → 完整部署实操（Docker Compose 路线 + Nginx 反代路线）→ 附件外置到对象存储 → 备份与升级 → 12 条常见问题。

一、先划边界：Rocket.Chat 管的是"实时对话"这一层

很多自建玩家一上手就把所有沟通工具混作一团，结果装了三套系统，团队反而不知道在哪儿说话。正确的做法是先想清楚每一层"回答什么问题"：

| 层 | 你已有的站内方案 | 回答什么问题 | 与本篇的关系 | |---|---|---|---| | 发布层 | WordPress / Typecho 博客 | "我发布，读者只看" | 博客底部可以挂一个"进群聊"的入口，把读者导进社区 | | 异步讨论层 | Discourse 论坛 | "大家提问，答案能被搜到、被沉淀" | 论坛是知识库（可搜索、可被 Google 收录），IM 是速聊（聊完就走） | | 实时沟通层 | Rocket.Chat（本篇） | "实时拉个群、发个文件、开个语音会" | — | | 邮件触达层 | 自建邮件服务器 | "正式通知、对外发信" | Rocket.Chat 依赖一个可用的 SMTP 来发注册/通知邮件 |

一句话选型：要"内容能沉淀、能被搜到" → 用 Discourse；要"实时对话、开会、传文件" → 用 Rocket.Chat；要"正式对外发通知" → 用邮件。 三者不是替代关系。一个成熟的独立团队，通常的形态是"博客（发布）+ 论坛（沉淀）+ 群（协作）"三件套：博客负责获客，论坛负责把问答变成 SEO 资产，Rocket.Chat 负责让团队和核心用户随时能说上话。

换皮自检：本站已经写过 Discourse 论坛部署，两者同属"协作工具"，凭什么再写一篇？因为它们的前提条件完全不同——Discourse 的前提是"你要一个能长期积累内容的公开社区"，Rocket.Chat 的前提是"你要一个私密的、实时的、多数消息不需要被搜索的沟通空间"。Discourse 是异步 + 公开 + 重沉淀，Rocket.Chat 是同步 + 私密 + 重即时，服务器架构也天差地别（PostgreSQL 单容器 vs MongoDB 副本集）。回答的是两个问题，不是同一个问题的两种做法。

二、官方硬性要求与三条"官方明确说做不到"的红线

搭任何自建服务，最值钱的不是"能跑起来"，而是知道它什么时候会崩。下面这些事实全部取自 Rocket.Chat 官方文档（2026 年 9 月口径，对应 Rocket.Chat 8.8 版本线），不是凭记忆写的。

2.1 软件版本要求：MongoDB 8.0 是硬门槛

Rocket.Chat 的版本与依赖是强绑定的。下表是官方为 Rocket.Chat 8.8 列出的组件要求：

| 组件 | 支持版本 | 说明 | |---|---|---| | MongoDB | 8.0 或更高（官方以 8.2 验证） | Rocket.Chat 8.x 的硬性要求，无法用 6.x / 7.x 顶替 | | Node.js | 22.22.3 | 官方 Docker 镜像与 Helm Chart 已内置，手工安装才需要自己对齐 | | Deno | 2.3.1 | Apps Engine 运行时依赖，官方镜像已内置 |

两条必须记住的推论：

1. 每个 Rocket.Chat 版本只被支持六个月（官方原文：Each Rocket.Chat version is supported for six months post-release）。这意味着自建 Rocket.Chat 是一个需要持续跟进的系统，不是装完就不管的——每半年至少要规划一次升级。 2. 从 7.x 升级到 8.x，必须先把 MongoDB 升到 8.0，再升级 Rocket.Chat。顺序反了，容器会因为数据库不兼容而反复重启。官方还特别提示：MongoDB 8.x 在 Ubuntu 26.04 上可能因为上游内核兼容问题（kernel 6.19）启动失败，暂时请用 Ubuntu 24.04 LTS 或其他受支持版本。本文主线即选 Ubuntu 24.04 LTS。

2.2 红线一：MongoDB 不是"可选组件"，官方推荐三成员副本集

Rocket.Chat 把所有工作区数据都存在 MongoDB 里。官方对生产环境数据库的措辞很明确：强烈推荐一个三成员的 MongoDB 副本集（replica set），以便其中一台故障时其他成员可以接管、避免停机。你可以自己维护这个副本集，也可以直接用 MongoDB Atlas 这类托管服务。

对自建玩家的现实含义是：如果只想要单机自用/小团队测试，官方 Docker Compose 会默认拉起一个内置的 MongoDB 容器（够用）；但只要你打算把它当成团队正式的生产通讯工具，就该认真考虑"应用 + 数据库分离"或直接上托管 MongoDB——因为数据库一挂，整个聊天系统归零。

2.3 红线二：官方推荐对象存储，明确说 GridFS"不推荐"

Rocket.Chat 默认用 GridFS 存储上传的文件（也就是把文件塞进 MongoDB）。官方文档的原话是：GridFS 不推荐用于生产，因为它会增加数据库负载、降低可伸缩性。官方强烈建议把附件外置到 Amazon S3、Google Cloud Storage（GCS）或 MinIO 这类对象存储上。

这条红线对你尤其值钱，因为本站已经写过 MinIO 私有对象存储部署——你完全可以在同一台机器或另一台机器上自建 MinIO，把 Rocket.Chat 的附件接过去，一个外部依赖都不引入。第六节会给完整步骤。

2.4 红线三：生产环境必须有域名，且只暴露 80 和 443

Rocket.Chat 的公开端口设计非常克制：只有 443（所有 HTTPS 流量）和 80（立刻 301 跳转到 443）需要对外。MongoDB 的 27017 只在数据库跑在另一台独立主机、且需要跨机访问时才开放。也就是说：

- 生产部署必须有域名，且域名的 A 记录（或 CNAME）要指向运行 Docker 的那台服务器的公网 IP——因为 Traefik 无法为一个它访问不到的域名签发证书。 - 内网端口一律不对公网开放，应用与数据库、消息中间件之间的通信都在 Docker 内部网络完成。

> 💡 这三条红线的共通点：它们都是"官方明确写出来告诉你别这么做"的段落。写搭建教程时，这类官方 WARNING/NOTE 比任何功能罗列都更值钱，因为它们替你省下的是"上线后半夜被叫起来排错"的时间。

三、服务器配置怎么选：按并发人数分档

Rocket.Chat 官方按"并发用户数"给出硬件规格（下表摘自官方 System Requirements，对应 Rocket.Chat 8.8）：

| 场景 | 并发用户 | Rocket.Chat 应用 | MongoDB | 备注 | |---|---|---|---|---| | Starter（无高可用） | 最多 500 | 2 vCPU / 4 GiB 内存 / 20 GiB 盘 | 2 vCPU / 4 GiB / 10 GiB，3 副本 | 绝大多数小团队落在这一档 | | Commercial / 高可用 | 500 以上 | 4 vCPU / 8–12 GiB / 20 GiB | 2 vCPU / 8–16 GiB / 20–80 GiB，3 副本 | 需要高可用、多副本 | | 超大规模 | 5,000 以上 | 16 vCPU / 12 GiB / 40 GiB（微服务 + Kubernetes） | 每副本 4 vCPU / 16 GiB / 80 GiB | 需拆成微服务跑在 K8s 上 |

给你的一句话结论：小团队（≤50 人、≤500 并发）直接按 Starter 档来——2 核 4G 起步。如果同一台机器上应用和 MongoDB 容器共存（官方 Compose 的默认形态），建议直接上 4 核 8G，给数据库留足内存，别卡在 4G 的边缘。

3.1 服务器配置推荐表（按用途分档）

| 场景 | 推荐配置 | 磁盘 | 说明 | |---|---|---|---| | 个人 / 3–5 人试水、先跑通流程 | 2 核 4G | 40 GB SSD | 应用与 DB 同机，够用；别指望它扛生产 | | 小团队正式用（10–50 人） | 4 核 8G | 60–80 GB SSD | 本文主推档，附件走对象存储后磁盘压力大减 | | 中团队 / 需要高可用 | 2 台各 4 核 8G（应用与 DB 分离） | 各 80 GB SSD | DB 用副本集，应用侧可水平扩容 | | 只想先本地验证一遍 | 本机 Docker | — | .env 里填 DOMAIN=localhost，用 http://localhost:3000 访问 |

> ⚠️ 一个容易忽略的成本项：Rocket.Chat 的磁盘增长主要来自用户上传的图片、文件和数据库膨胀。如果你把附件外置到对象存储（本文第六节），应用机的磁盘压力会小很多；否则请一次性买 60～80 GB，别"先 25GB 不够再加"——在线扩容虽然能做，但容器卷和数据库搬家的麻烦远大于一次买够。

3.2 服务商价格参考

下面是本文会用到的两档配置的公开官网参考区间。AWS Lightsail 和 DigitalOcean 的价格是可直接对标到具体档位的固定月费（含流量额度），而阿里云国际版与腾讯云国际版的 ECS/CVM 属于可自由配置的机型，同配置在不同地域、不同代次、不同活动下价差很大，所以给的是区间：

| 服务商 | 2 核 4G 档 月付 | 4 核 8G 档 月付 | 磁盘 | 适合本文哪一步 | |---|---|---|---|---| | DigitalOcean Droplet | $24（2 vCPU / 4 GiB / 80 GiB SSD / 4 TB 流量） | $48（4 vCPU / 8 GiB / 160 GiB SSD / 5 TB 流量） | 含 SSD | 官方文档与社区排错最贴合，chat.example.com 一键跑通 | | AWS Lightsail | $24（2 vCPU / 4 GB / 80 GB SSD / 4 TB 流量） | $44（4 vCPU / 8 GB / 160 GB SSD / 5 TB 流量） | 含 SSD | 固定月费最好预算，最低档 $5 起（本文不推荐） | | 阿里云国际版 ECS（通用型） | 约 $22～$38 | 约 $45～$70 | 另计或含盘 | 中文控制台、支持支付宝、与国内生态打通 | | 腾讯云国际版 CVM / 轻量 | 约 $20～$32 | 约 $40～$60 | 另计或含盘 | 香港/新加坡/东京节点，到国内延迟低 | | Vultr / Hetzner 等 | 约 $20～$28 | 约 $35～$55 | 含 SSD | 按小时计费，适合先跑一遍再定档 |

> 💡 一条选档口诀：人少看并发，人多看数据库。500 并发以内，瓶颈几乎永远在 MongoDB 的内存上，而不是 Rocket.Chat 应用本身——所以"4 核 8G 一台"往往比"2 核 4G 两台"更省心。通过 5.chengzicloud.cloud 购买以上平台还可享额外折扣。

> 声明：本文价格数据采集于 2026 年 9 月，仅为公开官网参考区间。云服务器价格随区域、计费方式和活动浮动，请以各厂商官网实时价格为准。除特别标注外，金额单位均为美元（USD）。

四、部署实操：从空机器到"域名能打开聊天"

下面的步骤以 Ubuntu 24.04 LTS（官方推荐，避开 MongoDB 8.x 在 Ubuntu 26.04 上的内核兼容问题）为主线。全程假设你的聊天域名是 chat.example.com——请把文中所有 chat.example.com 和 [email protected] 换成你自己的真实值。

第 0 步：三件必须先在"服务器之外"做完的事

1. 买机器：按第三节选一台 4 核 8G 的海外云服务器（香港 / 新加坡 / 东京节点到国内延迟最低）。 2. 解析域名：在你的 DNS 服务商处，为 chat.example.com 添加一条 A 记录，指向服务器的公网 IP。Traefik 无法为一个它访问不到的域名签发证书，所以这一步必须先做、并等待解析生效（dig +short chat.example.com 能返回你的 IP 即可）。 3. 开防火墙端口：只放行 22（SSH）、80、443。不要放行 3000、27017 这些内部端口。

`bash // 云厂商安全组放行 22 / 80 / 443 后，服务器本机再确认一次 sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status `

第 1 步：安装 Docker、Docker Compose 与 Git

官方要求 Docker Compose v2（即 docker compose 子命令，而不是老的 docker-compose 独立二进制）。用官方一键脚本最省事：

`bash // 安装 Docker（脚本已含 compose v2 插件） curl -fsSL https://get.docker.com | sh sudo systemctl enable --now docker

// 安装 Git sudo apt update && sudo apt install -y git

// 把当前用户加入 docker 组，之后可以不用 sudo（需要重新登录生效） sudo usermod -aG docker $USER

// 验证 docker --version docker compose version `

> RHEL / CentOS 7 差异：用 Docker CE 官方仓库安装。命令是 sudo yum install -y yum-utils → sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo → sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin → sudo systemctl enable --now docker。 > ⚠️ CentOS 7 的 glibc 2.17 不是问题——Rocket.Chat 是全容器化部署（应用、MongoDB、Traefik 全在官方镜像里），宿主机的 glibc 版本不参与运行，这与本站此前多篇自建教程（Immich / Loki / Harbor / Cloudflare Tunnel / Discourse）的结论一致。CentOS 7 真正要担心的是内核：MongoDB 8.x 需要较新的内核与 glibc，CentOS 7 的 3.10 内核上跑官方 MongoDB 8 镜像很可能失败。结论：CentOS 7 用户请改用 Ubuntu 24.04 LTS，这是最省事、也最省钱的选择——换系统的成本远低于跟内核较劲。

第 2 步：拉取官方 Compose 配置仓库

Rocket.Chat 官方维护了一个专门的部署配置仓库 rocketchat-compose，不要把 compose 文件改来改去，所有配置都通过一个 .env 文件管理：

`bash git clone --depth 1 https://github.com/RocketChat/rocketchat-compose.git cd rocketchat-compose `

仓库里包含：主配置 compose.yml、示例环境文件 .env.example，以及数据库、Traefik（反代 + HTTPS）、监控等附加配置文件。

第 3 步：配置 .env（关键参数逐个说明）

先复制示例文件：

`bash cp .env.example .env nano .env `

下面是要改动的核心段落（注意：.env 的注释符号是 #，但本文不在代码块里写 # 注释，以免博客渲染出错，说明一律写在上方）：

` RELEASE=8.8.0 DOMAIN=chat.example.com ROOT_URL=https://chat.example.com LETSENCRYPT_ENABLED=true [email protected] TRAEFIK_PROTOCOL=https `

逐项含义与坑位：

- RELEASE：填确切的版本号（如 8.8.0），生产环境绝不要用 latest。官方明确说：用固定版本号可以避免自动的破坏性升级，一切升级都在你备份好、检查完数据库兼容性之后手动进行。 - DOMAIN：填公网域名，不要带 https://、不要带任何结尾斜杠。 - ROOT_URL：用户实际访问的完整 URL，必须带 https://。 - LETSENCRYPT_ENABLED：设为 true，Traefik 就会自动向 Let's Encrypt 申请并续期证书，你不需要再手动跑 certbot。 - TRAEFIK_PROTOCOL：设为 https，强制走加密连接。

可选配置（不是必须，按需加）：如果你想接一台外部 MongoDB（比如 MongoDB Atlas 或独立副本集），改 MONGO_URL：

` MONGO_URL=mongodb://user:password@host1:27017,host2:27017,host3:27017/rocketchat?replicaSet=rs0&ssl=true&authSource=admin `

> ⚠️ 用外部 MongoDB 时，启动命令里要去掉 compose.database.yml（否则它会再拉起一个内置数据库容器），同时加上 compose.nats.yml 单独启动消息中间件。

仓库还内置了一套开箱即用的可观测栈：Prometheus 采集指标、Loki 聚合日志、Grafana 做面板。你可以选择把 Grafana 挂在路径下（https://chat.example.com/grafana，适合单域名场景），或者挂在独立子域名下（https://grafana.chat.example.com，官方推荐用于生产，更干净也更安全）。要设一个强密码：

` GRAFANA_ADMIN_PASSWORD=换成一个强密码 `

> 📌 注意：GRAFANA_ADMIN_PASSWORD 只在容器首次启动时生效一次，之后再改 .env 不会覆盖已存在的密码，必须进 Grafana 的用户偏好设置里改。

第 4 步：启动 Rocket.Chat

.env 存盘后，用同一个命令集合拉起整套服务。走 Traefik（官方默认推荐，自动 HTTPS）的启动命令是：

`bash docker compose \ -f compose.monitoring.yml \ -f compose.traefik.yml \ -f compose.database.yml \ -f compose.yml \ -f compose.nats.yml \ -f docker.yml \ up -d `

每个文件管什么：compose.yml 启动 Rocket.Chat 应用本体；compose.database.yml 启动内置 MongoDB；compose.monitoring.yml 启动 Prometheus + Loki + Grafana；compose.traefik.yml 启动 Traefik 反代并自动签证书；compose.nats.yml 启动内部消息中间件 NATS；docker.yml 提供 Docker 专属配置。

启动后检查所有容器的状态：

`bash docker ps -a `

正常情况下所有服务都应是 Up 状态；个别 MongoDB 相关的辅助容器显示 Exited (0) 也是正常的。看某个服务的实时日志：

`bash docker compose logs -f rocketchat `

第 5 步：首次访问与初始化

打开浏览器访问 https://chat.example.com（本地试跑则访问 http://localhost:3000）。首次加载时会出现安装向导，提示你创建第一个管理员账号并完成工作区初始化。这个过程中，你的工作区和邮箱会被注册到 Rocket.Chat Cloud 门户——这是官方用于推送通知和插件市场的机制，注册后即可正常使用。

五、路线二：用 Nginx 做反向代理（已有站点的选这条）

如果你已经在这台机器上跑着 Nginx（比如为了本站其他自建服务），或者团队本来就在用 Nginx 且有特定基础设施要求，可以不引入 Traefik，改用 Nginx 作为公网入口，让 Rocket.Chat 只在本地 3000 端口监听。官方把这个方案称作"Traefik 的替代方案"，步骤要多几步。

第 1 步：让 Rocket.Chat 只绑定本地

把 .env 里的这几项改回本地模式（Traefik 相关项全部关掉）：

` DOMAIN=localhost ROOT_URL=http://localhost LETSENCRYPT_ENABLED=false TRAEFIK_PROTOCOL=http `

然后启动命令里去掉 compose.traefik.yml（不要启动 Traefik），保留其余文件：

`bash docker compose \ -f compose.monitoring.yml \ -f compose.database.yml \ -f compose.yml \ -f compose.nats.yml \ -f docker.yml \ up -d `

第 2 步：用 certbot 签证书

`bash // Debian / Ubuntu sudo apt update sudo apt install -y certbot

// RHEL / CentOS sudo yum install -y yum-utils sudo yum install -y certbot

// 停掉占用 80 端口的服务后申请证书（standalone 模式） sudo certbot certonly --standalone --email [email protected] -d chat.example.com `

成功后证书文件在 /etc/letsencrypt/live/chat.example.com/ 下，fullchain.pem 与 privkey.pem 供下面的 Nginx 配置引用。

第 3 步：写 Nginx 配置

把默认站点配置改名备份，再新建一个 Rocket.Chat 的配置。下面的配置把 443 上的所有流量转给本地 3000 端口，并保留 WebSocket 所需的两个头（这两个头是实时聊天能正常工作的关键，缺了会表现为页面能开、但消息不刷新）：

` server { listen 443 ssl; server_name chat.example.com;

ssl_certificate /etc/letsencrypt/live/chat.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem;

location / { proxy_pass http://localhost:3000/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; proxy_set_header X-Nginx-Proxy true; proxy_redirect off; } }

server { listen 80; server_name chat.example.com; return 301 https://$host$request_uri; } `

如果 Grafana 挂的是独立子域名，再补一段 server 块，把 grafana.chat.example.com 反代到本地 5050 端口的根路径（注意路径是 /，不要带 /grafana 后缀）；如果 Grafana 挂在路径下，则加一个 location /grafana 块，proxy_pass 到 http://localhost:5050/grafana，并把 X-Forwarded-Proto 设为 https。

改完先验证语法，再重启：

`bash sudo nginx -t sudo systemctl restart nginx `

> ⚠️ 安全组提醒：云厂商安全组里放行 TCP/22（限你自己的 IP）和 TCP/443 即可；3000 和 5050 都不要对公网开放。

六、把附件外置到对象存储（MinIO 或 S3）

第四节讲过，官方明确说 GridFS 不推荐用于生产。把附件外置有两个好处：减轻 MongoDB 的负载，以及应用机的磁盘不再被附件撑爆。你有两条路：

- 公有云对象存储：Amazon S3、Google Cloud Storage，按量计费、免运维。 - 自建 MinIO：本站已有 MinIO 私有对象存储部署教程，可以零外部依赖地把附件接过去。

在 Rocket.Chat 管理后台的文件上传设置里，把存储类型切到对应的对象存储、填入 Endpoint、Bucket、Access Key、Secret Key 即可。一个实战建议：桶和密钥准备好之后，先在后台点一次"测试连接"，再正式切；切换后立刻上传一个文件验证，别等上线了才发现没写进去。

> 💡 反向边界：如果你的团队只是几个人、附件总量长期在几个 GB 以内，其实可以先用默认的 GridFS，不必为了"架构漂亮"额外维护一个 MinIO。官方的"不推荐"针对的是规模和性能，而不是"小团队不能用"。真正需要外置的信号是：数据库文件越来越大、附件上传开始变慢、或者你已经在用独立数据库主机。

七、备份、升级与监控

7.1 备份：Rocket.Chat 的命门是 MongoDB

Rocket.Chat 把所有工作区数据存在 MongoDB 里，所以备份的本质就是备份 MongoDB。官方给的标准命令是 mongodump：

`bash // 先找到 MongoDB 容器名（通常是 rocketchat-mongodb-1） docker ps -a

// 把整个数据库 dump 成一个二进制文件 docker exec <mongo容器名> sh -c 'mongodump --archive' > db.dump `

恢复时反向操作：

`bash docker exec -i <mongo容器名> sh -c 'mongorestore --archive' < db.dump `

> ⚠️ 一条比命令更重要的纪律：备份必须存在另一台机器或另一个对象存储桶上，不能只躺在同一台服务器的本地磁盘里。同一台机器上，磁盘坏一次，数据和备份一起没。参照本站 服务器备份与容灾恢复实战，把 db.dump 定期推到异地，并且真的演练过一次恢复——没演练过的备份不叫备份。

7.2 升级：先择时、先备份、先升数据库

升级 Rocket.Chat 的逻辑很简单：改 .env 里的 RELEASE 版本号，然后用和初次部署完全相同的那一组 compose 文件重新 up -d（少了任何一个文件，那个服务就会从项目定义里被移除）：

`bash docker compose -f compose.database.yml -f compose.yml up -d `

三条必须遵守的纪律：

1. 升级前先备份（7.1 节），这是唯一的后悔药。 2. 跨大版本升级时，先升 MongoDB，再升 Rocket.Chat。7.x 升 8.x 必须先上 MongoDB 8.0。 3. 降级 MongoDB 要先降功能兼容版本（FCV）。MongoDB 不允许数据文件由新版本创建后直接换回旧二进制——必须先在 mongosh 里把 FCV 降到目标版本、确认无误、停容器、改 MONGODB_VERSION、再启动；否则容器会反复重启。这条官方写得很清楚，但很多人是踩了坑才回头去找。

7.3 监控：官方栈已经帮你装了

第四节启动的 compose.monitoring.yml 已经把 Prometheus + Loki + Grafana 一起拉起来了。登录 Grafana（账号 admin，密码是你 .env 里设的那个），就能看 Rocket.Chat 的指标与日志。这是自建方案相对 SaaS 的一个隐性优势：你不用额外接监控，装完就有。

八、常见问题 FAQ

Q1：我在服务器上装了宝塔面板，能不能在宝塔里一键部署 Rocket.Chat？

不建议。Rocket.Chat 官方只推荐 Docker / Docker Compose 部署，它的整套架构（应用 + MongoDB + NATS + 反代 + 监控）是为容器编排设计的；宝塔是为"PHP 网站 + Nginx + MySQL"这套传统结构做的。硬把 Rocket.Chat 塞进宝塔，等于放弃官方支持、自己去拼装每一个组件，升级和维护都会变成噩梦。要自建 IM，请用一台干净的 Ubuntu 机器跑 Docker，把它和你的建站面板分开。

Q2：我只有一个公网 IP，没有域名，能装吗？

生产环境不行。官方明确要求生产部署必须有域名，因为 Traefik 无法为一个访问不到的域名签发 Let's Encrypt 证书，而 Rocket.Chat 的移动端和桌面端 App 都强依赖 HTTPS。本地验证可以：.env 里填 DOMAIN=localhost、ROOT_URL=http://localhost，用 http://localhost:3000 访问即可。真要上线，先花几美元买个域名——这一步没有捷径。

Q3：2 核 2G 的便宜机器能跑吗？会不会很卡？

官方 Starter 档的最低要求是 2 核 4G（Rocket.Chat 应用本身），MongoDB 还要另外 4G。虽然把应用和数据库挤在一台 2 核 2G 的机器上"理论上能起来"，但只要人一多、消息一多，MongoDB 会因为内存不足频繁换页，表现就是"平时能用、一忙就卡"。结论：4GB 内存是门槛，8GB 是舒适区。省下的那几美元月费，换来的是团队成员抱怨"消息发不出去"。

Q4：用户说收不到注册邮件/通知邮件，我该从哪里查起？

Rocket.Chat 依赖一个可用的 SMTP 来发信。排查顺序是：① 管理后台的邮件设置里是否配了 SMTP 主机、端口、账号；② 用后台的"发送测试邮件"功能验证；③ 检查发信域名是否配了 SPF / DKIM（没配基本会进垃圾箱）；④ 看容器日志 docker compose logs -f rocketchat 有没有连接被拒。关键判断：如果只是收不到、但注册流程能往下走，多半是进了垃圾箱或 SPF/DKIM 的问题；如果连测试邮件都发不出，就是 SMTP 账号或网络出口的问题。发信域的配置思路与 自建邮件服务器 完全一致。

Q5：应用和 MongoDB 一定要分家吗？

不一定，但要知道代价。官方 Compose 默认把应用和 MongoDB 放在同一台机器的两个容器里，对小团队（≤500 并发）完全够用。分家的价值只有一个：当数据库出问题时，你的聊天应用不会跟着一起挂；同时数据库可以独立扩容、独立备份。如果你打算把它当成团队正式的生产工具（而不是玩票），建议至少把"数据库独立备份 + 异地副本"做实，再考虑物理分家。

Q6：能不能把 Rocket.Chat 装在 example.com/chat 这种子目录里？

不建议。Rocket.Chat 的 ROOT_URL 设计是针对"一个域名 = 一个工作区"的，用子目录部署会让 WebSocket、文件链接、移动端 App 的配置全部错位。正确做法是给它一个独立子域名（chat.example.com），这样和一个已有的 Nginx 站点共存毫无压力——这正是第五节那条路线的价值。

Q7：升级会停机吗？会不会影响用户？

会短暂停机。升级的本质是"拉取新镜像 + 重启容器"，配置的重新加载、数据库的迁移都需要时间。把升级安排在低峰期，并提前在群里通知。真正要防的不是"停机几分钟"，而是升级失败后回不去——所以升级前的 mongodump 备份是硬性动作，没有备份就不要按升级键。

Q8：和 Slack / 飞书比，自建到底值不值？

把账算清就是答案：Slack 按人按月收费，50 人团队一年就是数千美元；而一台 4 核 8G 的海外服务器年费大约 $500 上下，软件本身免费、无人数上限。但"值不值"从来不只是钱——你付出的是运维时间：服务器安全更新、版本升级（每半年至少一次）、数据库备份、偶尔排错。一句话判断：如果你团队里已经有人在维护服务器、看得懂 Docker 和 Nginx，自建的边际成本极低；如果没有任何人愿意碰命令行，那么用 SaaS 是更诚实的选择。

Q9：Rocket.Chat 的数据能不能搬到另一台服务器？

能，而且很简单，因为所有数据都在 MongoDB 里。流程是：旧机 mongodump → 把 db.dump 传到新机 → 新机按本文重新部署一套 → mongorestore 恢复 → 检查附件存储配置。唯一要注意的是附件：如果你用了对象存储，附件本来就在桶里，不受影响；如果用 GridFS，它跟着数据库一起被 dump 出来了，直接恢复即可。

Q10：CentOS 7 能装吗？glibc 2.17 会不会不兼容？

glibc 2.17 不是问题（全容器化部署，宿主机的 glibc 不参与运行——这是本站自建教程反复验证过的结论，同 Immich / Loki / Harbor / Cloudflare Tunnel / Discourse）。但 CentOS 7 的 3.10 内核是问题：MongoDB 8.x 需要较新的内核支持，在 CentOS 7 上跑官方 MongoDB 8 镜像很可能启动失败。所以 CentOS 7 用户请换 Ubuntu 24.04 LTS。换系统花的时间，远少于跟老内核较劲的时间。

Q11：内网 / 离线环境能用吗？

可以。Rocket.Chat 支持内网部署，官方也提供 FIPS 合规部署指南（面向有合规要求的机构）。需要注意两点：① 官方 Docker 镜像、MongoDB 镜像、以及插件市场的资源需要预先下载到内网；② 如果完全离线，推送通知、插件市场这些依赖 Rocket.Chat Cloud 的能力会受限，官方有一份"防火墙配置"文档列出了需要放行的 URL。内网部署反而是自建 IM 相对 SaaS 最不可替代的场景——很多企业的沟通数据就是不允许出内网。

Q12：Rocket.Chat 免费版和付费版差在哪？

社区版（Community，也就是本文部署的这套）功能完整，频道、私聊、音视频、文件、全端 App、Webhook、REST API、Apps Engine 都在里面，没有人数上限。付费的企业版（Commercial / Government / Defense）主要加的是高可用支持、合规认证（FIPS 等）、企业级 SSO/LDAP 深度集成、以及官方 SLA 支持。对绝大多数中小团队来说，社区版足够了——你真正该预算的不是 License，而是"有没有人负责维护它"。

九、结语

把这篇教程压缩成一句话：Rocket.Chat 的安装本身不难（克隆仓库、填 6 行 .env、一条 compose 命令），难的是它周围那三件事——数据库、附件、备份。

- 数据库决定它扛不扛得住人（MongoDB 是命门，4GB 内存是门槛）； - 附件决定它的数据库会不会被文件撑爆（外置到 S3/MinIO 是官方推荐）； - 备份决定它会不会"一次误删就归零"（异地副本 + 演练过恢复才算数）。

这三件事都是通用能力。做完一遍之后你会发现，同样的思路可以直接套到本站其他自建服务上——Discourse 论坛 的数据库备份、MinIO 的对象存储、服务器备份与容灾 的异地策略，本质上是同一套东西。这也是自建这条路最大的复利：你练的不是某一个软件，而是"把任何软件安全地跑起来"的手感。

延伸阅读：

- 海外云服务器搭建 Discourse 论坛完整教程——异步讨论层搭档，与本文的实时 IM 构成"论坛 + 群"组合 - Docker + Portainer 容器管理平台部署教程——理解本文全部容器命令的基础概念篇 - MinIO 私有对象存储部署教程——第六节附件外置的自建落地 - 海外云服务器搭建 Nginx + Let's Encrypt SSL 完整教程——第五节反代与证书管理的细节参考 - 服务器备份与容灾恢复实战——把 7.1 节的本地备份升级成异地副本 - Uptime Kuma 可用性监控与公网状态页部署教程——给聊天首页加一个 7×24 的哨兵

> 本文由 5.chengzicloud.cloud 提供，点击访问首页了解更多海外云服务器部署方案和专属优惠。