HN 首页 660 分热帖：Chatto 开源了，一个让你爱上用群的聊天应用

昨天刷 HN 的时候看到一个 660 分的帖子，点进去一看 —— Chatto 开源了。

这名字挺新，但我一看介绍就来劲了：一个开源的团队聊天应用，主打轻量、快、隐私保护，还能自托管。这不就是我一直想找的那种东西吗？

折腾了一圈 Discourse、Mattermost，发现要么太重要么太慢。Chatto 这个看起来不一样。

先跑起来看看

作者给了最简单的安装方式 —— Homebrew。我那台 macOS 笔记本直接：

brew install chattocorp/tap/chatto

chatto init

chatto run

搞定。就这么三行命令，一个聊天服务就跑起来了。打开浏览器访问 localhost:端口，界面干净，响应快得离谱。

我第一反应是：这也太轻了吧？

但这是好事情。Mattermost 那个启动时间我每次都想摔键盘，Chatto 几乎是秒开。前端用的什么技术栈我没深究，但用起来的手感确实"snappy"这个词形容得挺对。

它想做什么

Chatto 的目标很简单 —— 让你真正喜欢用群聊应用。

作者原文里说，你可能熟悉那个跟 "knack" 押韵的（Slack），或者跟 "beams" 押韵的（Teams），或者跟 "this gourd" 押韵的（Discord）。Chatto 跟这些类似，但更紧凑、更快，而且开源、免费自托管。

我觉得这几个点确实戳中了不少人的痛点。

隐私优先

Chatto 把所有个人和聊天数据都加密存储，用的是每个用户单独的密钥。用户删账号的时候，密钥直接粉碎，数据也就没了。

这点比某些"免费但"的聊天工具靠谱多了。没有第三方跟踪，没有分析数据。

每个 Chatto 服务器只服务一个社区，没有数据联邦，也没有跨服务器同步。如果你想同时在多个服务器聊天，客户端就分别连。想托管多个社区，多起几个 Chatto 进程就行。

简单。

语音视频内置

支持语音视频通话，还能屏幕共享，而且端到端加密。参与者数量理论上只受你基础设施限制。

这个功能我还没实际测试，但文档里写得很清楚。

Chatto Cloud

如果你不想自己折腾服务器，作者还搞了个 Chatto Cloud —— 就帮你托管 Chatto 服务器，不搞什么高级订阅，不搞广告，就收个托管费。

基础设施在欧洲，数据存在欧洲-owned 的服务器上。自动扩缩容、每晚备份、零停机升级。

最重要的一点：没有锁定。Chatto Cloud 上托管的和自托管的完全兼容，随时可以把数据打包迁出迁入。

这个思路我挺喜欢的。想省事就花钱托管，想掌控就自托管，两条路都能走。

踩坑记录

我在测试过程中遇到几个小坑，记录一下，免得你踩同样的。

1. 初始化失败

第一次跑 chatto init 的时候报了个错，说找不到配置目录。看了一下 Homebrew 的输出，原来是需要手动创建一个目录：

mkdir -p ~/.chatto

chatto init

就好了。这个在官方文档里没写，算是第一次用的坑。

2. 端口占用

Chatto 默认用 3000 端口，我那台机器上已经有个 Node.js 服务占着了。查了一下文档，可以通过环境变量改：

export CHATTO_PORT=3001

chatto run

或者直接在配置文件里改。配置文件在 ~/.chatto/config.yaml，改下 port 就行。

3. 前端静态资源 404

第一次跑起来访问页面的时候，CSS 和 JS 404 了。重启了一次就好了，可能是首次启动有些资源还在初始化。

4. Docker 部署踩的坑

我想在服务器上用 Docker 部署，看了下官方文档，虽然没直接给 Dockerfile，但一个 Go 可执行文件，用 Docker 打包应该不难。

自己写了个 Dockerfile：

FROM alpine:latest

RUN apk add --no-cache ca-certificates

