Ech0 是什麼？把想法發布成一條自架時間軸的開源微網誌

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Ech0 是一套以 Go 撰寫、AGPL-3.0 授權的自架個人發布平台。它做的事情很明確：讓你在一個乾淨的介面寫下短文、連結、媒體，然後把這些內容排成一條公開的時間軸，別人可以訂閱 RSS、留言、追蹤更新。資料放在你自己的伺服器，預設用 SQLite 一個檔案管理。

很多人會把它和 Memos 歸在同一類，畢竟兩者都是自架、都強調輕量、都圍繞短內容。Ech0 的維護者在 README 裡親自畫出了那條線：Memos 擅長快速記下念頭，Ech0 處理的是下一步，把那些念頭發布成一條別人能追蹤、能互動的時間軸。一句話分野是「擷取」對上「發布」。如果你要的是一個只有自己看的筆記盒，Memos 仍然更合適；如果你要的是一個掛在自己網域、有 RSS、有留言、能被追蹤的個人動態牆，Ech0 才是它想解的問題。

Pin

它靠什麼運作：圍繞時間軸的單檔架構

Ech0 的技術選型有幾個會直接影響使用體驗的決定。

整個站的核心資料落在 SQLite 一個檔案裡，媒體檔案走它自稱的 VireFS 統一儲存層，可以掛本地磁碟，也可以接任何 S3 相容的物件儲存（MinIO、R2、AWS S3 都行）。備份不用牽涉資料庫叢集，把那個檔案和媒體目錄 copy 走就完成大半。從 v5.4.4 起 SQLite 改跑 WAL 模式，讀寫不再互相阻塞，這對單機部署的順暢度是實質改善。

S3 儲存的配置細節也值得提一下。Ech0 在設定面板裡把常見供應商做成預設：AWS、MinIO、Cloudflare R2 各自帶對應的定址方式，另外有一個 Other 類別接任意 S3 相容服務。v5.4.5 加入了 path-style 定址開關，解決了自架的 Ceph、Garage、SeaweedFS 這類只走 path-style 的服務連不上的問題；v5.4.6 又修正了騰訊 COS、阿里雲 OSS 這種只吃 virtual-hosted 定址的服務，上傳成功但圖片顯示不出來的 bug。如果你的儲存後端是這些華語圈常見的物件儲存，建議直接升到 v5.5.0 再開始用，省得踩定址坑。

備份這一塊除了把資料目錄整個 copy 走，Ech0 也提供面板裡的快照匯出。從 v5.4.4 起，快照用的是 SQLite 的 VACUUM INTO 線上備份，會產出一份一致的資料庫副本，而不是直接複製 live 檔案。這代表即使在有寫入的同時做快照，也不會抓到寫到一半的損壞資料。快照、排程備份、手動下載三條路都走同一個機制，失敗會直接報錯而不是默默存一份壞檔。

編輯器是 markdown-it，支援即時預覽與插件擴充。發布出來的內容可以是純文字短文，也可以是帶圖片、YouTube 或 Bilibili 影片、GitHub 專案卡片的富媒體動態，整體閱讀體驗接近一條社群動態牆，而不是傳統長篇部落格。

身分與權限走三層角色：第一個註冊的帳號自動成為 Owner，之後可以再有 Admin 和一般使用者，發布權限預設只開給特權帳號。登入方式除了帳密，還支援 OAuth2、OIDC 第三方登入，以及 Passkey 生物辨識或硬體金鑰。需要把 Ech0 接進自動化流程的人，可以在面板的 Access Token 管理產生帶範圍限制的權杖，例如只給 comment:write 範圍的 token，搭配專用的整合留言端點，就能讓外部程式在不碰主帳密的前提下發留言。官方也明說這類未授權的第三方整合不在支援範圍內，出事要自負，所以接外部服務前先把權杖範圍限到最小是基本動作。

Capsule 格式：把整站帶走的退場方案

很多自架平台最現實的風險，是哪天你不想再維護了，內容卻拿不出來。一時連不上線通常重開就好，棄維才是真正會丟東西的關頭。Ech0 在 2026 年 8 月 2 日釋出的 v5.5.0 加入了 Capsule 格式，這是它目前最值得看清的功能。

