Cloudflare Containers

它是什么

Cloudflare Containers 让你在 Cloudflare 的网络内部、紧挨着你的 Workers 运行一个完整的 Linux 容器镜像。当一个 Worker 需要做某件它自己做不到的事——更重的运行时、某个特定的二进制文件、一种放不进 Workers 沙箱的语言或库——它可以把这项工作交给一个在靠近用户处启动的容器。你定义这个容器，由一个 Worker 控制实例何时启动、停止和扩缩。

优势

• 运行真正的容器镜像，因此你可以使用那些在 Workers 沙箱中无法工作的工具和运行时。
• 与 Workers 一同位于 Cloudflare 的全球网络上，因此两者之间的跳转很短。
• 由一个 Worker 编排这些容器，因此你保留了已有的路由、鉴权和边缘逻辑。
• 很适合批处理作业、媒体处理、无头浏览器，以及移植既有的基于 Docker 的代码。
• 按需扩容并能缩回，因此你不必为全天候空闲的服务器付费。

取舍

• 比纯 Worker 更重、启动更慢——冷启动是真实存在的，所以它不适合每一个请求。
• 活动部件更多：你现在要管理一个镜像、它的构建及其生命周期，而不只是一个脚本。
• 同样一件简单任务，它比纯 Worker 更贵；只有在你确实需要容器时才动用它。
• 仍然比 Workers 更新，因此工具链和限制还会持续演进。

何时使用

当一个作业确实需要完整的操作系统、或需要边缘无法提供的运行时时，就使用容器——比如运行一个既有的 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" }
  ]
}