Docker 把應用程式包成 image 容易，把 image 送到伺服器卻常常是整個部署流程裡最尷尬的一段。CI build 完一個 200 MB 的映像檔，要先推到 Docker Hub、ghcr.io 或者自架的 Harbor，再到目標機器 docker pull 下來。為了一台跑五個容器的 VPS 而開一座 Registry 服務，這個比例在實務上一直被質疑。
Unregistry 是 2025 年中由 Pavlo Sviderski 開源、2026 年初開始被廣泛討論的工具。設計上它不是另一套 Registry 替代品，而是徹底跳過中間那層——把映像檔以 SSH 直送到目標伺服器，過程中只傳缺少的 layer。這篇拆解它為什麼被需要、運作機制，以及在自架 VPS 部署流程裡的真實定位。
中小型部署被 Registry 卡住的場景
問題出在 Docker 預設工作流的不對稱性。本地 build 出來的 image 已經完整存在開發者或 CI 機器的 Docker daemon 裡，目標伺服器需要的也只是同一份檔案，但兩者中間多了一個 Registry。
走 Registry 的代價包含三件事。其一是部署環節多一個必須維運的服務：Harbor 要外掛 PostgreSQL、Redis、TLS 憑證，自架 Distribution 雖然輕量但仍需要儲存清理與授權設定。其二是頻寬重複：image 先從 CI 推上 Registry，再從 Registry 拉下伺服器，等於同一份 layer 在公開網路上多走一趟。其三是攻擊面變大：對外提供 Registry 端點意味著得處理使用者認證、金鑰輪替、log 稽核。
繞過 Registry 的傳統做法是 docker save 後 scp 過去再 docker load。但這條路的缺陷很明顯——save 出來的是完整 tar，每次部署都會把 200 MB 整包重新傳送，即使應用層只動了 5 MB。對於每天部署多次的小型服務，這個延遲跟頻寬浪費累積得很快。
Unregistry 的設計把 Registry 收進伺服器的 Docker daemon
Unregistry 的核心想法是：與其架一座中央 Registry，不如讓目標伺服器自身的 Docker daemon「臨時扮演」一座 Registry。
具體實作上，Unregistry 是一個容器化的 Registry 服務，但儲存後端不是傳統檔案系統，而是直接讀寫 containerd 的 image store。這代表當映像檔被推進 Unregistry，它就已經是 Docker daemon 認得的 image，不需要額外的「從 Registry 同步到 Docker」步驟。
搭配 Unregistry 一起發佈的 docker pussh 指令——刻意多一個 s 提醒這是走 SSH 推送——是一個 Docker CLI plugin。它編排了整套流程：建立 SSH 連線、在遠端啟動暫時的 Unregistry 容器、把本地的某個 port 轉發到容器內的 Registry port、執行標準的 docker push、結束後關閉容器與通道。
對使用者而言，整個指令長這樣：
1 | docker pussh myapp:latest [email protected] |
對遠端伺服器而言，整個過程只在記憶體裡多了一個短暫的容器，沒有任何長駐服務、沒有對外暴露的 port、沒有額外的身分驗證系統。
docker pussh 的執行細節
把整段流程攤開來看，每次推送會發生這些事：
本地的 docker-pussh plugin 解析參數，確認目標 host 與映像檔。SSH 連到目標伺服器後，下達指令啟動 ghcr.io/psviderski/unregistry 容器，這個容器掛載目標伺服器的 containerd socket。SSH 通道把本地的隨機 port 轉發到容器內的 5000 port。
接著 plugin 在本地呼叫標準的 docker push，目的地是 localhost:<隨機 port>。Docker daemon 走標準 Registry V2 API，把每一層 blob 上傳——但因為目標 Registry 直接讀 containerd 的儲存，它能立刻回應「此 layer 已存在，跳過」，於是只有缺少的 layer 才會實際走過 SSH 通道。
推送完成後，plugin 關閉遠端容器、收回 SSH 通道。整個過程在 layer 變動小的情況下，通常比 docker save | ssh "docker load" 快上一個數量級。
跟 docker save/load 和 Harbor 的真正差距
實務上會拿來比較的方案大概是三種：自架 Harbor、純 docker save/load、Unregistry。各自的成本曲線並不相同。
Harbor 的長處在多人協作與映像檔治理。它有 RBAC、漏洞掃描、簽章驗證、垃圾回收，適合維護幾十個專案、幾十個開發者共享 image 的場景。但對一個只有兩三個應用、一兩個維運人員的小型 VPS，這套機制顯得過重。Harbor 自身吃的記憶體跟 PostgreSQL 加起來通常超過 1 GB。
docker save/load 的長處在零相依——只需要 Docker、ssh、tar 就能完成。缺點是每次都傳完整 image。對於只動 0.5% 內容的部署，等於浪費 99.5% 的頻寬與傳輸時間。
Unregistry 卡在中間：沒有治理功能、沒有掃描、沒有保留歷史版本，但部署效率接近 Harbor、維運成本接近 save/load。它的甜蜜點是「一個人或小團隊維護幾個應用、每天部署很多次」的場景。對於這種情境，建議直接放棄 Harbor 的念頭，Unregistry 加上 CI 端的 tag 命名規則已經夠用。
與 Kamal、Coolify、Dokploy 的整合位置
Kamal 從 2.0 開始把外部 Registry 視為部署的硬性依賴，這在自架 VPS 場景下偶爾會讓人遲疑。社群在 Kamal 的 GitHub issue 裡長期討論能不能整合 Unregistry，目前可行的做法是在 Kamal 設定裡把 builder 與 Registry 都指向本地，再用 Unregistry 替代實際的推送步驟。Kamal 3 是否正式納入這套模式還在觀察。
Coolify 與 Dokploy 走的是另一種思路：build 直接在伺服器上進行，image 從本地 Docker daemon 拉出來部署。這套模型不需要 Registry，但也犧牲了「跨機器分發同一份 image」的能力。Unregistry 補的正是這個縫——build 在 CI 或開發機，部署到多台伺服器時不必架 Registry，但每台都拿到一致的 image。
對於正在從「手動 ssh 進伺服器 git pull 再 docker compose up」轉向標準化部署的團隊，Unregistry 通常是比 Harbor 更務實的第一步。
該注意的限制
Unregistry 不是萬用工具。實際導入前有幾個點需要先確認。
Windows 平台需要 WSL 2 才能跑 docker-pussh plugin。多平台映像檔（multi-arch）要求本地 Docker 啟用 containerd image store，這在 Docker Desktop 預設配置下需要手動切換。SSH 使用者必須有 docker 群組權限，或者能 sudo 免密碼跑 docker 指令——這在強化過的伺服器上會跟最小權限原則衝突，需要另外設計。
容錯方面，Unregistry 沒有保留版本歷史，推送過去的 image 就是該 tag 的當下版本，無法像正規 Registry 那樣回滾到「三天前那個版本」。在生產環境裡，這代表 image 的版本管理責任全部回到 CI 端的 tag 命名策略上，每次 build 用 git commit hash 當 tag 是比 latest 安全得多的選擇。
跨資料中心同步也不是 Unregistry 的長處。Harbor 有 replication policy 可以把同一份 image 自動同步到多個區域，Unregistry 的設計是點對點，要分發到十台機器就是十次 docker pussh。如果機器數量已經到了需要 fan-out 的規模，Registry 仍然是更合理的架構。
部署這條路該怎麼選
Unregistry 把 Docker 部署裡最不直覺的那段——為了搬一份檔案而架一座服務——壓縮到最低成本。對於跑在臺灣 VPS 上的中小型應用，這個工具能直接拿掉 Harbor 那塊維運負擔，把部署流程簡化成「build 完 → 一行指令 → 上線」。
需要的條件其實只有兩個：穩定的 SSH 連線跟一台跑得動 Docker 的伺服器。NCSE Network 在臺灣是方電訊機房提供搭載 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，搭配低延遲的本地對外連線，是把 Unregistry 接進部署流程的合理基礎。從 build 端到生產機之間少掉一座 Registry，整體部署管線會直接俐落不少。
