Cloudflare Sandboxes Reaches GA — Designing Custom Development Without In-House AI Agent Execution Environments 2026

"We want agents to execute generated code, but running it directly on internal infrastructure is completely out of the question." "Spinning up VMs for browser-automation agents is causing operational costs to skyrocket." Inquiries regarding agent execution environments (runtimes) have grown significantly since April. This demand aligns with Cloudflare elevating Cloudflare Sandboxes—isolated execution environments with persistent storage for AI agents—to GA (general availability). The sandboxes required when agents execute arbitrary code, manipulate files, and automate browsers can now be offloaded to Cloudflare instead of managed in-house.

This article organizes client architecture guidelines for an era where agents become executors, alongside migration steps from existing sandbox setups (self-hosted K8s, Firecracker, containers).

Why dedicated agent sandboxes are necessary

Running agent-generated code has become a baseline requirement across virtually all enterprise agent projects in 2026. However, executing this code directly on existing enterprise infrastructure is dangerous on multiple fronts.

Building this internally with K8s, Firecracker, dedicated storage, and network isolation requires two to three dedicated infrastructure engineers. Cloudflare Sandboxes manages this entire surface, establishing clear boundaries of responsibility in client delivery.

Overall architectural picture

Our standard architecture for client projects is divided into four layers:

1. Agent layer — Claude / Gemini / OpenAI (hosted on Workers AI or external APIs)
2. Orchestration layer — Workers / Durable Objects, managing tool execution
3. Isolated execution layer (Cloudflare Sandboxes) — Isolated VMs with persistent filesystems
4. Business UI layer — Slack / internal portals / Web UI

All agent tasks—running code, controlling browsers, and saving files—are contained entirely within Sandboxes. The core security principle is that the agent issues instructions from the outside while runtime execution remains locked inside the Sandbox.

5 design guidelines to master in client development

1. Establish clear "Session = Sandbox" mappings

Because Cloudflare Sandboxes feature persistence, they retain prior state across subsequent invocations. The first decision to make in client projects is "what constitutes a sandbox boundary."

Per-user mappings provide richer long-term context but increase data retention obligations. For client projects, per-project mappings often offer the ideal operational balance.

2. Always enforce sanitization at I/O boundaries

Commands and outputs generated by agents inside the Sandbox must always be sanitized before passing to outside systems.

async function runInSandbox(sandboxId: string, code: string) {
  const result = await env.SANDBOX.get(sandboxId).exec({
    language: "python",
    code,
    timeout_ms: 30_000,
    network: "deny",  // デフォルトで外向き通信は拒否
  });
  return {
    stdout: redactSecrets(result.stdout),
    stderr: redactSecrets(result.stderr),
    files: result.files.filter(f => isAllowedPath(f.path)),
  };
}

The key rule is to keep network: "deny" as the default, opening only approved domains via an allowlist. This single safeguard dramatically mitigates SSRF and data exfiltration incidents.

3. Separate intra-session from inter-session storage

While persistent storage in Cloudflare Sandboxes is convenient, failing to organize use cases makes data lifecycles untraceable. In client projects, we categorize storage into three tiers:

• Intra-session (ephemeral): Equivalent to /tmp; destroyed upon session termination
• Inter-session (persistent): Equivalent to /workspace; retained per sandbox
• Persistent storage (external): R2 / KV; saved beyond sandbox lifecycles

Clearly distinguish between files a user will access again in /workspace and deliverables meant to be shared across users in R2.

4. Maintain audit trails across 3 tiers: launch, execution, and file changes

For enterprise clients with compliance requirements, persist the following three tiers to external storage.

- sandbox_id ─┬─ start_event (user_id, project_id, started_at)
              ├─ command_event (cmd, exit_code, duration_ms)
              └─ file_event (path, op, size, hash)

Recording "which conversation executed which code and modified which files" linked directly to conversation_id makes post-incident analysis of PII leaks or erroneous runs significantly faster.

5. Manage costs through timeouts and idle termination

While persistence is valuable, unattended sandboxes can accumulate rapidly. In client development, always implement these two safeguards:

• Command execution timeout: 30 seconds to 5 minutes (depending on use case)
• Automatic idle termination: Destroy sandboxes inactive for 24 hours

These two configurations alone curb monthly cost inflation by 70% to 80%.

Migration steps from existing sandbox infrastructure

For projects that already have their own Firecracker- or K8s-based sandbox infrastructure, a phased migration is safer than an immediate, full-scale switch.

Step 1: Move only new use cases to Cloudflare Sandboxes

Keep existing infrastructure as is, implementing only new agent projects on Cloudflare Sandboxes.

Step 2: Migrate short-lived sandboxes

First migrate task-level disposable sandboxes (code execution, web scraping).

Step 3: Migrate persistent sessions

Switch user-level and project-level sandboxes alongside data migration.

Step 4: Scale down in-house infrastructure

Scale down operations of in-house infrastructure after fully shifting traffic to Cloudflare.

The "separation of responsibilities between execution environments and agents" that we laid out in Sandbox and Memory Operations with OpenAI Agents SDK v2 applies just as effectively to Cloudflare Sandboxes.

Assessing fit — cases where Cloudflare Sandboxes is suitable vs. not suitable

We always verify whether a case is suitable, requires review, or is not suitable during initial client discovery. Proceeding with a PoC based on an incorrect assessment will lead to massive rework down the road.

The browser automation sandbox requirements covered in Guide to Integrating Anthropic Computer Use into Business Operations serve as a prime example when combining with Cloudflare Sandboxes.

Conclusion

In an era where agents take the execution reins, the general availability of Cloudflare Sandboxes provides a practical solution that frees companies from operating their own isolated environments. Here are five key points we focus on in custom development:

1. Establish the session-to-sandbox mapping first
2. Sanitize at input/output boundaries and default-deny network traffic
3. Isolate storage across three tiers: intra-session, inter-session, and external
4. Retain audit trails across three tiers
5. Control costs through timeouts and idle teardown

At GleamHub, we are actively driving agent projects that adopt Cloudflare Sandboxes. If you are struggling with the heavy operational burden of managing your own sandboxes or cannot get sign-off from security teams, please feel free to reach out to us.