Cloudflare Containers

概要

Cloudflare Containers を使うと、完全な Linux コンテナイメージを Cloudflare のネットワーク内部、Workers のすぐ隣で実行できます。Worker が単独ではできないこと — より重いランタイム、特定のバイナリ、Workers のサンドボックスに収まらない言語やライブラリ — を必要とするとき、その作業をユーザーの近くで起動するコンテナに引き渡せます。コンテナを定義すると、Worker がインスタンスの起動、停止、スケールのタイミングを制御します。

強み

実際のコンテナイメージを実行するため、Workers のサンドボックスでは動かないツールやランタイムを使えます。
Cloudflare のグローバルネットワーク上で Workers の隣に存在するため、両者間の往復が短くて済みます。
Worker がコンテナをオーケストレーションするため、すでに持っているルーティング、認証、エッジロジックを維持できます。
バッチジョブ、メディア処理、ヘッドレスブラウザ、既存の Docker ベースのコードの移植に適しています。
需要に応じてスケールし、また縮小するため、アイドル状態のサーバーに四六時中支払う必要がありません。

トレードオフ

素の Worker より重く、起動が遅い — コールドスタートは現実に存在するため、あらゆるリクエスト向けではありません。
可動部品が増えます。スクリプトだけでなく、イメージ、そのビルド、そしてライフサイクルを管理することになります。
同じ単純なタスクに対しては純粋な Worker よりコストがかかります。本当にコンテナが必要なときだけ使いましょう。
Workers よりまだ新しいため、ツールや制限は進化し続けると考えておきましょう。

使うべきとき

ジョブが本当にフルの OS や、エッジでは提供できないランタイムを必要とするとき — 既存の CLI ツールの実行、Workers が対応していない言語、計算負荷の高いステップ — に、エッジネイティブな入り口を Worker に保ちつつコンテナを使いましょう。

バイブコーディングとの相性

これは AI 支援のきれいな対象です。形が馴染みあるものだからです。Dockerfile に加え、それを起動する小さな Worker。汎用的なクラウド VM を想定するのではなく、Worker からコンテナへのバインディングを正しく配線できるよう、Cloudflare Containers を使っていることをエージェントに伝えましょう。

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