Skip to content

SYSTEM Cited by 7 sources

Cloudflare Containers

Cloudflare Containers is Cloudflare's Docker-container runtime on the Developer Platform, intended for workloads that don't fit the Workers isolate model — typically because they need arbitrary binaries, multi- process runtimes, or Linux-filesystem assumptions. Containers are addressable from Workers and can be driven at a higher level via Sandbox SDK.

Ephemeral by design

Containers are inherently ephemeral — data generated inside a container is lost when the container is deleted. This is the structural shape called out as durable-vs-ephemeral-sandbox. Persistent-storage needs are met by mounting external storage (e.g. R2 via sandbox.mountBucket()) rather than by persisting the container filesystem itself.

The durable_object scheduling policy (2026-09 rearchitecture)

In 2026-09 Cloudflare rearchitected Containers from an application-deployment model into an on-demand agent-sandbox substrate (Source: sources/2026-09-30-cloudflare-containers-rebuilt-to-scale-agent-sandboxes). The old model made two decisions at deploy time and rolled them across the whole application: which image a Container runs and how much compute it gets. Each (image, instance-type) combination was its own Containers application with its own Durable Object namespace, provisioned ahead of time with wrangler deploy, with routing logic in a Worker to send each task to the right one. Agents don't fit that shape — they create a sandbox per task, and the task determines image/resources/tools/starting- filesystem.

The durable_object scheduling policy moves those decisions into application code that runs at request time, controlled by the Container's attached Durable Object. Images are declared in wrangler.jsonc and exposed as this.ctx.container.images.<name>; the DO picks image + instance inside ctx.container.start(...) after the task is known:

// wrangler.jsonc: "scheduling_policy": "durable_object",
//   "images": { "node": {...}, "python": {...} }
const image = workspace.toolchain === "python"
  ? this.ctx.container.images.python
  : this.ctx.container.images.node;
const instance = workspace.workload === "build" ? "standard-2" : "standard-1";
this.ctx.container.start({ image, instance, enableInternet: true });

"What used to take a separate application and a separate wrangler deploy is now an if statement." One DO class can start Node.js and Python sandboxes of different sizes side by side, and adding an environment is a code change, not a deployment.

Rollout as code

Because the image is chosen at start time, there is no rollout configuration — no grace periods, percentage splits, or config-push API. A Container keeps its start-time image until the DO's code stops it; the next start uses whatever the code chooses. Canary (hash the DO ID), pin (store pinned-image in DO storage), migrate at a checkpoint, and roll back all become a few lines of DO code. This is patterns/progressive-configuration-rollout relocated from a platform control plane into the application. (Source: sources/2026-09-30-cloudflare-containers-rebuilt-to-scale-agent-sandboxes)

Faster first command (6× startup)

The old first-command path went through a global control plane to resolve app config, find capacity, and coordinate placement. The new path starts demand at the Durable Object: it looks for capacity on the same machine first, then widens within the location, and favors hosts that already hold the image or snapshot locally (image locality). The redesigned runtime restores a prepared virtual machine that isn't yet assigned instead of booting one from scratch — reusing networking + filesystem setup, batching repeated operations, and skipping services the first command doesn't need. This is control-plane removal from the data path plus a prepared-VM warm pool.

On ComputeSDK's independent Burst TTI benchmark (100 concurrent sandboxes, client-measured time-to-interactive): median 4.049 s → 648 ms (6.2×), p95 5.839 s → 910 ms (6.4×), p99 6.717 s → 1129 ms (5.9×). In Cloudflare's own preliminary burst test, one account started 100,000 Containers in 5.387 s across six locations. See concepts/cold-start.

Prepared base image + filesystem snapshots