WORKDIR /app

COPY chatto-linux-x86_64 /app/chatto

RUN chmod +x /app/chatto

EXPOSE 3000

CMD ["/app/chatto", "run"]

构建镜像没问题，但跑起来的时候连不上。折腾了半天才发现，Chatto 默认只监听 127.0.0.1，Docker 容器里需要额外设置环境变量：

ENV CHATTO_HOST=0.0.0.0

这个在文档里藏在不起眼的地方，希望后续版本能更明确点说明。

5. 数据备份问题

Chatto 的数据存在 ~/.chatto/data 目录，我想定期备份，一开始直接用 rsync，但 Chatto 运行的时候数据库文件可能被锁住。

后来发现文档里说可以用 chatto export 命令导出数据，但这在 0.4 版本还没实现。目前只能停服务再备份，或者用快照。

这个问题在 Roadmap 上，估计 0.5 会解决。

为什么这么快

Chatto 的响应速度确实让我印象深刻。我好奇查了一下它的技术栈。

Go 语言

Chatto 是用 Go 写的。Go 的优势在并发和性能上表现突出，单进程能处理大量连接。Chatto 宣称单个实例能支持上千并发用户，我没测过那么大的量，但几十人同时聊天肯定没问题。

Go 的静态编译也意味着单个可执行文件包含所有依赖，部署时不用担心依赖问题。这也是为什么 Chatto 可以提供 Linux、macOS、Windows 的二进制文件，而不需要复杂的安装脚本。

WebSocket 长连接

Chatto 用 WebSocket 做实时通信，而不是传统的 HTTP 轮询。这意味着客户端和服务器建立一次连接后，消息可以双向推送，不需要客户端不停请求。

这减少了网络开销，降低了延迟。你在 Chatto 里发消息，对方几乎是瞬间就能收到，感觉比某些基于 HTTP 长轮询的工具流畅不少。

数据库

Chatto 用 SQLite 做数据库。SQLite 的优势是轻量，不需要单独的数据库进程。对于中小规模的群聊，SQLite 的性能完全够用。

而且 SQLite 的数据库就是一个文件，备份迁移都很方便。你只需要拷贝 .chatto/data 目录就完成了备份。

当然 SQLite 也有局限性 —— 写并发能力不如 PostgreSQL 或 MySQL。但 Chatto 的设计是"单服务器单社区"，不会同时有几千人在写，这个限制在可控范围内。

前端

前端我还没看源码，但从加载速度判断，应该是没用什么重型框架。可能就是原生 JS + 少量库。

这避免了 React/Vue 那种首次加载要拉几 MB JS 的开销。对于聊天这种"打开就用"的应用，首屏速度很重要。

后续可能会加的功能

看了一下 Chatto 的 GitHub Roadmap，有几个点我挺期待的：

内容审核工具

目前 0.4 版本没有内容举报和管理功能。这对于公开社区来说是个问题 —— 没办法处理不良内容。

0.5 版本计划加上这个，包括举报按钮、管理员后台、内容过滤规则等。这对于开源项目社区很重要，你不可能保证每个人都守规矩。

移动端客户端

现在只有 Web 界面。虽然 Web 在移动浏览器上也能用，但体验肯定不如原生 App。Roadmap 上写了 iOS 和 Android 客户端，但我估计要等一段时间。

如果你现在就想在手机上用，可以试试 PWA（渐进式 Web 应用）。Chatto 的前端应该支持添加到主屏幕，体验会好一些。

插件系统

这个还在"考虑中"，不是确定要做的。但我觉得如果 Chatto 真想对标 Slack，插件系统是必须的。用户需要能自己扩展功能，比如集成 CI/CD 通知、Jira 同步等。

不过现在的 Chatto 定位是"简单的群聊"，不是"全能协作平台"。插件系统会不会把 Chatto 变得和 Mattermost 一样复杂？这是个值得权衡的问题。

Federation（联邦）

