Sablier 是一套讓 Docker 容器自動 scale-to-zero 的工具，1.14 版在 2026 年 6 月發布。自架服務的人多半遇過同一個尷尬狀況：機器上跑著二十個容器，但實際每天會打開的只剩三、四個。剩下那些 dashboard、舊版 wiki、半年沒人登入的 NAS 介面、跑一次就放著的測試環境，每一個都默默吃著一兩 GB 記憶體。8GB 的 VPS 看起來不夠用，升到 16GB 又覺得浪費——因為這些服務九成時間都沒人連。
雲端那邊早就有解法。AWS Lambda、Cloud Run、Vercel Functions 都是「沒人用就降到零、有人來才喚醒」。自架環境一直缺一塊對應的拼圖。Sablier 補的就是這個——它本身是一支 Go 寫的 daemon，靠反向代理攔截請求，把對應的容器或 Pod 在收到流量時喚醒、閒置一段時間後再停掉。支援的 backend 從 Docker、Docker Swarm、Podman、Kubernetes 一路覆蓋到 Proxmox LXC。
自架的代價：八成服務閒置卻仍吃滿資源
問題出在「服務常駐」這個預設。Docker Compose 拉起來的容器只要沒有手動停掉就會一直跑，即使整天沒有任何 HTTP 請求進來。Java 寫的 wiki、Python 寫的 ERP、Node 寫的圖形介面，光是 idle 都能吃掉 300MB 到 1GB 不等的 RSS。十幾個堆在同一臺 VPS 上，記憶體很快就見底。
OOM killer 一發動，最先被砍的往往是真正在用的服務。換更大臺方案是最直覺的解法，但這筆錢的本質是在養一堆「以防萬一要用」的閒置程序，並不划算。
另一條路是手動停掉不常用的容器，要用之前再開。問題是這個動作有阻力，多數人不會為了開一次舊 wiki 去 SSH 進機器下 docker compose up。結果通常就是該停的沒停，該升的還是升了。
Sablier 把 serverless 的喚醒模型搬到反向代理
Sablier 的設計核心是把判斷邏輯放在反向代理層。當請求進到 Traefik、Nginx、Caddy、Envoy 等支援的代理時，代理會先問 Sablier：「這條路徑對應的容器現在是不是醒著？」如果是，請求直接放行；如果不是，Sablier 透過 Docker socket 或 Kubernetes API 把對應的工作負載叫起來，然後維持一個 session 計時器。session 期間任何請求都會把計時器歸零，計時器到期就把容器停掉。
整個流程在穩態時對每個請求多加大約 1.5 到 2 毫秒延遲，單核心可以撐 5000 到 5700 RPS。對絕大多數自架服務來說這個 overhead 可以無視。
session duration 預設 5 分鐘，可以依服務性質調整。一個經常被人讀但讀完就關的文件站，設 10 分鐘剛好；一個批次跑完就沒人理的 dashboard，設 1 分鐘就夠。整個機制不需要應用層做任何改動，所有判斷在反向代理外緣完成。
兩種等待策略，給人看和給機器接是不同事
Sablier 提供 dynamic 與 blocking 兩種等待策略，差別在「請求進來但容器還沒醒」的時候要做什麼。
dynamic 策略會立刻回一個 HTML 頁面，內建幾套主題（預設的 hacker-terminal 風格之外還有幾種），瀏覽器每隔幾秒自動 refresh，等容器好了之後刷出真正的內容。適合給瀏覽器使用者，因為網頁可以明確告訴對方「服務正在啟動，請稍候」。
blocking 策略則是直接讓 HTTP 連線掛在那裡，等容器 ready 才回 response。對 webhook、API client、健康檢查這類非互動式的呼叫者比較合適，因為這些角色不會處理 HTML 等待頁面。預設 timeout 1 分鐘，超過就回 504。
選擇邏輯很直觀：人看的用 dynamic，程式接的用 blocking。同一個 Sablier 實例可以為不同 route 配不同策略，文件站走 dynamic、API endpoint 走 blocking 並不衝突。
新版本還多了一個 scale mode，不停容器、改成把它的 CPU 和記憶體限制壓到極低。優點是沒有冷啟動，缺點是還佔著進程空間。適合那種啟動成本特別高、但常駐記憶體也不算大的應用，例如帶 JVM warmup 的 Java 服務。
從 Docker Compose 撐到 Kubernetes 和 Proxmox LXC
provider 支援是 Sablier 比其他類似工具更廣的地方。早期同類的 KEDA 主要鎖定 Kubernetes，knative 則綁死整個 serverless framework。Sablier 從一臺單機跑 Docker Compose 開始就能用——Compose 服務貼上 sablier.enable=true 與 sablier.group=mygroup 兩個 label，反向代理那邊掛上對應的 middleware 就能跑。
到了 Kubernetes 環境，Sablier 處理 Deployment 與 StatefulSet 的 replica 調整，搭配 Ingress 上的 annotation 觸發。Proxmox LXC 那條路徑透過 API token 認證，連 container 從啟動到 ready 都能等。同一支 binary 可以同時管理多種 provider，這在混合架構的小型機房特別有用——前端 Docker Compose 跑網站，後端 Proxmox LXC 跑資料庫沙箱，全部交給同一個 Sablier 排程。
group 機制可以把多個容器綁在一起喚醒。一個 wiki 同時需要 PostgreSQL 與 Redis，Sablier 收到 wiki 的請求時會把三個容器一起拉起來，並一起算 session。避免單獨叫醒 wiki 但發現後端資料庫還沒好的尷尬。
不適合用 Sablier 的場景
冷啟動敏感的服務不該套。任何要求 P99 延遲低於 100ms 的 API，被 Sablier 攔下後第一個請求至少要等容器啟動完畢，重的 Java 應用要十秒以上，使用者一定會察覺。這類場景應該保持常駐，或者用 scale mode 取代。
需要常駐背景工作的服務也不合適。定期跑 cron job、處理 message queue 的 worker、收 webhook 的服務——這些被停掉就漏資料。Sablier 是「請求驅動」的，沒有外部請求進來時不會被喚醒，自然不適合純背景模式。
session 機制也意味著無法精準預測停機時間。如果有 SLA 要求或合約規定服務 7×24 可用，scale-to-zero 在審計層面會變麻煩。
部署上要注意的幾個地方
健康檢查是第一個關鍵。Sablier 判斷容器 ready 完全依靠 Docker 的 healthcheck 或 Kubernetes 的 readiness probe，如果應用 Dockerfile 沒寫 HEALTHCHECK，Sablier 只能猜「容器有跑起來」就算 ready，但實際上應用可能還在 warmup。生產環境必須在 Dockerfile 補上正確的 healthcheck 指令，否則 dynamic 等待頁面會在容器還沒準備好時就放行請求。
socket 權限是第二個風險點。連 Docker socket 等於 root 等級權限，把 Sablier 跑在獨立的低權限使用者底下、用 Docker socket proxy 隔開操作面，才不會讓反向代理層變成攻擊目標。Kubernetes 環境則要把 RBAC 精準綁定到能操作的 namespace，避免一個 Sablier 實例能停掉整個 cluster 的工作負載。
metrics 是第三個容易被忽略的部分。Sablier 內建 Prometheus endpoint 與 OTLP tracing，建議至少把 wake-up 次數、session 維持時間、blocking timeout 失敗率三個指標納入監控。長期觀察可以反過來校正 session duration——某個服務若每 30 秒就被叫醒一次，session 拉長到 5 分鐘還比較省，反覆冷啟動本身也會吃 CPU。
結論
scale-to-zero 過去是雲端 serverless 平臺的專利，在自架圈長期欠缺對等方案。Sablier 用一支 Go binary 加上反向代理 plugin，把這個能力下放到 Docker Compose、Kubernetes 與 Proxmox LXC，讓單臺 VPS 能容納原本要更大方案才放得下的服務數量。對於同時架二十個工具但只有三個天天用的人，這個工具的回本速度比想像中快。
NCSE Network 的臺灣 VPS 採用 Intel Gold CPU 與 NVMe SSD，機房落在臺北是方電訊。搭配 Sablier 這類 idle 管理方案，可以把 8GB 或 16GB 的方案發揮到最滿。如果正在評估自架服務的長期成本，歡迎了解 NCSE Network 的 VPS 主機方案。
