cloudflareAug 3, 2026

Your agent needs a computer, not a container — introducing @cloudflare/computer (opens in new tab)

Cloudflare argues that scalable AI agents need their own computer-like environment—filesystem, shell, tools, and execution capabilities—rather than isolated access to ad hoc tools. Its early-preview `@cloudflare/computer` package abstracts across isolates, containers, and browsers while sharing a durable filesystem. The goal is to provide scalable, efficient compute for potentially hundreds of millions or billions of concurrent agents. ## Why Traditional Containers Do Not Scale - Coding agents work best when they can inspect files, run commands, install packages, modify code, and test their changes. - Giving every agent a dedicated container is too resource-intensive for large-scale deployments. - The industry is increasingly demanding CPU compute because agent workloads require substantial execution capacity in addition to GPU-based model inference. - Cloudflare believes agent infrastructure must move beyond conventional container-per-agent architectures. ## Isolates and On-Demand Containers - Cloudflare’s isolates start and stop quickly, scale horizontally, hibernate while idle, and can preserve agent state. - Durable Objects can host the agent loop and invoke containers only when heavier computation is necessary. - This architecture combines: - Isolates for lightweight, scalable coordination and file operations. - Containers for Linux environments, npm, native binaries, and other resource-intensive tasks. - Cloudflare wants to hide the complexity of combining these primitives from application developers. ## A Shared, Durable Filesystem - `@cloudflare/computer` gives each agent a declaratively initialized workspace containing the files and tools needed for its task. - Agents can select the most suitable execution environment: - Isolates for file manipulation, data processing, or Git operations. - Containers for commands requiring Linux, npm, or native binaries. - All environments operate on synchronized copies of the same source filesystem. - The filesystem can work with Git repositories, storage buckets, and arbitrary files. - File operations can be performed through Code Mode or Bash. - Operations are gated, audited, and observable, enabling fine-grained permissions and a record of agent activity. ## Using `@cloudflare/computer` - A workspace can be attached to any Durable Object to provide virtual filesystem and execution capabilities. - Installation uses: ```bash npm install @cloudflare/computer ``` - A `Workspace` is initialized with Durable Object storage and can be connected to an agent framework such as `@cloudflare/think`. - The example describes a bug-triage agent that: - Works in `/workspace/repo`. - Reproduces and investigates bugs. - Applies focused fixes when appropriate. - Runs verification commands. - Reports changes, commands, and verification results. - The package supports multiple execution backends, including Cloudflare Containers, and allows developers to implement custom backends. Cloudflare is presenting `@cloudflare/computer` as an open-source experiment and is seeking feedback from customers building agents at scale. Its practical recommendation is to use isolates as the default execution layer and attach containers only for tasks that genuinely require them, while sharing a controlled, durable workspace across both.

container-sandboxingtypescriptcloudflare-workersdurable-objects+3

figmaOct 23, 2023

Server-side sandboxing: Containers and seccomp | Figma Blog (opens in new tab)

Containers and seccomp provide lightweight alternatives to virtual machines for isolating untrusted server-side workloads. Containers rely on OS-level features such as namespaces, cgroups, privilege dropping, and mandatory access controls, while seccomp restricts which system calls a process can invoke. Figma’s conclusion is that containers are not secure by default: effective sandboxing depends on the runtime, kernel, configuration, and broader infrastructure design. ## Container Isolation and Its Attack Surface - Container escapes depend on three main components: - The container runtime implementation - Operating-system primitives and interfaces exposed to the runtime - Runtime configuration - On Linux, Docker commonly uses the `runC` runtime alongside: - Namespaces and cgroups - Privilege dropping - Seccomp - SELinux or AppArmor - Vulnerabilities in the kernel or runtime, as well as configuration mistakes, can allow malicious workloads to modify host files or execute host-level code. - Unlike many VM solutions, containers place more responsibility on operators to configure isolation correctly. ## Risks from Compromised Containers - Simply running untrusted code inside a container does not guarantee safety. - Container settings should be strengthened to prevent host takeover. - The surrounding architecture should limit what a compromised container can access. - A safer design may use containers with: - No mounted network devices - No credentials - No access to unrelated data - Containers can be placed in an isolated network, with orchestration systems passing inputs and collecting outputs through controlled channels. ## Seccomp as an Additional Boundary - Seccomp, or “secure computing mode,” restricts the system calls available to a process. - This can reduce the kernel attack surface available to malicious code running inside a container. - Seccomp works alongside container mechanisms rather than replacing them; isolation depends on combining syscall restrictions with carefully configured namespaces, privileges, access controls, and infrastructure. ## Figma’s Evaluation Criteria Figma assesses sandboxing technologies using two questions: - Can a malicious workload escape its container and affect the host? - If it cannot escape, can it misuse the container’s permissions to reach other systems or cause harm? The practical recommendation is to treat containers as configurable security primitives, not automatically secure sandboxes. Use restrictive seccomp and container configurations, minimize credentials and connectivity, and design the surrounding system so that a compromised workload has limited impact.

container-sandboxingdockerseccompcgroups+4