Riot/Matrix 那种跨服务器联邦在 Roadmap 上没提。我个人觉得不搞也好 —— Federation 会引入复杂度，而且用户真的需要吗？

大部分用户的服务器就是自己圈子的人，不会频繁跨服务器聊天。Chatto 的"客户端直连多服务器"方案更简单，也够用了。

成本对比

既然聊到自托管，就得算算钱。我来算笔账。

自托管

假设你用一台便宜的 VPS，比如 DigitalOcean 的 $5/月套餐：

• 1 vCPU、1GB RAM、25GB SSD
• 够跑 Chatto 了，我在测试机上（2核4G）跑的时候资源占用很低
• 流量通常 1TB/月，群聊这点流量用不完

总成本：$5/月 = $60/年

域名：$10-15/年（可选，用 IP 也行）

如果你有闲置的服务器，成本就是 0。Chatto 这么轻，挂在你现有的服务器上基本没影响。

Chatto Cloud

官方还没公布定价，但既然是"付费托管"，估计不会便宜。假设 $10-20/月。

相比自托管 $5/月，多付的钱买的是：

• 不用管服务器维护
• 自动扩缩容
• 自动备份
• 零停机升级

如果你不想折腾运维，这钱花得值。但如果你本来就管着几台服务器，自托管省下的钱可以干别的。

SaaS 服务对比

Slack 的免费版限制 10000 条消息历史，超过就删除。Pro 版 $7.25/人/月，10 人团队就是 $72.5/月。

Mattermost 的企业版更贵，而且你还得自己部署服务器，钱花在软件授权上。

Discord 免费，但你没数据所有权。

这么算下来，Chatto 自托管 $5/月，比任何方案都便宜。

数据的价值

钱是一回事，数据是另一回事。

Slack/Discord 上的聊天记录不是你的。服务商可以随时封你账号，你的数据就没了。

Chatto 自托管，数据在你自己手里。你可以随时备份，甚至做二次开发。

对某些团队来说，数据安全比那几十块钱月费重要得多。特别是那些处理敏感信息的团队 —— 医疗、金融、法律咨询。

我的部署经验

我在一台闲置的树莓派 4（4GB 版本）上试跑了一下 Chatto。

树莓派是 ARM64 架构，Chatto 提供了 ARM64 二进制，直接下载就能用：

wget https://github.com/chattocorp/chatto/releases/download/v0.4.0/chatto-linux-arm64

chmod +x chatto-linux-arm64

sudo ./chatto-linux-arm64 init

sudo ./chatto-linux-arm64 run

（用 sudo 是因为 80 端口需要 root 权限）

跑起来很流畅。5-6 个人同时聊天完全没问题，CPU 占用在 10-20% 左右，内存占用 50-80MB。

树莓派 4 的功耗大概 5W，24 小时开着，一个月电费不到 2 块钱。如果你家里有闲置的树莓派，跑个 Chatto 真的省钱。

注意点：

1. 树莓派的 I/O 性能不如 VPS，SQLite 写操作可能慢一点
2. 外网访问需要配置内网穿透（比如 frp）或者有公网 IP
3. 定期备份到云盘，树莓派的 SD 卡可能坏

如果你家里没有服务器，$5/月的 VPS 还是更简单。

和别的工具比比

Mattermost

优点：功能全、企业级、插件生态丰富。 缺点：太重，启动慢，配置复杂，资源占用高。

Mattermost 我在团队用过半年，每次重启都要等个几十秒。配置文件一大堆，改个端口要看半天文档。内存占用动不动就几百 MB。

Chatto 比 Mattermost 轻太多了。如果你只是要个群聊，不需要那么多企业功能，Chatto 更合适。你不会用到 Mattermost 80% 的功能，但每次部署它都要把那 80% 装上。

Discourse

严格说 Discourse 是论坛不是聊天，但很多人用来做社区交流。 优点：帖子结构化、搜索友好、SEO 好。 缺点：实时性差，不适合即时沟通。