Capsule 把你整站匯出成一個資料夾：每篇貼文是一個帶 frontmatter 的 markdown 檔，留言集中在 comments.yaml，站點資訊寫進 ech0.yaml，所有媒體檔案連同 S3 上的圖都拉下來放成原始檔。匯出是冪等的，重複匯入同一份 Capsule 不會產生重複資料，也不會覆蓋你已經有的內容。

更有意思的是 ech0 build 指令。它可以把一份 Capsule 編譯成一個靜態唯讀網站，直接丟上 GitHub Pages 或 Cloudflare Pages 就能留存。也就是說，就算你決定不再跑 Ech0 伺服器，你的時間軸還是能以一個靜態站的形式活著，繼續被讀到。靜態站會沿用 Ech0 前端的介面，按讚和留言以凍結的唯讀狀態顯示，不需要 Node 或 pnpm 環境，素材全部嵌進二進位檔裡。對重視資料主權的人來說，這是一條設想過的退場路徑，而不是把內容綁死在運行中的實例上。

Capsule 和快照的分工也設計得清楚。快照是完整備份，包含帳號和憑證，是唯一能拿來做災難復原的格式；Capsule 只帶內容和媒體，沒有帳號資訊，不能拿來還原整站，但正因如此它適合拿來分享、搬移或做成靜態站。兩種格式的產物放在不同目錄，互不覆蓋，Capsule 也被排除在快照之外，避免備份吃掉自己。

聯邦能力要看清楚：是 Ech0 之間互通，不是 ActivityPub

網路上不少介紹文章把 Ech0 描述成一套基於 ActivityPub 協議、能和 Mastodon 或 Misskey 互聯的聯邦宇宙平台。這個說法需要校正。

Ech0 官方倉庫的 federation 文件顯示，它的跨站能力來自兩個自有機制。第一個是 Connect，你在系統設定裡填入對方 Ech0 實例的根地址，兩個 Ech0 站就連起來了。對方實例必須也是 Ech0，填一個 Mastodon 或 Misskey 的地址進去是連不通的。第二個是 Hub，路徑在 /hub，它會根據你 Connect 列表裡的實例，去各站拉取公開貼文，按時間合併成一條聚合時間軸。如果某個實例暫時連不上，Hub 會跳過它只顯示連得上的站，不會讓整條時間軸卡住。

整份官方文件從頭到尾沒有提到 ActivityPub、Mastodon 或 Misskey。倉庫的 topics 標籤有 self-hosted、microblog、social-network，但沒有 activitypub 或 federation。換句話說，Ech0 的聯邦是封閉在同產品之間的，它不能讓你直接被 Mastodon 帳號追蹤，也不能把你的貼文投進 Fediverse 的跨協議網路。

Pin

如果你挑 Ech0 是因為想加入 ActivityPub 聯邦生態，這一點會是期待落差。反過來說，如果你要的只是把幾個朋友或自己的 Ech0 站串在一起看，Connect 加 Hub 的設計簡單直接，不需要處理 ActivityPub 的複雜度。

內建 MCP Server：讓 AI 工具直接操作你的時間軸

Ech0 另一個比較少被討論的特點是內建了 MCP（Model Context Protocol）伺服器。MCP 是一套讓 AI 模型與外部工具溝通的協議，最近在 AI 工具鏈裡越來越常見，例如瀏覽器自動化場景裡的 Browserwing MCP 就是用同一套協議把瀏覽器能力暴露給 AI。

Ech0 的 MCP 伺服器用 Streamable HTTP 傳輸，以 scoped JWT 做權限控制，官方說法是涵蓋近完整的核心功能，包含貼文、檔案、統計資料等。v5.4.7 又把協議版本升級到 2026 年 7 月 28 日的最新規格，這次升級是破壞性的：舊版 MCP 客戶端用的 initialize 握手流程被拿掉了，改走 server/discover，每個請求都要帶協議版本標頭，沒跟上的舊客戶端會直接收到 HTTP 400 錯誤。官方 SDK（TypeScript v2、Go v1.7 以上、Python、C# v2）已經內建處理，但如果你用的是自己刻的或較舊的 MCP 客戶端，升級前要先確認相容性。實際意義是：你可以在相容 MCP 的 AI 編輯器或自動化流程裡，直接呼叫 Ech0 的 API 來發文、取資料，不用自己包一層 REST 客戶端。

