當機房裡的 VPS 從一臺長到五臺、十臺，每臺都裝一份 Portainer 並單獨登入維護的做法很快就會失控。映像版本不同步、compose 檔散落在不同主機、改個環境變數要登進去三次 SSH——這套模式在單機時代沒問題，多機之後幾乎是必然的負債。Komodo 鎖定的就是這個尺寸的痛點：它不打算取代 Kubernetes，也不想當成 Heroku 來用，而是把多臺獨立 Docker 主機收回一個控制平面。
Komodo 由 moghtech 用 Rust 與 TypeScript 寫成，2026 年 3 月推出 2.0，5 月已經更新到 2.2。架構上分成 Core 與 Periphery 兩支 binary：Core 是中央伺服器，提供 Web UI、API 與資料庫；Periphery 是裝在每一臺受控主機上的輕量代理，負責執行 Docker 指令、收集 metrics、回傳 log。兩者透過雙向 WebSocket 通訊，因此 Core 不一定要直接連得到 Periphery——位於 NAT 後面的主機可以反向打回 Core。
為什麼一臺機器一臺 Portainer 不再划算
Portainer 與 Komodo 的差別常被簡化為「單機」對「多機」，但真正的關鍵其實在抽象層級。Portainer 的世界裡，主要單位是 container 與 stack，操作邏輯接近 Docker CLI 的 GUI 版；想跨主機部署，要嘛升級到 Business 版的 Edge Agent，要嘛接 Swarm。對於只想集中管理散落在三家機房十臺 VPS 的小團隊，這個門檻並不低。
Komodo 把「Server」當作頂層資源，每一臺裝了 Periphery 的機器都是平等的目標。部署一份 compose stack 時，使用者選擇要部署到哪幾臺主機、是同步推還是輪流推、要不要綁定 Git 倉庫做自動更新。當需求是「同一份 stack 在三個地理位置各跑一份」或「dev 環境推到 A 機、prod 推到 B 機」這種典型場景，Komodo 的工作流明顯順手。
另一個被低估的差別是 GitOps。Komodo 的 Stack 可以直接綁定 Git 倉庫的 compose.yaml 路徑，搭配 webhook 達成 push 即部署。Portainer 也能做到，但 Komodo 的版本對齊與輪流更新策略內建得更完整，rollback 也直接以 Git commit hash 為基準。
Core 與 Periphery 的職責分工
Core 是有狀態的：MongoDB 存所有資源定義、操作記錄、使用者權限。Periphery 則完全 stateless，重新安裝後只要重新加入就會恢復原狀態。這個設計讓災難復原相對簡單——備份 Core 的資料庫就足以重建整個控制平面，Periphery 端唯一要還原的是受控主機上的 Docker volumes。
通訊層用的是 bidirectional WebSocket。Core 與 Periphery 之間誰先發起連線都可以，這讓三類部署形態都能成立：Core 在公網、Periphery 在 NAT 後（Periphery 主動連 Core）；Core 在內網、Periphery 在公網 VPS（Core 主動連 Periphery）；甚至 Core 跟 Periphery 都在 WireGuard 網路上。對於同時管理本地實體機與遠端 VPS 的環境，這種拓樸自由度很實用。
Periphery 預設用 systemd 安裝，整支 binary 含設定檔不到 30 MB，跑起來常駐記憶體大約落在 40 MB 上下。也可以打成 Docker 容器丟到 host network 模式跑，但這種裝法每次升級要重啟容器，對連線敏感的場景反而不如直接 systemd。
v2 把 passkey 換成 PKI 解決了什麼
1.x 時代 Core 與 Periphery 之間靠一組共享 passkey 認證。聽起來簡單，實務上很糟糕：passkey 寫在 Periphery 的設定檔裡，一旦某臺主機被入侵，整個叢集的 passkey 都得手動換過一輪；新增主機要先在 Core 設定再複製貼上到 Periphery；多人團隊裡這把 key 等於管理員密碼。
v2 把整套機制換成 Ed25519 金鑰對。Core 跟 Periphery 各自生成自己的私鑰，只交換公鑰——把新機器加進來時 Core 產生一次性的 onboarding key，Periphery 用這把 key 完成首次握手後立刻自己生成永久金鑰對。後續流程內建自動輪替，整個過程不需要管理員手動接觸任何密鑰檔。
對於把 Komodo 從 1.x 升上來的使用者，這次轉換不是 drop-in：要重跑 Periphery 安裝腳本、在 Core 重新接入每一臺主機。但只要走完一次，整個 fleet 的認證體質就完全不同——這也是 2026 年才認真評估 Komodo 的人值得直接從 v2 入手的原因。
Stack、Build、Procedure 三層抽象
實際操作 Komodo 會遇到三個比 Portainer 更上層的概念。
Stack 是 Komodo 對 Docker Compose 專案的封裝。一個 Stack 對應一份 compose.yaml，可以從 Git 倉庫、本地檔案、或直接在 Web UI 編輯。部署目標可以是單一 Server，也可以是 Swarm。Stack 內建版本快照，回滾到上一版只是點兩下。
Build 對應 Docker 映像建置。Komodo 可以指定任意一臺 Periphery 主機當 build runner，從 Git 拉原始碼、build image、推到 registry。這對「不想用 GitHub Actions 跑 build、又懶得自己寫 Drone」的場景剛好填空——而且 build runner 跟正式環境隔離，不會吃掉服務主機的 CPU。
Procedure 是把多個動作串成順序執行的小型工作流。例如「先 build 新 image、再推到 staging、跑健康檢查、最後推到 prod」這種日常流程，可以包成一個 Procedure 設排程或手動觸發。它沒有 Argo Workflows 那種完整的 DAG，但對中小團隊的部署需求已經很夠用。
跟 Coolify、Dokploy 怎麼選
三者表面看都是「自架 PaaS」風味的工具，但定位差很多。
Coolify 走的是 Heroku 路線：使用者貼一個 Git 連結，工具自動偵測語言、自動 build、自動跑。它把整套 PaaS 的便利搬到自家伺服器，代價是黑盒比較多、走錯路時除錯麻煩。對「一個 Node.js 專案、一臺 4 GB VPS、想十分鐘上線」的需求最合適。
Dokploy 比 Coolify 更輕，定位也比較單純：給開發者一個自家版的 Vercel，主打 Compose 部署與 Traefik 自動路由。它沒有 Komodo 的多機編排能力，但對單機環境部署多個小服務的場景相當俐落。
Komodo 則明顯偏 ops 側。它不會幫使用者自動偵測語言、自動寫 Dockerfile，使用者必須自己準備好 compose.yaml 與映像。換來的是對部署過程的完整掌握權——當需要在十臺 VPS 上維持一致的服務狀態、需要審計每一次變更、需要分權給不同團隊操作不同 Server 時，Komodo 的設計才會展現它的價值。
簡單的選擇邏輯：單機跑幾個個人專案選 Dokploy；想要 Heroku 體驗、不在意黑盒選 Coolify；機房或機櫃裡有多臺 VPS 需要統一治理選 Komodo。
權限、告警與審計
Komodo 的 RBAC 設計接近 Kubernetes：每個 Resource（Server、Stack、Build、Procedure）可以個別設權限，使用者可以是 Read、Execute、Write 三級。User Group 則用來打包權限，例如「Web 團隊」對所有前端 Stack 有 Write、對資料庫 Server 只有 Read。
告警走 webhook：CPU、記憶體、磁碟、容器存活、Stack 部署失敗都能觸發。對接 Slack、Discord、Telegram、Mattermost 都有官方範本。對已經跑 Beszel 之類的監控的使用者來說，Komodo 的告警可以只負責部署相關事件，避免跟既有系統重複。
審計記錄是另一個值得留意的點。每次部署、每次配置變更、每個使用者登入都會落地到 Core 的資料庫，並且可以按 Resource 查詢歷史。對於要對客戶交差「誰、何時、改了什麼」的場合，這個內建功能省下另外接 Loki 的工夫。
給臺灣自架使用者的實際建議
Komodo 適合的尺寸大約是「三到三十臺 VPS、不到一個 Kubernetes 叢集」的中間地帶。再小就用 Dokploy 或 Coolify、再大就直上 K3s 或 Talos Linux。它對主機規格的需求不高——Core 配 2 vCPU、4 GB RAM 就跑得動，Periphery 端只佔幾十 MB。
實際部署時建議把 Core 放在一臺穩定低負載的 VPS 上，最好跟受控主機分開機房，避免單點故障時連控制平面一起斷。資料庫備份也要設好排程——Komodo 的所有狀態都在 MongoDB，建議用 mongodump 排程加異地備份，搭配 Restic 推到 S3 是常見的搭法。
NCSE Network 提供的臺灣機房 VPS 採用 Intel Gold CPU 與 NVMe SSD，正好適合做為 Komodo Core 與 Periphery 節點的底層——低延遲的內網互連讓 Periphery 回傳 metrics 不會卡，NVMe 也讓 MongoDB 寫入夠快。若有興趣把現有的多機 Docker 環境收進統一管理介面，可以到 ncse.tw 了解 VPS 方案與技術諮詢服務。