Two capabilities ship alongside the policy:

  • cloudflare/debian-trixie — a Cloudflare-managed base image (Debian Trixie Slim + Node.js 24.20.0 LTS) pre-distributed and unpacked onto hosts before requests arrive, so image download/unpack leaves the user-visible path.
  • Native filesystem snapshots (public beta) — ctx.container.snapshotContainer({ name }) saves a workspace; ctx.container.start({ containerSnapshot, ... }) restores it. Snapshots are immutable and reusable, so one baseline can be forked into many independent sandboxes — a copy-on-write storage fork enabling both cross-session persistence and eval/RL fan-out (patterns/snapshot-replay-agent-evaluation).

DO as explicit controller; Sandbox SDK 1.0

New capabilities are native-only on ctx.container: exec() runs directly in the Workers runtime, and outbound-request interception, image/instance selection, and snapshots all live on ctx.container with no wrapper class. The Container becomes a compute extension of the Durable Object, which retains identity, state, policy, and lifecycle. The legacy Container class and Sandbox class are maintained only through 2026-12-31; Sandbox SDK 1.0 is reframed as utilities that work inside your own DurableObject class, and @cloudflare/computer is the higher-level env combining Dynamic Workers + Containers with a synchronized filesystem.

Storage architecture (per-container writable root disk)

Each container runs inside a dedicated Firecracker virtual machine, and its writable root disk is provided by Linux device-mapper thin provisioning (dm-thin). Firecracker presents this disk to the guest as /dev/vdc. Physical storage is allocated lazily: dm-thin only maps a physical block when the virtual disk first writes to a previously-unmapped region, and the thin blocks live in a pool shared across multiple customer accounts on the host — when a container's thin volume is deleted, its physical blocks return to that shared pool. OCI image layers are served from a per-host cache of prepared dm-thin snapshots, so a new container can inherit block mappings from a cached layer without re-allocating them. (Source: sources/2026-09-24-cloudflare-how-cloudflare-addressed-a-cross-tenant-data-exposure-vulner-4224c10f)

This shared-pool + lazy-allocation design is exactly what made the 2026-09 cross-tenant data-remanence vulnerability possible (see Seen in) — the storage layer, not the identity/network layer, was where tenant isolation had to be re-hardened.

Positioning

  • Not the default compute tier on Cloudflare — Workers isolates are. Containers are opt-in for workloads where isolate constraints don't fit (custom binaries, ffmpeg-style tooling, agent runtimes, full Docker images).
  • Paid-plan feature — the Workers Paid plan is required to access Sandbox Containers.
  • Usually driven via Sandbox SDK, not raw Container APIs, for ergonomic lifecycle / networking / filesystem / process management.

