Cloudflare Containers

它是什麼

想像一個航運集裝箱：你的整個應用以及它所需的一切都被裝進一個密封的箱子裡，在哪裡都能一樣執行。Cloudflare Containers 讓你在 Cloudflare 的網路內部、緊挨著你的 Workers 執行一個完整的 Linux 容器——也就是那個密封的箱子。當一個 Worker 需要做某件它自己做不到的事——更重的執行時、某個特定的程式檔案、一種放不進 Workers 沙箱的語言或庫——它可以把這項工作交給一個在靠近使用者處啟動的容器。你定義這個容器，由一個 Worker 控制例項何時啟動、停止和擴縮。

優勢

• 執行真正的容器映象，因此你可以使用那些在 Workers 沙箱中無法工作的工具和執行時。
• 與 Workers 一同位於 Cloudflare 的全球網路上，因此兩者之間的跳轉很短。
• 由一個 Worker 編排這些容器，因此你保留了已有的路由、鑑權和邊緣邏輯。
• 很適合批處理作業、媒體處理、無頭瀏覽器，以及移植既有的基於 Docker 的程式碼。
• 按需擴容並能縮回，因此你不必為全天候空閒的伺服器付費。

取捨

• 比純 Worker 更重、啟動更慢——冷啟動（cold start，請求到來時卻沒有任何東西在執行所產生的預熱延遲）是真實存在的，所以它不適合每一個請求。
• 活動部件更多：你現在要管理一個映象、它的構建及其生命週期，而不只是一個指令碼。
• 同樣一件簡單任務，它比純 Worker 更貴；只有在你確實需要容器時才動用它。
• 仍然比 Workers 更新，因此工具鏈和限制還會持續演進。

何時使用

當一個作業確實需要完整的作業系統（OS）、或需要邊緣無法提供的執行時時，就使用容器——比如執行一個既有的 CLI（命令列介面）工具（一種你通過輸入命令來操作的程式）、一種 Workers 不支援的語言，或一個計算密集的步驟——同時把你邊緣原生的前門保留在 Worker 中。

Vibe coding 契合度

這是一個很清爽的 AI 輔助目標，因為它的形態很熟悉：一個 Dockerfile（構建容器的配方）加上一個啟動它的小 Worker。告訴 agent 你用的是 Cloudflare Containers，這樣它就會正確地接好 Worker 到容器的繫結，而不是假定一臺通用雲 VM（虛擬機器，在雲端租用的一臺計算機）。

// wrangler.jsonc — bind a container to a Worker
{
  "name": "my-app",
  "main": "src/index.ts",
  "containers": [
    { "class_name": "MyContainer", "image": "./Dockerfile" }
  ]
}