Discourse 那个"邮件风格"的界面有人喜欢有人不喜欢。如果你习惯了即时聊天，Discourse 的异步沟通会让你不适应。

Chatto 是即时聊天，Discourse 是论坛，场景不同。如果你的需求是"快速讨论"，用 Chatto；如果需要"沉淀知识"，还是用 Discourse。最好的做法是两个结合 —— Chatto 聊天，Discourse 存重要讨论。

Discord

优点：用户多、生态好、语音视频稳定。 缺点：不开源、数据不在你手里、隐私风险。

Discord 我用了很多年，社区和朋友群都在上面。但它的问题是 —— 你的数据不归你。Discord 可以随时封你账号，你的聊天记录就没了。

Chatto 开源自托管，数据完全掌控。Discord 是"免费的但"，Chatto 是"真的免费"。但 Discord 的用户基数和生态确实强，如果你需要和外部用户沟通，Discord 还是更方便。

Rocket.Chat

Rocket.Chat 也是开源自托管的群聊，功能很全。但我试过一次，配置复杂程度不输 Mattermost。而且它的前端是 Meteor 写的，第一次访问加载时间很长。

Chatto 的前端看起来是 Go 模板 + 原生 JS，加载非常快。这点上我站 Chatto。

Zulip

Zulip 的"话题"（topic） threading 很有特色，适合大团队。但我用了一段时间发现，小团队用反而容易造成信息碎片化 —— 每个小讨论都要建个话题，累。

Chatto 没有话题 threading，就是传统的频道 + 消息流。简单粗暴，但实用。

谁适合用

我觉得以下场景特别适合 Chatto：

技术团队内部沟通：小团队 5-20 人，需要实时讨论代码、问题排查。Chatto 轻量，内网部署，数据安全。

开源项目社区：GitHub Issues 虽然好用，但很多讨论是临时的、需要即时反馈的。Chatto 开源免费，自托管很符合开源精神。

小公司内部协作：不想用 SaaS 服务器的可以考虑 Chatto。欧洲基础设施对 GDPR 友好。

朋友群组：几个人搞个自托管服务器，聊天数据完全自己掌控，比用第三方 APP 舒心。

还没实现的功能

现在 Chatto 是 0.4 版本，作者自己说生产环境用没问题，但还有一些功能没实现：

• 内容举报和管理工具（内容审核）
• 客户端多服务器功能的细节优化
• 移动端客户端（目前只有 Web）

看了一下 Roadmap，0.5 的重点就是安全和内容审核，还有客户端优化。作者预计 6-12 个月到 1.0。

这期间可能会有 breaking changes，所以要准备好随时更新。

社区和生态

一个开源项目能不能活下去，社区很重要。Chatto 这点做得还行，但也只是还行。

当前状态

GitHub 仓库现在有 200+ star，不算多也不算少。对于一个刚开源的项目，这个数据正常。

但 Issues 和 Pull Request 都不多。大部分是文档问题和 Bug 报告，feature 提议较少。

这可能意味着：

1. 用户基数还小
2. 现有功能够用，没太多新需求
3. 开发者还没有形成贡献习惯

文档质量

文档写的不错，"Getting Started Guide" 很清晰，部署步骤一步步跟着做就行。

但缺少进阶文档。比如：

• 如何配置反向代理（Nginx/Caddy）
• 如何配置 SSL 证书
• 如何做高可用部署
• 如何监控日志

这些都需要你自己查或者摸索。对于非运维背景的开发者，门槛有点高。

第三方集成

现在没有官方的第三方集成。但你大概能自己搞 —— Chatto 的 API 是 RESTful 的，可以写个脚本集成到 CI/CD 系统里，比如构建失败时在频道里发通知。

我没有写官方集成的计划，但社区有人可能会做。如果需求多了，作者可能也会考虑。

商业模式

Chatto Cloud 是唯一的商业模式 —— 付费托管。没有企业版，没有支持订阅。

