自架服務跑一段時間之後，管理面通常會停在一個尷尬的地方：SSH 進去改 docker-compose.yml、docker compose pull && up -d、看 logs、繞回上一版，這一連串動作重複到不想再手打。Portainer 功能齊全但介面越來越像企業級產品，Dockge 輕巧卻只顧單機。Sencho 是 2026 年才穩定下來的第三個選項，v0.95 已經可用，走的是「Compose 檔案即真實來源、多節點靠外連 Agent」的路線，剛好卡在 Portainer 和 Dockge 中間那塊沒人做的地方。
Sencho 的定位不是要成為第二個 Portainer，作者在 README 裡把目標讀者寫得很直接：homelab、小型 DevOps 團隊、用 Compose 管一堆 VPS 的平台工程師。這幾類人的共通痛點都是一樣的——想要 UI，但不想把 Docker socket 開到網路上；想要多節點，但架 Kubernetes 太重；想要自動化，但不想寫一整套 Ansible。
Portainer 塞太多，Dockge 又太陽春
Portainer CE 現在的功能地圖已經延伸到 Swarm、Kubernetes、Edge Agent、Nomad 全都吃。功能多是優點也是缺點：對只想管十幾個 Compose 專案的個人或小團隊來說，介面切換、權限模型、License 頁面全都比實際要用的功能還顯眼。Portainer Business 版把不少功能鎖在付費牆後，Community 版每次版本更新都要留意有沒有哪個功能又被劃走。
Dockge 走的是完全反方向。單機、單 UI、直接對應 Compose 專案資料夾，安裝完就能用。但一旦有第二臺 VPS，Dockge 就開始難搞：官方推薦的方式是每一臺都跑一個 Dockge 實例，然後 UI 上加入多個 endpoint，這其實跟自己開多個瀏覽器分頁差不多。跨主機的動作（例如「全部拉最新版」、「全部重啟」、「一次看誰掛了」）Dockge 沒有辦法。
Sencho 選擇的路徑是把「Compose 檔案留在硬碟、UI 是薄薄一層編輯與觸發器、多節點透過驗證過的通道連線」這幾件事拆開處理。這樣的分工乍看沒什麼特別，但實作細節裡藏著幾個關鍵決定，讓它跟 Portainer、Dockge 的體驗差很多。
Pilot Agent 用外連 WebSocket 換掉暴露的 Socket
大部分多節點容器管理工具的做法都很類似：在每一臺被管理的主機上，開放 Docker Socket、或裝一個 daemon 監聽某個 port，讓主節點過來連。這件事在 homelab 或小團隊環境沒什麼問題，但一旦其中一臺 VPS 是租在別的機房、或者放在 NAT 後面，麻煩就出現了：要開 firewall port、要處理反向 tunneling、要維護一組 TLS 憑證，還得擔心 Docker socket 一旦被打進來等於整臺主機淪陷。
Sencho 的 Pilot Agent 反過來做。Agent 部署在遠端主機上，用長期 API token 主動對主節點建立單一條外連 WebSocket。所有管理指令都走這條通道下去，遠端主機完全不需要開任何 inbound port，也不用把 Docker socket 掛到任何網路介面上。實務上這對「一臺在臺灣主要機房、一臺在海外 CDN 節點、一臺在家裡 homelab」這種混合拓樸特別有價值——三邊都不用改 firewall，Pilot Agent 裝完連 token 就通了。
這個模型不是 Sencho 發明的，Tailscale/Headscale、Cloudflare Tunnel、Pangolin 都是這個思路。差別在於 Sencho 把 Agent 縮小到只做「Compose 管理」這一件事，不需要額外跑一個 mesh VPN，也不需要拉流量到第三方。走的通道就一條 WebSocket，資料面只有 Compose 檔案內容和 Docker API 呼叫結果，攻擊面窄。
檔案系統仍然是單一真實來源
用過 Portainer 的人大概都遇過一個問題：透過 Portainer 建立的 stack 存在資料庫裡，如果你直接在主機上改 Compose 檔案，Portainer 不會知道；反過來如果你直接 docker compose down 停掉某個 stack，Portainer 的 UI 還是會顯示它在跑。要救回一致性通常得手動同步，或者乾脆重建。
Sencho 一開始就決定 Compose 檔案存在主機檔案系統，UI 只是它的 editor 和觸發器。要把它跑起來時，docker-compose.yml 掛進來的路徑必須跟宿主機一致：
1 | services: |
這裡有個容易踩到的坑：/opt/docker 這個路徑，在容器內外要一模一樣。原因是 Sencho 在下 docker compose -f <path> up 的時候，<path> 是要透過主機的 Docker daemon 執行的，所以路徑必須是主機視角。這個 1:1 掛載規則寫在文件裡但很多人第一次裝會忽略。
指向 COMPOSE_DIR 之後，Sencho 會自動掃描底下每一個子資料夾當成一個 stack。已經在跑的專案不需要「匯入」，Sencho 掃到就會列出來。刪除 stack 只是把資料夾拿掉，接手權限交還給任何一個能 SSH 進去的人。這種「無鎖定」的設計跟 Dockge 一樣，是把 UI 當工具而不是當黑箱。
健康檢查沒過就退回上一個版本
Compose 使用者最頭痛的場景之一：docker compose pull && up -d 之後某個 container 啟動失敗，服務中斷，還得手動把 image tag 改回舊版。Sencho 對這個做了一個很實用的處理：atomic deployment 搭配 health-gated update。
流程是這樣。當使用者按下 deploy，Sencho 會先把目前的 Compose 檔案跟資料夾狀態存成一個快照，然後把新版本套用進去 up -d。接著它會盯著每個服務的 healthcheck（Docker 原生的 healthcheck 定義），在設定的時間內如果某個 container 一直進不到 healthy 狀態，Sencho 就自動把剛才那份快照套回去、重新拉起舊版本。整個過程完全不需要人在旁邊看。
前提是 Compose 檔案本身有寫 healthcheck。這是很多人平常懶得寫的東西，但接 Sencho 之後會發現值得補上：一個 curl 到 /healthz、或 pg_isready、或 redis-cli ping，加起來也就幾行，換來的是「更新失敗自動退回」這件事真的成立。
Monaco 編輯器本身是加分項。改 Compose 檔案的時候會直接在 UI 顯示 diff、YAML 語法錯誤即時標紅、儲存前有預覽，比 nano 或 vim 直接改 production Compose 檔安全一階。
Blueprints、快照、排程這些「加值」功能
Sencho 主要跟同類產品拉開差距的不是核心 UI，而是幾個平常自己拼會有點麻煩的功能：
Blueprints 是把一組 Compose 專案模板化的機制。舉例來說，可以定義一個「監控套件」的 Blueprint，包含 Grafana、Prometheus、Loki、加上預設的 volumes 命名和網路設定，之後在任何節點上一鍵展開。跟直接複製資料夾比，Blueprint 支援參數化（例如節點名稱、時區、資料保存天數），也支援跨節點一次部署。這對「每次開新 VPS 都要重跑一套 baseline」的場景很好用。
Snapshots 是把 Compose 檔案、.env、資料夾結構做成一個時間點快照。這不是資料備份——volumes 裡的實際資料還是要靠 restic、rustic 之類的工具處理——而是設定檔的版本控制。改壞了可以退回；換機遷移的時候直接把 snapshot 拉到新主機。搭配 Git 儲存庫使用效果更好，但 Sencho 本身不強制要用 Git。
排程 用 CRON 語法，可以指定「每週日凌晨三點 pull latest 並 restart」、「每小時檢查一次某個 stack 是不是 healthy，掛掉就重啟」。這種事以前要嘛寫成 systemd timer、要嘛丟去 Watchtower，Sencho 把它整合進 UI 之後好處是可以直接在 stack 頁面上看到「下一次自動更新在什麼時候」。
Webhooks 綁在 stack 生命週期事件上：部署成功、失敗、rollback 觸發、healthcheck 失敗。可以直接接 Discord、Slack、或者 Uptime Kuma、Kuvasz 這類監控系統，讓 Compose 層的變動不再是無聲的。
目前的限制與定位
Sencho 目前在 v0.95，還沒到 1.0，不建議直接押在關鍵生產環境。使用時要留意幾件事：
第一，資料庫是內建的 SQLite（存在 DATA_DIR 底下），單一 primary 節點，主節點掛掉整套管理面板就掛掉——被管理的容器不受影響，但要繼續操作只能 SSH。這對只有幾臺主機的環境沒差，要拿去管上百臺就會顯得單薄。
第二，Community 版的 RBAC 只有 admin 與 viewer 兩種角色，需要更細的權限切分（例如「A 團隊只能碰某幾個 stack」）要 Admiral 付費版才有。對三五個人的小團隊夠用，公司內部團隊多的話這條會擋住。
第三，跟 Kubernetes 完全無關。這是它的定位選擇——如果需求已經到要 K8s 的規模，Sencho 就不是答案，看 Talos、k3s、加 ArgoCD 才是路線。Sencho 明確畫給「還在 Compose 世界」的人。
Portainer、Dockge 跟 Sencho 三者要如何選？直接給個判斷：只管一臺主機、只想要一個能改 Compose 檔案的 UI，Dockge 最省事；要管企業級叢集、要各種認證整合、要 Kubernetes/Swarm 支援，Portainer Business 還是最完整；如果情境是 3 到 30 臺 VPS、跨機房、想要 Compose 檔案即真實來源、想要健康檢查自動 rollback、又不想把 Docker socket 攤在網路上，Sencho 是這一格目前最合適的填空。
值得先在測試環境跑一輪
Sencho 的 Docker image saelix/sencho:latest 拉下來、一份 Compose 檔、五分鐘就能開起來。第一次接觸建議先在一臺跑三、四個非關鍵 stack 的 VPS 上試，體驗一下自動掃描資料夾、Monaco 編輯器、健康檢查回滾這幾個核心功能。確認手感之後，再考慮把第二臺遠端主機用 Pilot Agent 接進來——這一步是它跟其他工具最大的差別，也是最能感受到「這套東西幫上忙」的地方。
多節點 Compose 管理的痛點，本質上是「基礎設施夠複雜、但又還沒複雜到要 Kubernetes」這一段的體驗長期沒有好答案。Sencho 不是完美解，但它把最痛的那幾件事——外連連線、原子部署、健康檢查回滾——都做進了單一個容器裡，這在同類工具中並不常見。
如果正在規劃臺灣機房 VPS 上跑 Docker Compose 的多節點架構，NCSE Network 的 VPS 服務採用是方電訊機房、Intel Gold CPU 與 NVMe SSD，適合作為主節點承載 Sencho 這類管理面板，遠端節點透過 Pilot Agent 外連即可，不需另外處理 firewall 與 socket 曝光的問題。想了解更多可以參考 ncse.tw 的服務內容。
