Cloud Parts

Cloudflare Containers

Linux container images that run on Cloudflare’s network next to a Worker, each instance started on demand by its own Durable Object and put to sleep when idle.

What it is
Containers
Used for
Serverless functions (FaaS)
Type
Commercial product
Made by
Cloudflare, Inc.
License
Proprietary
Facts checked
12 October 2026
Website

What it is

You ship an ordinary linux/amd64 image alongside a Worker, and wrangler deploy builds it, pushes it to Cloudflare’s registry and readies it across the network. A container instance is never reached directly: a Worker sends the request to a Durable Object, and that object starts, stops and talks to its container through ctx.container (or the Container helper class). Calling the namespace with a new ID, such as a user session, gets a separate instance, so routing per user, per tenant or per job is just a choice of ID. Each instance runs in its own Firecracker microVM with its own kernel, in a Cloudflare location near the request that started it; cold starts are often 1 to 3 seconds, depending on the image. Since Birthday Week 2026, Containers can also be run as agent sandboxes: under the durable_object scheduling policy (in public beta) each Durable Object picks the image and instance type when it starts its container, the container starts on or near the Durable Object’s machine from a prepared VM, and median startup in ComputeSDK’s benchmark fell from about 4 seconds to 648 ms.

Instances stop after an inactivity timeout (10 minutes by default with the Container class), and you pay only while they run, in 10 ms increments: memory and disk by the size provisioned, CPU by active use. Six instance types range from lite (1/16 vCPU, 256 MiB, 2 GB disk) to standard-4 (4 vCPU, 12 GiB, 20 GB), or you can define a custom size. The Workers Paid plan includes 25 GiB-hours of memory, 375 vCPU-minutes and 200 GB-hours of disk a month; beyond that, a vCPU costs $0.00002 per second and a GiB of memory $0.0000025 per second, plus egress from $0.025 per GB after 1 TB in North America and Europe. Containers and the Sandbox SDK built on them became generally available on April 13, 2026.

Why teams pick it

  • Scale to zero with per-ID routing: each session, tenant or job can get its own instance, started on the first request and stopped when idle
  • Hardware isolation: every instance is a Firecracker microVM with its own kernel, which suits untrusted or AI-generated code
  • Programmable from TypeScript: the Durable Object in front of each container handles routing, auth, lifecycle hooks and saved state, with no Kubernetes operators or control plane
  • CPU is billed by active use, not allocation, so a mostly idle instance pays mainly for its memory and disk

Watch out for

  • Inbound traffic must arrive as HTTP or WebSocket through a Worker; end users can’t open raw TCP or UDP connections to a container
  • The local disk is wiped when an instance sleeps; keeping files means snapshots (Durable Object scheduling policy, in beta), FUSE-mounted R2 or other storage
  • Instances top out at 4 vCPU, 12 GiB of memory and 20 GB of disk, and an account at 1,500 vCPU and 6 TiB of memory running at once by default
  • Cold starts of 1 to 3 seconds, and a restarted instance may come up in a different location from before; only the Workers Paid plan has Containers

The Cloudflare Containers family

1 technologies built from or on Cloudflare Containers

Alternatives

What all containers have in common →
AWS FargateAWSRuns ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.DockerOpen sourceThe tool that made containers mainstream: build an image from a Dockerfile, then run it anywhere.Google Cloud RunGoogle CloudGive Google a container that listens on a port; it runs as many copies as traffic needs, down to zero.gVisorOpen sourceA Linux kernel reimplemented in Go that runs in user space, so a container’s system calls never reach the host kernel directly.PodmanOpen sourceRuns Docker-style containers without a daemon, as root or as an ordinary user, and hands long-running ones to systemd.

How it fits with other technologies

One container per session, asleep after 5 idle minutes · ts

import { Container, getContainer } from "@cloudflare/containers";

// A Durable Object class that wraps the container ("containers" in wrangler config)
export class CodeRunner extends Container {
  defaultPort = 8080;      // where the image listens
  sleepAfter = "5m";       // stop the instance when idle
  enableInternet = false;  // no outbound internet access
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const session = request.headers.get("x-session-id") ?? "anonymous";
    // The same ID always reaches the same instance while it runs
    return getContainer(env.CODE_RUNNER, session).fetch(request);
  },
};

See it in a real stack

No architecture uses Cloudflare Containers yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2025–2026

Workers run in V8 isolates, which start fast but can’t run arbitrary binaries, a full Linux userland, or programs that need gigabytes of memory and several cores. Customers kept telling Cloudflare they would run their whole application on it if only they could deploy the one piece that needs a container. At the end of Developer Week in April 2025, Mike Nomitch announced that Cloudflare had been building a container platform and would open a beta in June, aimed at running user-generated code, CLI tools, heavy workloads and applications ported from other clouds.

Instead of a separate orchestrator, Containers sit on Durable Objects. Each container gets an object that acts as a programmable sidecar: it proxies requests, starts and stops the container, and runs code when its status changes, while the Worker in front plays API gateway, service mesh and orchestrator. The public beta opened to all paid plans on June 24, 2025.

During the beta Cloudflare switched CPU billing to active use (November 2025), raised account limits fifteenfold to 1,500 vCPU (February 2026), and added Docker Hub images, SSH and connections to Workers bindings. Containers and the Sandbox SDK became generally available on April 13, 2026. On September 30, 2026, in “Cloudflare Containers, rebuilt to scale agent sandboxes”, Thomas Gauvin described a rearchitecture for agents that create a sandbox per task: a new durable_object scheduling policy, in public beta, lets each Durable Object choose its image and size at start time, replaces application-wide rollouts with code, and adds filesystem snapshots, while a redesigned runtime restores prepared VMs to start containers more than 6x faster.

Why it’s built this way

Every container behind a Durable Object
The announcement calls each Durable Object a “programmable sidecar”: routing, lifecycle hooks, health checks and saved state are written as Worker code, instead of Kubernetes operators or control-plane configuration.
Addressed by ID, started on demand
Calling the namespace with a unique ID gives a unique instance that boots on its first request and sleeps after a timeout, which fits per-user sandboxes for untrusted, LLM-generated code and costs nothing while asleep.
Private by default, reached only through Workers
Requests are encrypted until they reach the container’s port on the host, so containers don’t need their own TLS certificates, and outbound traffic can also be forced through Workers.

Timeline

  1. 2025

    Announced in April, at the end of Developer Week

  2. 2025

    Public beta for paid plans on June 24

  3. 2025

    CPU billed by active use instead of allocation, from November 21

  4. 2026

    Account limits raised 15x to 1,500 vCPU and 6 TiB of memory in February

  5. 2026

    Containers and Sandboxes generally available on April 13

  6. 2026

    Rebuilt for agent sandboxes on September 30: per-start images, 6x faster starts, snapshots in beta

Sources9 · facts checked 12 October 2026

Improve this page on GitHub