2026-10-01 — Containers 新排程策略：程式碼選映像檔，啟動快 6 倍

Containers 新排程策略：程式碼選映像檔，啟動快 6 倍

Cloudflare Blog · 2026-09-30

Cloudflare Containers 的映像檔與機型不再於 wrangler deploy 時固定，改由 Durable Object 的程式碼在啟動沙箱時才決定。這是新的 durable_object 排程策略，目前為公開 beta，同時帶來約 6 倍的啟動速度與檔案系統快照。

這次改動是為 agent 工作負載而做：agent 會為每個任務即時建立沙箱，並期待它立刻可用、可暫停、可恢復。

原本的問題

過去每一組「映像檔加機型」都是一個獨立的 Containers application，各有自己的 Durable Object namespace，必須事先用 wrangler deploy 建好。一個 agent 要小型 Node.js 沙箱、另一個要大型 Python 沙箱，就得兩個 application、兩個 namespace，還要在 Worker 裡寫路由邏輯把任務送到對的那一個。

更新映像檔也是整個 application 一起更新：要設定 grace period 讓實例排空、設定百分比分流，再呼叫 API 推送新設定。替換哪些實例、何時替換由平台決定，即使 agent 正做到一半。

啟動路徑同樣偏慢。啟動 Container 要先經過全域 control plane 解析設定、尋找容量、協調配置，部署機制被放在 agent 第一個指令的路徑上。

核心改動

在 wrangler.jsonc 設定排程策略並宣告可選映像檔，程式碼再於啟動時挑選：

// wrangler.jsonc
"scheduling_policy": "durable_object",
"images": { "node": {...}, "python": {...} }

// Durable Object
this.ctx.container.start({
  image, instance: "standard-2",
  enableInternet: true,
});

以前要另開一個 application 的事，現在是一個 if 判斷。同一個 Durable Object class 可以並存不同大小的 Node.js 與 Python 沙箱，新增環境只是改程式碼，不必重新部署。

rollout 也變成程式碼：Container 會一直跑啟動時的映像檔，直到你的程式碼停止它，下次啟動才用新選的映像檔。文章列出的做法包括依 Durable Object ID 雜湊讓新工具鏈只進 5% 的新沙箱、把進行中的專案釘在目前映像檔、以及改變後續啟動的選擇來回滾，不需推送設定或等待排空。

實際效果

新路徑從 Durable Object 所在處開始找容量：先找同一台機器，找不到再擴大到同一地點，並偏好本機已有映像檔或快照的主機。抵達主機後，新 runtime 會還原一台預先準備、尚未指派的虛擬機，而不是從頭開機。

在 ComputeSDK 的獨立 Burst TTI 測試（同時啟動 100 個沙箱，從客戶端量測到可互動的時間）中：

Cloudflare 自己的初步突發測試中，單一帳號在六個地點於 5.387 秒內啟動了 100,000 個 Container。這是廠商自測，文章標明為 preliminary。

映像檔與快照

新增 cloudflare/debian-trixie 系統映像檔，內含 Debian Trixie Slim 與 Node.js 24.20.0 LTS。因為由 Cloudflare 掌控，可以在請求到達前先分發到各主機，agent 不必自己寫 Dockerfile 與推送映像檔，啟動後用 exec() 裝好環境即可。

檔案系統快照（公開 beta）解決「每次啟動都要重新 clone、裝依賴」的等待。快照不可變，可被多個 Container 各自當作起點，適合 eval 時固定 repo、依賴與輸入檔來比較不同模型或 prompt：

const snapshot = await this.ctx.container
  .snapshotContainer({ name: "project-ready" });
// 之後
this.ctx.container.start({
  containerSnapshot: snapshot,
  instance: "standard-2",
});

影響範圍

新能力只在原生 ctx.container API 提供，包括新排程策略、快速啟動、執行期選映像檔與機型、快照。文章指出 Container class 與舊的 Sandbox class 維護到 2026 年 12 月 31 日，之後既有部署仍會運作，但不再更新。

• 繼承 Container 的專案：通常改成 extends DurableObject 並直接呼叫 this.ctx.container，細節見遷移指南。
• 為每種環境各開一個 application 並在 Worker 做路由的專案：可合併成單一 Durable Object class。
• 使用 Sandbox SDK 的專案：SDK 1.0 改為工具函式集合，不再是 base class，helper 在自己的 Durable Object class 內搭配 ctx.container 使用。
• 自行管理 rollout grace period 與分流比例的專案：改用程式碼控制後，這些設定不再適用。

文章未說明快照的容量上限與計費，遷移前需自行查閱文件。

原始來源：Cloudflare Blog、ComputeSDK Burst TTI、遷移指南