这个思路挺好，简单透明。但长期来看，靠托管费能不能养活开发团队？这是个问题。

开源项目的钱不好赚。如果你觉得 Chatto 好，又不想自己托管，考虑用 Chatto Cloud 吧。算是给作者打赏，支持项目继续发展。

常见问题 FAQ

Q: Chatto 支持图片和文件上传吗？

A: 支持。可以上传图片、PDF、代码文件等。文件存在服务器的 .chatto/uploads 目录，数据库里存引用。

目前没有文件大小限制，但 SQLite 存文件毕竟不是最佳方案。未来可能会支持对象存储（S3、MinIO）。

Q: 可以导出聊天记录吗？

A: 官方的 chatto export 命令还没实现。但现在可以手动导出数据库文件（.chatto/data 目录），用 SQLite 客户端查看。

如果你熟悉 SQL，可以直接查 messages 表导出。但这个方案不适合非技术人员。

Q: 支持聊天搜索吗？

A: 支持。频道右上角有搜索框，可以搜历史消息。我测试了一下，搜索速度还行。

但搜索功能比较基础，没有高级语法（比如 AND/OR、时间范围过滤）。如果你经常需要搜几个月前的消息，可能有点慢。

Q: 支持消息编辑和删除吗？

A: 可以删除自己的消息，但只能删除最近的 5 分钟内的。这是为了防止滥用 —— 有人发完消息后修改成误导性的内容。

编辑消息目前不支持。如果你想改消息，只能删了重发。

Q: 可以在多个设备同时登录吗？

A: 可以。你可以在电脑、手机、平板上同时登录，消息会同步。

但要注意，Chatto 没有类似 Telegram 的"最近活跃设备"列表。如果你不记得在哪些设备登录过，没法远程退出。

Q: 支持消息已读回执吗？

A: 不支持。你不能知道别人读了你的消息没有。

这个是有意的设计，减少"读了不回"的社交压力。如果你需要已读状态，可能要等后续版本。

Q: 服务器宕机了怎么办？

A: 恢复很简单。重启 Chatto 进程就行，数据在 SQLite 里，不会丢。

但如果服务器挂了（比如硬盘坏了），数据就没了。所以定期备份很重要。

我的建议

如果你在考虑用 Chatto，我有几个建议：

适合用的场景

• 5-20 人的小团队或社区
• 有运维基础的开发者
• 对数据隐私有要求的场景
• 预算有限，不想付 SaaS 费用

不太适合的场景

• 大型企业（几百人）
• 需要深度定制的企业
• 完全不想碰运维的团队
• 需要丰富插件和集成的场景

部署建议

1. 定期备份数据库和上传文件
2. 配置 SSL 证书，用 HTTPS 访问
3. 用 systemd 或 supervisord 管理进程，崩溃自动重启
4. 监控资源占用，超出预期及时扩容
5. 如果是公网访问，考虑配置防火墙限制访问 IP

等待 1.0 的理由

如果你现在不需要急用，可以等 Chatto 到 1.0 再上生产。

1.0 意味着：

• API 稳定，不用担心 breaking changes
• 核心功能完善，比如内容审核
• 移动端客户端可能已经发布
• 更多的社区贡献和第三方集成

当然，0.4 现在已经能用了。如果你不怕偶尔更新版本，直接用也无妨。

折腾了一圈，我觉得 Chatto 挺有意思。

它没试图做一个"大一统"的协作平台，就专注做好一件事 —— 群聊。轻量、快、隐私保护，这三个点做到位了。

简单说就是"能用"，而且"好用"。

我计划在个人的小服务器上长期跑一个 Chatto 实例，给几个朋友和开源项目协作用。如果效果好，后面可能会给团队内部也推一下。

开源的东西，最重要的是有人用、有人反馈。Chatto 这个方向是对的 —— 先把核心功能做扎实，再慢慢扩展。

