自架團隊聊天這條路，過去幾年幾乎只有兩個選項：Mattermost 或 Rocket.Chat。前者是 Go 寫的、拖著 PostgreSQL 跟建議掛 Elasticsearch 做搜尋；後者是 Meteor 加 MongoDB，記憶體吃到讓小型 VPS 直接歇菜。2026 年 7 月 8 日，Chatto 這個原本閉源的商業產品把整個 codebase 轉成 AGPL-3.0-or-later 授權開源，把單一 Go binary、內嵌 NATS、預設 SQLite 這條路徑跑通——第一次讓一個十幾人的小團隊在 2 GB RAM 的 VPS 上跑內部聊天變成一件不用配 DBA 的事情。
Chatto 的定位很明確：不做企業級的功能堆疊、不做聯邦、也不跟 Matrix 生態競爭，只解決「一個團隊需要一個私有的、能語音視訊、能 SSO、能自己備份」這個場景。這種收斂讓它的架構決策跟 Mattermost、Rocket.Chat 有本質差別，值得把技術細節攤開來對照。
舊有自架聊天在小團隊卡住的地方
Mattermost 的官方部署文件建議在生產環境跑 PostgreSQL 14+ 加上獨立的 Elasticsearch 節點做全文搜尋。實務上一個十人團隊要上正式環境，最少要三隻服務——mattermost-server、postgres、elasticsearch——加上反向代理跟備份腳本。RAM 用量在 4 GB 起跳，其中 Elasticsearch 一個就吃 2 GB。這對已經有 Kubernetes 或 Nomad 的團隊不算問題，對只有一臺 VPS 的小團隊就是一個要另外派人顧的東西。
Rocket.Chat 的問題方向不同但一樣痛。Meteor 框架跟 MongoDB 的組合讓它的資源消耗跟訊息數量成正比——訊息破十萬則之後 mongod 常態吃 3 GB RAM，Node.js worker 再吃 1.5 GB。運維成本落在 MongoDB 的備份、副本集設定、oplog 監控這一整套外部知識。想搜尋歷史訊息還要另外開 Rocket.Chat 的 Elasticsearch 整合。
第三條路是 Matrix Synapse，但 Synapse 的定位是聯邦通訊協定的參考實作，不是給單一團隊用的產品。設定檔的複雜度、資料庫成長速度、跟外部 homeserver 的信任模型，都不是小團隊會想碰的東西。想要「就是一個給公司內部用的 Slack」，Matrix 是明顯過度設計。
這三個選項的共通點是把「自架聊天」跟「維運多個相依服務」綁在一起。Chatto 的技術選型直接把這個綁定拆開。
一支 binary 跟嵌入式資料庫的取捨
Chatto 用 Go 寫後端、Svelte 寫前端，兩邊在 build 階段合成一個執行檔。前端資源直接 embed 進 binary，跑起來只要一個 process、聽一個 port、寫一個 SQLite 檔就能開始收訊息。原始 docker-compose 檔可選，但在 10 人以下的使用場景，直接 ./chatto 就是完整的部署。
SQLite 當主要儲存這件事在 2026 年已經不像五年前那麼有爭議。litestream、rqlite、Turso 這幾年把 SQLite 的高可用性跟遠端備份補齊；WAL 模式加上正確的 fsync 策略，寫入吞吐量在單機情境對聊天訊息量級來說綽綽有餘。Chatto 走這條路就是明確地說「不打算做橫向擴充」——需要多節點的公司，本來就會選 Mattermost 或商業版。
即時訊息推送靠的是內建的 NATS runtime。NATS 是 CNCF 的訊息佇列，Go 生態裡拿來做 pub/sub 幾乎是預設選擇。Chatto 把 nats-server 用 library 模式引進來，跑在同一個 process 裡面——訊息事件在寫入 SQLite 之後，透過 NATS 廣播到所有連線的 WebSocket 客戶端。整條路徑沒有外部依賴，也不需要另外設定 Redis 或 RabbitMQ 這種訊息中介層。
這種嵌入式架構的代價是水平擴充路徑不存在。Chatto 明講不支援叢集——想在多節點跑就是走 Chatto Cloud 或等未來的商業授權。對只想解決自己團隊需求的使用者，這個取捨反而是好事：少一個維度的設定、少一個可能出錯的地方。
LiveKit 內建把語音視訊從加購項目變成預設值
Mattermost 的語音通話在社群版是外掛，功能只到 1 對 1；要多人會議要買企業版，或自己接 Jitsi。Rocket.Chat 用 Jitsi Meet 做視訊，設定路徑很長。Chatto 的做法是把 LiveKit 這個開源的 WebRTC SFU 直接包進來——啟動 chatto 的時候，LiveKit server 也一起起來，端到端加密的多人語音視訊跟螢幕分享預設就能用。
LiveKit 是 2021 年開源的 SFU（Selective Forwarding Unit），現在被 OpenAI 的 Realtime API 拿來當底層傳輸。它跟自己接 Jitsi 相比有幾個實際差別：內建的媒體伺服器不需要另外開 UDP port range 給 mediasoup、認證機制用 JWT 而不是每次要打 REST API 建 room、client SDK 有官方的 WebRTC 抽象層。Chatto 把 LiveKit 收在自己的認證體系底下，使用者不需要知道底層是 LiveKit，通話按鈕按下去就通了。
技術上的取捨是 LiveKit 的 SFU 對頻寬敏感——十人視訊會議在伺服器端要處理十路上傳、每個參與者收九路下載。臺灣的 VPS 頻寬情境下這通常不是問題（1 Gbps 對外的方案已經常態），但要注意 CPU——SFU 雖然不轉碼，加密解密還是要吃 CPU 週期。八核 Intel Gold 級別的 VPS 撐十人視訊會議沒問題，兩核的入門方案就要保守估計。
每個使用者一組金鑰跟刪帳號 crypto-shredding
Chatto 對加密的處理方式跟大部分自架聊天不同。訊息跟個人資料在儲存前用該使用者的金鑰加密，金鑰本身用主金鑰加密後存進 SQLite；帳號刪除的時候不是清 row，而是把該使用者的金鑰銷毀，剩下的密文變成不可讀的隨機資料。這個技巧叫 crypto-shredding，好處是不需要遍歷所有資料表去清理該使用者的痕跡——備份檔裡的舊資料也一樣變成無效密文。
值得注意的是這種靜態加密跟端到端加密不是同一件事。伺服器需要能讀取訊息內容來做搜尋、通知、外部 webhook，所以主金鑰必須存在伺服器上。這個模型防的是磁碟被人拿走、備份外流、資料庫被 dump 這類威脅場景。真正的端到端加密只發生在 LiveKit 的語音視訊層——那部分金鑰真的只在客戶端之間交換，伺服器只轉封包。
這種設計對 GDPR 或個資法規範下的資料刪除義務有實際價值——「已刪除的帳號連備份都讀不出來」比「已從資料庫刪除但七天備份還有」在法遵層面乾淨很多。歐洲託管的商業使用者是 Chatto 主打的族群，這個設計不是巧合。
AGPL-3.0 授權跟版本現實
Chatto 的授權是 AGPL-3.0-or-later，前端跟 SDK 有 Apache-2.0 例外條款。AGPL 對純內部使用沒有實質影響——公司內部部署不對外提供服務，就沒有觸發原始碼公開義務。要注意的是把 Chatto 改造之後對外提供的 SaaS 服務，會被 AGPL 條款要求公開修改後的原始碼。這對 99% 的自架情境不是問題，但如果打算基於 Chatto 做二次商業化，要先跟 Chatto Cloud 那邊談雙授權。
版本方面 0.4 是開源時的版本，作者明確標示「production-ready 但可能有 breaking change」直到 1.0 之前。1.0 預計在開源後 6 到 12 個月釋出，這中間升級要看 changelog。0.5 版的重點是內容檢舉跟審核功能——這對開放註冊的社群比較重要，內部團隊聊天用不太到。
實務上建議的部署節奏是：0.x 階段先用在非任務關鍵的內部溝通、備份週期縮短到每日、升級前先在測試環境跑一次。等 1.0 出來、認證跟權限模型定型之後，再考慮把主要的公司溝通遷移過去。
什麼團隊該試、什麼團隊該等
Chatto 適合的場景很具體：5 到 30 人的技術團隊、只需要一個內部聊天工具、想避免把 SSO 跟語音視訊擋在企業版付費牆後面、有能力自己顧一臺 VPS 但沒有專門的維運。這個組合在 Slack 每月每人 7.25 美元的成本結構下，一年可以省下五位數美金。臺灣的中小型軟體公司跟開源社群，這個規格區間人不少。
該等的情境也很明確：需要跟客戶或外部合作單位共用 workspace（Chatto 沒有 guest access 這種細緻的權限模型）、公司規模超過 50 人要考慮橫向擴充、有已經在用的 Slack Enterprise Grid 訂閱要遷移（Chatto 沒有訊息匯入工具）、需要跟 Zapier 或 Slack marketplace 深度整合。這幾種情況 Mattermost Enterprise 或直接留在 Slack 反而合理。
技術上還有一個等待點是 Kubernetes 支援。目前 Chatto 的 K8s 部署狀態在文件裡標示為 experimental——嵌入式 NATS 跟 SQLite 這種架構在 stateful set 上跑得起來，但 rolling update 的行為還沒完全定義好。用 Docker Compose 或裸機部署是目前比較穩的路徑。
自架團隊聊天要跑得穩，底下那臺 VPS 才是關鍵。Chatto 的資源用量跟 Mattermost 相比低了一個量級，但 SQLite 的寫入效能跟 LiveKit 的 CPU 消耗直接看的是磁碟 IOPS 跟 CPU 世代。NCSE Network 的 VPS 服務用臺灣是方電訊機房、Intel Gold CPU 加 NVMe SSD，跑一個內部團隊 Chatto 加上未來加開的其他自架服務綽綽有餘，方案細節可以到 ncse.tw 了解。
