By Every developer building on Cloudflare Workers eventually hits the same wall. Your Worker is fast, globally distributed, and costs almost nothing — until you need FFmpeg to transcode a video, a Python script to run an ML model, or headless Chrome to generate a PDF. At that point you abandon the edge and spin up something on Fly.io. Cloudflare Containers went generally available on April 13, 2026: any Docker image, running at 330+ edge locations, wired directly into your existing Workers via bindings.
The Architecture: Durable Objects All the Way Down
Containers are not a separate product bolted on — they run as Durable Objects underneath. Each container instance is a Durable Object that manages its own lifecycle. Your Worker communicates with containers via service bindings, using RPC-style method calls rather than an extra HTTP hop. The container stays private and unreachable by default; traffic only arrives through your Worker, which continues to handle routing, authentication, and caching.
This architecture matters because it preserves what makes Workers valuable — the edge routing layer — while handing off heavy compute to a full Linux environment. The Worker stays fast; the Container handles the work Workers never could.
What You Can Actually Build Now
The short list of things Workers could not do, and Cloudflare Containers can:
- Media transcoding — FFmpeg runs inside a container at the nearest Cloudflare location, cutting latency versus a round-trip to a regional backend
- Browser automation — Puppeteer and Playwright with full headless Chrome, for screenshots, PDF rendering, or scraping pipelines
- Python ML inference — model weights stay in the container, serving predictions at the edge without a separate inference endpoint
- CLI tool execution — PDF generators, zip utilities, language linters spawned on demand, billed only for the CPU they consume
- Code sandboxing — isolate user-submitted code executions; Cloudflare’s own Sandbox product is built on the same underlying tech
The common thread: anything that required a full Linux toolchain previously forced you off Cloudflare. Now it does not.
Deploying a Container: One Wrangler Command
The deployment model is minimal. Write a Dockerfile, add a [[containers]] block to wrangler.toml, and run wrangler deploy. Wrangler builds the image with Docker, pushes it to Cloudflare’s registry, and deploys your Worker — all in one command.
name = "my-container-app"
main = "src/index.js"
compatibility_date = "2026-06-09"
[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
max_instances = 5
[[durable_objects.bindings]]
name = "MY_CONTAINER"
class_name = "MyContainer"
[[migrations]]
tag = "v1"
new_sqlite_classes = ["MyContainer"]Your Worker extends the Container class from cloudflare:workers and exposes container instances through the standard Durable Object stub pattern. Since March 2026, you can reference Docker Hub images directly in your config — no pre-push to Cloudflare Registry required. Point to any public (or private, with credentials) Docker Hub image and deploy.
Debugging Live Containers Over SSH
Enable wrangler_ssh in your container config, add your public key, and connect directly to a running instance:
wrangler containers ssh <instance-id>List running instances with wrangler containers instances <app-name>. SSH ProxyCommand support landed in May 2026, letting your local SSH client connect through Wrangler directly. Live debugging without rebuilding and redeploying cuts a 20-minute cycle down to 2 minutes.
The Pricing Argument
The financial case for Cloudflare Containers hinges on one distinction: active CPU billing. You pay for CPU only when the container is actively processing. An idle container costs memory and disk, not compute. Competitors bill by provisioned CPU — your reserved vCPUs accumulate costs whether or not any traffic is flowing.
For spiky or event-driven workloads, this is a meaningful advantage. For high-sustained-throughput workloads where a container runs at saturation 24/7, run the math yourself — sustained load may not beat a well-sized instance on Fly.io or Render.
Workers vs. Containers vs. Something Else
The decision is not complicated:
- Workers — short, stateless, JavaScript/TypeScript/Wasm, sub-10ms cold starts. Default choice for edge logic.
- Cloudflare Containers — when Workers cannot run your code: binary tools, Python runtimes, anything needing a real filesystem or over 128 MB RAM
- Fly.io / Render / Railway — persistent stateful applications, always-on services, anything requiring persistent volumes
One genuine caveat: the first provision after deploy takes minutes, not milliseconds. Workers spoil you with near-zero cold starts. Containers are closer to a regional container service on that dimension — keep this in mind for latency-sensitive request paths.
The Bigger Picture
Cloudflare is assembling a full application platform: D1, R2, KV, Durable Objects, Queues, AI Gateway, Workers AI — and now Containers for anything Workers cannot run. The account limits have scaled to match: 6 TiB of memory, 1,500 vCPUs, and 30 TB of disk concurrently. This is not a toy tier.
The infrastructure bet is that developers already in the Cloudflare ecosystem will find it easier to stay than to assemble a multi-provider stack. Containers closes the most glaring gap in that story.
Get started at the official getting started guide. Check the pricing page for active CPU rates and instance types. Full platform details are in the Cloudflare Containers documentation.