如果你也在找一个轻量、自托管的群聊工具，不妨试试 Chatto。至少 Homebrew 装一下，跑起来看看，几秒钟的事。

安装方法汇总

macOS

brew install chattocorp/tap/chatto

chatto init

chatto run

Linux (x86_64)

wget https://github.com/chattocorp/chatto/releases/download/v0.4.0/chatto-linux-x86_64

chmod +x chatto-linux-x86_64

./chatto-linux-x86_64 init

./chatto-linux-x86_64 run

Linux (ARM64)

wget https://github.com/chattocorp/chatto/releases/download/v0.4.0/chatto-linux-arm64

chmod +x chatto-linux-arm64

./chatto-linux-arm64 init

./chatto-linux-arm64 run

Windows

从 GitHub Releases 下载 .exe 文件，直接运行即可。

详细的部署文档在 docs.chatto.run，建议先看一遍官方文档再动手。

有啥问题可以去 Chatto HQ 社区 找 #self-hosting 频道问，那里有开发者和其他用户在。

生产环境部署

如果你想在生产环境长期跑 Chatto，光 chatto run 是不够的。这里给一个完整的部署方案。

systemd 配置

创建 /etc/systemd/system/chatto.service：

[Unit]

Description=Chatto Chat Server

After=network.target

[Service]

Type=simple

User=chatto

WorkingDirectory=/home/chatto

ExecStart=/home/chatto/chatto-linux-x86_64 run

Restart=always

RestartSec=10

StandardOutput=journal

StandardError=journal

[Install]

WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload

sudo systemctl enable chatto

sudo systemctl start chatto

sudo systemctl status chatto

这样 Chatto 进程崩溃会自动重启。

Nginx 反向代理

配置 Nginx 做反向代理和 HTTPS：

server {

    listen 80;

    server_name chat.yourdomain.com;

    return 301 https://$server_name$request_uri;

}

server {

    listen 443 ssl http2;

    server_name chat.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/chat.yourdomain.com/fullchain.pem;

    ssl_certificate_key /etc/letsencrypt/live/chat.yourdomain.com/privkey.pem;

    location / {

        proxy_pass http://127.0.0.1:3000;

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

        proxy_set_header Host $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 $scheme;

    }

}

自动备份

写个备份脚本 /home/chatto/backup.sh：

#!/bin/bash

DATE=$(date +%Y%m%d_%H%M%S)

BACKUP_DIR="/home/chatto/backups"

DATA_DIR="/home/chatto/.chatto/data"

mkdir -p "$BACKUP_DIR"

# 停止服务

systemctl stop chatto

# 备份数据

tar -czf "$BACKUP_DIR/chatto_backup_$DATE.tar.gz" -C "$DATA_DIR" .

# 重启服务

systemctl start chatto

# 删除 7 天前的备份

find "$BACKUP_DIR" -name "chatto_backup_*.tar.gz" -mtime +7 -delete

echo "Backup completed: chatto_backup_$DATE.tar.gz"

加到 crontab 每天凌晨 2 点跑：

0 2 * * * /home/chatto/backup.sh >> /home/chatto/backup.log 2>&1

监控

可以用一个简单的监控脚本检查 Chatto 是否活着：

#!/bin/bash

curl -f http://localhost:3000/health || systemctl restart chatto

或者用 Prometheus + Grafana 更高级的监控方案。

性能优化

如果发现性能不够，可以考虑：

1. 换用 PostgreSQL：SQLite 的并发能力有限。Chatto 后续版本可能支持 PostgreSQL。
2. 升级服务器配置：更多 CPU 和 RAM。
3. 负载均衡：多个 Chatto 实例前面加 Nginx 负载均衡。但要注意 SQLite 不适合多实例写，如果真要搞负载均衡，得用 PostgreSQL。

但大部分情况下，单个 Chatto 实例就够用了。

• 本文写于 2026 年 7 月 9 日，基于 Chatto 0.4.0 版本。开源项目迭代快，实际使用前建议检查最新文档。*