這對想把 Ech0 接進自動化工作流的人是實質便利，例如讓 AI 助理把處理結果直接發布成一條 Ech0 動態。當然，能不能派上用場取決於你有沒有在跑 MCP 相關工具，否則它就只是背景裡一個開著的端點。

怎麼部署：一行 Docker 指令起步

Ech0 的部署門檻確實很低。官方建議的 Docker 一行指令是進場的最短路徑：

docker run -d \
  --name ech0 \
  -p 6277:6277 \
  -v /opt/ech0/data:/app/data \
  -e JWT_SECRET="換成你自己的安全密鑰" \
  sn0wl1n/ech0:latest

容器跑起來後打開 http://你的伺服器IP:6277，註冊的第一個帳號就是 Owner。JWT_SECRET 一定要換成你自己的隨機長字串，這是簽發登入權杖的密鑰，留預設值等於把帳號體系的鑰匙大開。預設情況下只有特權帳號能發文，所以第一個動作是建好自己的管理帳號，再決定要不要開放給其他人。除了單一 Docker 容器，官方也提供 Docker Compose 與 Kubernetes Helm Chart，後者放在倉庫的 charts 目錄裡，適合想正式上線的人。

資料備份有三個入口：Web 面板、CLI 指令、TUI 終端介面，三條路都能做快照匯出。把對應的 data 目錄定期備份走，加上偶爾做一次 Capsule 匯出留存，資料安全的下限就抓得相當穩。如果你平常就在顧自架服務，這套流程不會讓你陌生；想找同類自架筆記或內容工具對比的話，EdgeEver 是另一個值得看看的自架筆記方案。

它不適合拿來做什麼

把限制講清楚，比把優點列滿更能幫你做決定。Ech0 的維護者在 README 直接列出了它不想解的幾類需求。

它不是雙向連結的知識庫。如果你要的是 Obsidian 那種筆記之間互相反向連結、可以畫出知識圖譜的個人知識管理工具，Ech0 沒有這個設計，它的內容單位是一條一條的動態，不是一篇一篇可交叉引用的長文。

它不是團隊協作文件空間。Notion 式的多人即時共編文件、資料庫、看板，在這裡都找不到。角色模型只有 Owner、Admin、一般使用者三層，刻意保持簡單可預測，沒有細粒度的權限矩陣。

它也不適合只想要一個純私人的備忘錄 App、完全沒有發布或時間軸需求的人。Ech0 的核心價值圍繞在把內容發布出去給別人看，如果你永遠不打算公開，很多設計對你會是多餘的。

另外要誠實提醒的是，網路上流傳的「運行佔用不到 15MB 記憶體、鏡像僅 40MB」這組數字，Ech0 官方 README 與版本更新記錄並未列出，出處不明。輕量這個方向是可信的，Go 編譯成單一二進位檔加上 SQLite 的組合本來就不會太吃資源，但具體數字建議你自己跑起來量，別直接把第三方轉述的數字當規格。

該不該用 Ech0

回到一開始的問題。Ech0 適合的人相當明確：想在自己的網域上掛一條個人公開時間軸，用 Markdown 寫短文和連結，要 RSS 訂閱和留言互動，同時希望資料完全握在手裡、隨時能帶走。如果你已經在用 Memos 但覺得「記下來」之後少了「發布出去」這一步，Ech0 補的就是那一塊。輕量自架、內建 MCP、加上 Capsule 這條退場路徑，是它和同類工具拉開距離的三個點。

挑選前要先確認兩件事。第一，它的聯邦只在 Ech0 之間生效，不要期待 Mastodon 互聯。第二，它不是筆記知識庫也不是團隊協作工具，把它當成那些用途會失望。確認過這兩點還覺得合用，一行 Docker 指令就能開始試。習慣用 Markdown 寫作的人，也可以順便看看 Markdown 轉圖片工具 或 Markdown Viewer，把寫作前後的工具鏈補齊；會用到 RSS 訂閱的讀者，RSS AIGC 這類聚合器則能幫你把 Ech0 的輸出接進日常閱讀流程。