Containers
When a Worker isn't enough, spin up a real container — your own Docker image, a full filesystem, any language — controlled from Worker code.
What are Containers?
Cloudflare Containers let you run a full container image — packaged with its own operating system, libraries, and files — on Cloudflare's network, started and managed directly from your Worker code.
A "container" is a self-contained box that holds an application plus everything it needs to run. The most common way to build one is with Docker. Containers are perfect when a lightweight Worker can't do the job — for example, when you need a specific programming language, lots of memory, multiple CPU cores, or a real disk.
Think of it like…
A Worker is like a quick errand you can do empty-handed. A container is like a fully packed suitcase — it carries everything your app needs (the OS, tools, files) so it runs the same way anywhere you set it down.
Why use it?
Workers are fast and cheap, but they run in a sandbox with limited memory and only support a few languages. Some jobs simply need more. Containers fill that gap — without you having to learn Kubernetes or run your own servers.
More power
Get up to 4 vCPUs and 12 GiB of memory — far beyond a Worker's 128 MB limit.
Any language
Run Python, Go, Java, FFmpeg, or any binary that runs on Linux — not just JavaScript.
A real filesystem
Read and write files on a full disk (up to 20 GB), great for processing or temporary storage.
Bring your image
Already have a Docker image? Deploy it as-is — no rewrite needed.
No ops burden
Cloudflare provisions, scales, and routes for you. No clusters, no orchestration to manage.
Worker-native
Containers are controlled from Worker code, so they plug straight into the rest of your stack.
When should you use it?
Reach for Containers whenever a task is too heavy, too specialized, or too "Linux-y" for a plain Worker.
Media processing
Transcode video or images with tools like FFmpeg that need CPU and a filesystem.
Heavy compute
Run data crunching, simulations, or model inference that exceeds Worker memory.
Existing apps
Lift an existing Python/Go/Java service into the Cloudflare network with its Docker image.
CLI tools & binaries
Wrap a command-line tool that only ships as a Linux binary and call it from a Worker.
Untrusted code
Run user-supplied or AI-generated code in an isolated container sandbox.
Custom runtimes
Need a specific OS version, system library, or odd dependency? Bake it into the image.
How do you get started?
You define a container with a Dockerfile, point your Worker at it in wrangler.jsonc, and deploy with Wrangler. Cloudflare builds the image and runs instances on demand. (Containers require the Workers Paid plan.)
Scaffold from the template
Start from Cloudflare's official containers template, which includes a Dockerfile and Worker wired together.
npm create cloudflare@latest -- --template=cloudflare/templates/containers-templateConfigure the container
In wrangler.jsonc, name your container class, point to your Dockerfile, and cap how many instances can run at once.
{ "name": "my-container-app", "main": "src/index.js", "compatibility_date": "2025-05-23", "containers": [ { "class_name": "MyContainer", "image": "./Dockerfile", "max_instances": 10 } ], "durable_objects": { "bindings": [ { "name": "MY_CONTAINER", "class_name": "MyContainer" } ] }, "migrations": [ { "tag": "v1", "new_sqlite_classes": ["MyContainer"] } ] }Deploy
Wrangler builds your image, pushes it, and goes live. Instances start on demand and sleep when idle.
npx wrangler deploy
import { Container, getContainer } from "@cloudflare/containers";
export class MyContainer extends Container {
// The port your container app listens on
defaultPort = 8080;
// Put the container to sleep after 10 minutes idle
sleepAfter = "10m";
}
export default {
async fetch(request, env) {
// Get (or start) a container instance and forward the request to it
const container = getContainer(env.MY_CONTAINER);
return container.fetch(request);
},
};Containers are built on Durable Objects
Under the hood, each container is managed by a Durable Object — that's why the config has a durable_objects binding and a migration. You don't need to understand Durable Objects to use Containers, but it's why they integrate so smoothly.
Key concepts
Image
The packaged blueprint of your app and its environment, usually built from a Dockerfile.
Instance type
The size of the machine — from lite (256 MiB) up to standard-4 (4 vCPU, 12 GiB, 20 GB disk).
On-demand instances
Containers start when needed and sleep when idle, so you only pay while they're awake.
sleepAfter
How long an idle container stays awake before sleeping to save resources, e.g. "10m".
Container class
A JavaScript class extending Container that defines your container's port and behavior.
max_instances
A cap on how many copies of your container can run simultaneously — useful for cost control.
Tips & pricing
Let them sleep
You're billed for memory and disk while a container is awake, and for vCPU only while it's actively computing. Set a sensible sleepAfter so idle containers don't keep running up the bill.
Instance types
- lite — 1/16 vCPU, 256 MiB memory, 2 GB disk
- basic — 1/4 vCPU, 1 GiB memory, 4 GB disk
- standard-1 — 1/2 vCPU, 4 GiB memory, 8 GB disk
- standard-2 — 1 vCPU, 6 GiB memory, 12 GB disk
- standard-3 — 2 vCPU, 8 GiB memory, 16 GB disk
- standard-4 — 4 vCPU, 12 GiB memory, 20 GB disk
Paid plan required
Containers run on the $5/month Workers Paid plan, which includes monthly allowances (25 GiB-hours of memory, 375 vCPU-minutes, 200 GB-hours of disk) before usage-based charges kick in.
Related products
menu_bookOfficial docsopen_in_new