Watchtower 是 Docker 生態裡待了七年的老工具，功能簡單到一句話講得完——定期去 registry 抓 image digest、變了就把舊容器停掉、重新以新 image 建一個。這個模型撐起了幾十萬臺自架伺服器的日常運維，直到 2025 年 12 月 17 日 containrrr/watchtower 官方倉庫被作者親手 archive。Release notes 寫的理由很坦白：兩位主要維護者都不再重度使用 Docker，沒有動機再改，時間也不夠。
三個月後 Docker 29 出來把最低 API 版本抬到 1.44，Watchtower 這種內部還在用舊 SDK 的守護程式直接罷工。已經在自家 VPS 上跑了兩三年 Watchtower 容器自動更新的人此刻只有三條路可以走。這篇拆解這三條路真正的差別，以及在 2026 年的實際部署情境下該怎麼選。
nickfedor/watchtower 是最短的一條路，但架構沒有變
社群裡先冒出來的是 Nicholas Fedor 維護的 fork，image 名稱從 containrrr/watchtower 換成 nickfedor/watchtower，其他一切照舊。Docker Compose 檔案只要改 image 這一行，環境變數、labels、command 完全相容，遷移成本近乎為零。這位 fork 作者從 archive 那週開始接手，補上 Docker 29 API 支援、更新過期的依賴、修了幾個原本 issue tracker 積在那裡沒人碰的 bug。
作為短期的延命方案這很合理，但問題是 Watchtower 的架構本身就有幾個沒人敢動的老問題。第一是它把「拉新 image」跟「重建容器」這兩件事綁死，中間沒有健康檢查——新容器起來後如果 crash loop、如果 healthcheck 失敗，Watchtower 沒有回滾機制，只會留下一個壞掉的服務外加一封通知信。第二是它跟 Docker Compose 的關係尷尬，能認 label 但認不到 compose project 的依賴順序，重啟一批互相依賴的服務時常踩到啟動順序問題。第三是沒有 UI，全部靠環境變數跟 label 驅動，遇到 fleet 大到二三十臺的規模就開始難以管理。
對於只跑三五個容器、可以接受手動 rollback 的家用 VPS，換 fork 繼續用是務實選擇。要往上走就必須考慮真的換一套工具。
Tugtainer 把整套架構推倒重寫
Tugtainer 是開發者 Quenary 在 2025 年秋天釋出、2026 年上半年逐漸被討論起來的方案。整套用 Angular SPA 做前端、FastAPI 做後端、外加一個獨立的 Agent 元件跑在遠端主機上。單一 Docker image 把三塊塞進去、supervisord 管起來、Nginx 反向代理接前端。裝起來就是一支容器加一個 volume。
架構上最值得看的一點是後端從來不直接摸 Docker socket。所有 Docker 操作都是後端透過 HTTP 呼叫 Agent、Agent 才真正跟本機 daemon 對話。這個設計換來三件事：多主機管理天然成立，同一個 UI 可以看跨十幾臺 VPS 的容器；socket proxy 天然被支援，因為 Agent 本來就在 API 層而不是 socket 層；後端本身完全不需要 privileged，安全邊界比 Watchtower 乾淨很多。所有 backend 對 Agent 的請求都用共享 secret 做簽章，未授權的第三方連進去也叫不動 Docker。
功能面向管理員這一側 Tugtainer 有 Watchtower 沒有的東西。網頁上列出所有容器、每個容器目前跑的 tag 跟 digest、registry 上最新的 digest、是否有更新可用、是否設定自動更新、屬於哪個 compose project。更新可以逐容器 opt-in 也可以整批排程，cron 表達式直接寫進 UI。真正處理更新時 Tugtainer 會讀 compose 的 depends_on 跟自訂 label，解出拓撲排序才決定重啟順序，不會踩到 Watchtower 常見的依賴翻車問題。
要注意的是 Tugtainer 還很年輕，兩個近期 CVE 都跟權限有關——CVE-2025-69201 打在 Agent 的 command execution endpoint、CVE-2026-23846 打在密碼傳輸。都在小版本修掉了，但這種年輕度反映在整個專案的成熟度上：文件不完整、部分 feature 還在打磨，正式 production 環境用之前要有讀原始碼 debug 的心理準備。
freshdock 走另外一條路：只做更新，但做到有 rollback
freshdock 是開發者 Turbootzz 的專案，2026 年上半年在 self-hosted 社群開始有聲量。跟 Tugtainer 走完全相反的方向——沒有 Web UI、沒有 Agent、沒有多主機管理。就一支 Rust 寫的單一 binary，功能只做一件事：定期檢查 image 有沒有更新、有的話就更新，過程中做健康檢查、失敗就自動回滾。
回滾這件事在自動更新的世界裡意外重要。多數容器一升就壞的情境並不罕見——上游把 config schema 換掉、image entrypoint 改行為、依賴的 sidecar 版本沒同步升——這些都會讓看起來成功的 docker pull 加 docker compose up -d 換來一個實際 crash loop 的服務。freshdock 的處理方式是先把舊容器改名保留、拉新 image 起新容器、等 Docker healthcheck 通過（沒 healthcheck 的話等一段可設定的 grace period），確認活著才把舊容器真正刪掉；失敗的話反過來把新容器停掉、把舊容器重新啟動、發通知說出了什麼事。
freshdock 從 v1.4 開始能直接讀 Watchtower 的 label，com.centurylinklabs.watchtower.enable 這類設定不用改就能用。實際遷移時把 image 換掉、加上更新頻率的 label（live、nightly、weekly、monthly、watch、off 這幾種），Watchtower 的原有 opt-in/opt-out 設定就直接繼承過來。支援的 registry 涵蓋 Docker Hub、GHCR、Quay、lscr.io 等主流 OCI bearer token 端點，私有 registry 走環境變數帶 credential。
單一 binary、Rust 記憶體佔用低、附回滾機制、跟 Watchtower label 相容——這幾點加起來讓 freshdock 在單機或雙機的 VPS 部署情境裡是目前最合適的選項。
三個部署情境的對照
三條路實際落地時的分野很清楚。
家用 NAS 或單臺 VPS 跑三五個容器、想改動最少：直接把 image 換成 nickfedor/watchtower。花的時間不到十分鐘，未來一年沒有大變動的話這樣就夠。缺點是壞了要自己處理，社群 fork 的維護強度終究比不上原專案巔峰期。
單臺或雙臺 VPS 但在意 rollback、討厭凌晨被叫起來手動修的：換 freshdock。單一 binary 部署簡單、附健康檢查回滾、label 直接吃 Watchtower 原有設定。缺點是沒有 UI，要看狀態只能翻 log。
管理十臺以上主機、需要 Web UI 給非 CLI 派同事用、有多環境更新排程需求：上 Tugtainer。多主機 agent 架構解決集中管理、compose 依賴解析解決重啟順序、UI 解決可見性。缺點是專案年輕、部署複雜度比前兩者高、正式環境要接受目前還在快速迭代的現實。
Watchtower 的死亡不是壞事。這個生態多年停在「反正也沒別的可以選」的狀態，現在有人願意花時間把架構往前推、把安全邊界劃清楚、把 rollback 這種基本盤補上，整體品質最終會比 2023 年的 Watchtower 高出一個檔次。
結論與服務推薦
Watchtower 官方倉庫的 archive 逼著整個自架社群把「容器自動更新」這件事重新想過一遍。短期繼續用 nickfedor fork、長期換成 freshdock 或 Tugtainer，是目前三條可走的路，選哪一條由部署規模跟對 rollback 的重視程度決定。
NCSE Network 提供臺灣是方電訊機房的 VPS 主機，Intel Gold CPU 加 NVMe SSD，是自架 Tugtainer 這類 Web-based 管理面板或 freshdock 常駐更新守護程式的合適平臺——低延遲的臺灣機房加上穩定的網路連接，讓自動更新真正跑起來時不會被上游 registry 拉取速度拖垮。歡迎到 https://ncse.tw 進一步了解服務內容。