Seen in

  • sources/2026-09-30-cloudflare-containers-rebuilt-to-scale-agent-sandboxes — canonical wiki instance of the durable_object scheduling policy and the 2026-09 agent-sandbox rearchitecture: runtime image/instance selection moved into DO code, rollout-as-code, prepared-VM restore (6.2× median startup: 4.049 s → 648 ms; 100k Containers in 5.387 s), the pre-warmed cloudflare/debian-trixie base image, and native filesystem snapshots (public beta). Makes the Durable Object the explicit Container controller via ctx.container; deprecates the Container/Sandbox base classes after 2026-12-31 in favor of Sandbox SDK 1.0 utilities and @cloudflare/computer.
  • sources/2026-10-01-cloudflare-introducing-clef-our-open-source-decision-models-and-new-rl — Containers as the RL sandbox in Cloudflare's Clef RL fine-tuning product: "Cloudflare Containers – RL sandbox for scoring and replaying agent actions." The third stage of the AI-Gateway → Workers-AI → Containers → Trainer → BYO-Model loop — the ephemeral, forkable container substrate (cf. filesystem snapshots / eval-RL fan-out) used to score and replay agent trajectories during decision-model fine-tuning.

  • sources/2026-09-24-cloudflare-how-cloudflare-addressed-a-cross-tenant-data-exposure-vulner-4224c10f — canonical wiki instance of a cross-tenant data-remanence vulnerability on the Containers storage layer. A Workers Paid customer could recover residual disk blocks from other tenants' deleted containers on the same host, because the shared dm-thin pool backing container root disks was configured with skip_block_zeroing (blocks handed to a new owner without being cleared). With a 64 KiB thin-block size, a 4 KiB write triggered allocation of a reused block and replaced only 4 KiB — the remaining 60 KiB kept the previous owner's data, readable via a raw read of Firecracker's /dev/vdc. Reported via HackerOne (Oren Yomtov / Accomplish) 2026-09-04; runtime fix merged the same day. Two-stage mitigation: (1) remove skip_block_zeroing fleet-wide (restore zero-on-allocate — killed the PoC); (2) retire running container disks + purge pre-mitigation cached OCI-layer snapshots (drain hosts, restart VMs, clear image caches), because zeroing new allocations does not sanitize blocks already mapped into live disks or cached snapshots. Validated foreign-block attribution via ext4 metadata_csum directory-block checksums (5,614 foreign blocks / 2,700 foreign inodes across 6 placements; residual data on 18/24 placements, 20/22 nodes, four continents — including complete SQLite databases). A detection-signature sweep of historical disk-I/O telemetry found no exploitation beyond the researchers. Read-only, non-targetable exposure (bounded blast radius — no victim selection, no writes, no availability impact). A textbook vendor-first-patch response. All cached snapshots cleared fleet-wide 2026-09-19.

  • sources/2026-05-19-cloudflare-announcing-claude-managed-agents-on-cloudflare — canonical wiki instance of Cloudflare Containers as the microVM tier in a per-agent sandbox-substrate choice. The launch post pairs Containers with Dynamic Workers (V8-isolate tier) as the two interchangeable backends an operator can pick per agent at setup time — "agents acting as a developer, building full applications and running Linux-based tools" pick Containers; "a faster, cheaper, and more scalable alternative" picks isolates. The trade-off itself is canonicalised at concepts/micro-vm-isolation; the larger architectural shape (Anthropic brain ↔ Cloudflare hands) at agent-brain-hands-decoupling; the egress-policy half at patterns/agent-sandbox-with-gateway-only-egress and outbound-proxy-credential-injection. Containers here are the dev-agent-shape backend for Claude Managed Agents — the "if you need agents to act as a developer, building full applications and running Linux-based tools" case.

  • sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster — canonical wiki instance of Cloudflare Containers as the Customer Zero substrate for Browser Run. Browser Run migrated off shared Browser Isolation (BISO) infra onto its own DO-enabled Container image to unblock three workload-shape mismatches that had been bottlenecking it (image-size, distribution footprint, long-steady-vs-short-spiky session shape). The migration surfaced (and drove fixes for) the "novel, unstable early-stage Containers platform interface that was light on documentation, light on observability, and light on colleagues in an overlapping timezone" — explicitly framed as customer-zero for the Containers platform itself. Two architectural primitives canonicalised on this substrate by the migration: (a) DO-Container placement is independent (do-to-container-cross-region-rtt) — DO-enabled Containers create a Durable Object near the request, but the Container "may spin up on the other side of the world"; for chatty WebSocket workloads, the cross-region distance is paid per-message; (b) Regional pre-warmed DO+Container pair pools (regional-pre-warmed-do-container-pair-pool) are the architectural response — the unit of selection becomes a colocated DO+Container pair within a region. Outcomes: 60 browsers/min via Workers binding, 120 concurrent (4× previous), >50% Quick Action latency drop, WebGL + WebMCP unblocked.
  • sources/2026-01-29-cloudflare-moltworker-self-hosted-ai-agent — Moltbot's Gateway runtime (originally run via Docker on a user's Mac mini) is instead run as a Cloudflare Container in the Moltworker architecture. The ephemeral-by-design property forces the use of mountBucket() for session memory + conversations (mountable-persistent-storage).
Last updated · 766 distilled / 2,225 read