Agent Sandboxes & Code Execution Arena
Cloudflare Sandboxes vs Vercel Sandbox
Cloudflare Sandboxes
Cloudflare, Inc.
Vercel Sandbox wins · 12–18 (18 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to Vercel SandboxA probe confirms Cloudflare's developer docs expose a working llms.txt (HTTP 200) covering the whole docs site including Sandbox, giving agents a structured entry point. However, a probe for the markdown version of the specific Sandbox get-started page returned 404, showing per-page agent-friendly docs aren't uniformly available. Missing for 10: dedicated llms.txt or .md endpoints scoped to the Sandbox product docs, and no community/hands-on confirmation of agents actually consuming it successfully.
Probes confirm both a working llms.txt at the root domain (vercel.com/llms.txt, HTTP 200) and a markdown-formatted docs endpoint for Sandbox specifically (sandbox.md, HTTP 200), which are exactly the agent-oriented docs formats this story asks for. Missing for 10: no explicit evidence llms.txt itself deep-links to sandbox-specific docs, and no independent/community confirmation of an agent successfully consuming these files.
- [probe] “PROBE llms.txt: HTTP 200 at https://vercel.com/llms.txt # Vercel > Vercel is a cloud platform for building, deploying, and scaling web appl…”
- [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs/sandbox.md --- title: Vercel Sandbox product: vercel url: /docs/sandbox canonical_url: "h…”
- [claimed-docs] “Connect to and manage Sandboxes from the dashboard”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Vercel SandboxCloudflare Sandboxes are SDK/Workers-driven (exec, code execution, git operations, bindings access) which is inherently headless/programmatic and well-suited to CI/CD automation, and docs explicitly mention CI/CD as a target use case. However there's no dedicated CLI, no CI integration examples (GitHub Actions, etc.), and no evidence of auto-cleanup/idle-timeout controls needed for reliable CI runs — community notes explicitly flag the lack of auto-destroy on idle, requiring manual cleanup logic. missing for 10: explicit CI/CD pipeline examples or integrations, a standalone CLI for headless invocation, documented idle-timeout/auto-teardown controls, and independent verification of headless automation at scale.
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
- [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Vercel Sandbox is designed for headless/programmatic use via SDKs (@vercel/sandbox) and a CLI, with access tokens explicitly documented for external CI/CD systems and non-Vercel environments, plus OpenAPI-backed REST access confirmed by probe. missing for 10: no explicit third-party/independent CI pipeline case study or GitHub Actions example demonstrating real-world headless automation.
- [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
- [claimed-docs] “Use access tokens when `VERCEL_OIDC_TOKEN` is unavailable, such as in external CI/CD systems or non-Vercel environments.”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round drawnCloudflare Sandboxesnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnCloudflare Sandboxesnone0/10Cloudflare Sandboxes is an execution/infrastructure SDK (not itself an agent), so an official MCP server for agent connectivity is a fair axis to ask about—but the evidence pack contains no mention of MCP, an MCP server, or any protocol for connecting AI agents beyond raw SDK APIs (exec, files, sessions, tunnels, etc.).
Vercel Sandboxnone0/10Vercel Sandbox is an execution/infrastructure product (not itself an agent), so an official MCP server exposing it to agents is a fair, applicable axis; however no evidence in the pack mentions MCP, an MCP server, or any agent-protocol integration—only SDKs, CLI, and REST/OpenAPI docs are described.
ai-native userUse an official CLI
weight 2 · round to Vercel SandboxCloudflare Sandboxesnone0/10The evidence pack shows the Sandbox SDK is an API/library used from Workers code (exec, files, sessions, etc.) but nowhere mentions an official CLI tool for AI-native workflows; interaction is entirely via SDK calls or the general Wrangler CLI, not a dedicated Sandbox CLI.
Vercel Sandbox ships an official `sandbox` CLI explicitly positioned for manual testing, agentic workflows, debugging, and one-off operations, with documented commands like `sandbox create --name` and `sandbox run`. missing for 10: independent/hands-on corroboration beyond vendor docs, and no CLI reference/full command list shown.
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
- [claimed-docs] “sandbox run echo "Hello Sandbox!"”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
ai-native userDrive the product through a documented public API
weight 3 · round to Vercel SandboxCloudflare publishes extensive, structured API documentation for the Sandbox SDK (exec, file I/O, sessions, code interpreter, ports/tunnels, watch, snapshots, git, Docker, bindings) explicitly marketed for building AI agents that execute code (docs-24, docs-34). The docs are machine-readable (llms.txt, openapi.json probes return 200) and cover the full surface an AI-native developer would need to drive. missing for 10: independent hands-on confirmation that agents successfully integrate via this API in production, and a dedicated REST/OpenAPI spec for the sandbox endpoints themselves (only the SDK is documented, not a standalone HTTP API schema).
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
- [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
Vercel Sandbox is explicitly built for agentic/AI use cases and exposes a documented SDK (@vercel/sandbox), CLI, and REST API (openapi.json) for programmatic control—creating sandboxes, running commands, streaming logs, managing files, images, and persistence. This directly satisfies driving the product via a documented public API for AI-native workflows. Missing for 10: independent third-party corroboration beyond vendor docs/probe checks.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs/sandbox.md --- title: Vercel Sandbox product: vercel url: /docs/sandbox canonical_url: "h…”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnCloudflare Sandboxesnone0/10The evidence pack documents sandbox execution, filesystem, networking, and session features but contains no mention of scoped or least-privilege API credential/token issuance for agents accessing the sandbox APIs; in fact, community feedback notes egress control is 'all or nothing' rather than fine-grained, suggesting limited scoping capability overall.
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
Vercel Sandboxnone0/10Evidence only describes authentication mechanisms (automatic OIDC token in production, access tokens for CI/CD) but nowhere documents scoped or least-privilege permission models for these credentials — no mention of granular scopes, role restrictions, or per-agent credential limits.
- [claimed-docs] “In production on Vercel, authentication is automatic.”
- [claimed-docs] “Use access tokens when `VERCEL_OIDC_TOKEN` is unavailable, such as in external CI/CD systems or non-Vercel environments.”
- [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
ai-native userBuild against official SDKs
weight 2 · round to Cloudflare SandboxesCloudflare publishes an extensive official SDK (TypeScript/JavaScript) with detailed docs covering exec, file I/O, sessions, code interpreter for Python/JS, port exposure, snapshots, and bindings, explicitly positioned for building AI agents that execute code. Community commentary discusses pricing/latency but does not dispute the SDK's functionality or documentation quality. Missing for 10: independent hands-on developer reviews of the SDK's ergonomics/reliability, and confirmation of multi-language SDK parity beyond JS/TS/Python.
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
Vercel Sandbox offers an official `@vercel/sandbox` SDK for JS/TS plus a CLI, with docs on authentication, commands, and sandbox lifecycle management — evidence that AI-native builders have a first-party SDK to integrate against. missing for 10: no mention of official SDKs for other languages (e.g., Python), no independent/hands-on corroboration of SDK usage beyond vendor docs.
- [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
- [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnCloudflare Sandboxesnone0/10No evidence anywhere in the pack of a webhook subscription mechanism for sandbox events; the SDK exposes file watching, SSE streams, and callback-based output but nothing about registering external webhook endpoints for event notifications.
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to Cloudflare SandboxesDocs show sandboxes can run background processes, maintain persistent sessions/state, and reconnect via stable IDs (docs-43, docs-9, docs-37, docs-32), which supports basic autonomous background execution. However, there's no documented native scheduling/trigger mechanism for kicking off automations, and community feedback notes the lack of auto-idle cleanup means developers must manually manage sandbox lifecycle rather than it running fully autonomously (comm-7). Missing for 10: built-in cron/trigger scheduling, evidence of true unattended long-running automation, and confirmation that background processes persist reliably without manual intervention.
- [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
- [claimed-docs] “const buildSession = await sandbox.createSession({ id: "build", env: { NODE_ENV: "production" }, cwd: "/build" });”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Vercel Sandbox supports running agent-generated code, detached/background commands with log streaming, timeouts/extension, and persistence/resume, which enable building autonomous background automations. However, there's no built-in scheduler, trigger system, or native 'automation' orchestration layer — users must build their own scheduling/trigger logic around the SDK/CLI. missing for 10: native scheduling/cron or event-trigger mechanism, independent evidence of long-running unattended automations in production, and explicit 'autonomous background job' framing beyond detached commands.
- [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
- [claimed-docs] “Stream logs from a detached command”
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
- [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
ai-native userOperate the product with natural-language commands
weight 2 · round drawnCloudflare Sandboxesnone0/10Cloudflare Sandboxes is a programmatic SDK (sandbox.exec(), writeFile(), createSession(), etc.) intended to be called from Worker code, not a product with a natural-language command interface; while it markets itself for building AI agents (docs-24), there is no evidence of a chat/NL layer for operating the sandbox itself. missing for 10: any NL command parsing/interface, evidence of a conversational control layer, examples of natural-language-driven sandbox operations.
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”
Vercel Sandboxnone0/10Vercel Sandbox is designed to run agent-generated code and is explicitly marketed for 'agent workflows,' but the evidence only describes CLI commands (`sandbox create`, `sandbox run`) and SDK calls, not a natural-language interface for operating the product itself. No documentation shows a chat/NL command layer for creating or managing sandboxes. Missing for 10: any NL command parser, chat-driven CLI, or natural-language API for controlling Sandbox operations.
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
- [claimed-docs] “sandbox run echo "Hello Sandbox!"”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnCloudflare Sandboxesnone0/10The evidence pack shows extensive static code snippets across Cloudflare's Sandbox docs (exec, file I/O, sessions, interpreter, etc.) but nothing indicates an interactive, in-browser 'try it now' API reference or runnable playground — the openapi.json probe is for Cloudflare's general API, not a Sandbox-specific interactive explorer. Missing for 10: an in-page runnable code sandbox/playground, an interactive API explorer (e.g., Swagger/Redoc try-it-out), or any embedded live execution environment tied to the docs.
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “import pandas as pd data = {'product': ['A', 'B', 'C'], 'sales': [100, 200, 150]} df = pd.DataFrame(data) df['sales'].sum() # Last expressi…”
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/sandbox/get-started/.md”
Vercel Sandboxnone0/10Evidence shows Vercel has an OpenAPI spec and Sandbox docs, but nothing describes an interactive API reference with runnable/live examples for Sandbox itself — no docs playground, no 'try it' console, no runnable code snippets in-page. missing for 10: interactive API reference UI, runnable example execution in docs, evidence of a docs playground feature.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to Vercel SandboxCloudflare's developer platform exposes a general openapi.json (HTTP 200, containing an 'openapi' key), but there's no evidence this spec specifically documents the Sandbox SDK's methods (exec, writeFile, sessions, etc.), which is a code-level SDK rather than a REST API; a dedicated machine-readable doc for the sandbox pages itself returned 404. Missing for 10: confirmation that the openapi.json actually covers Sandbox-specific endpoints/methods, and a dedicated llms.txt/OpenAPI export scoped to the Sandbox SDK docs.
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/sandbox/get-started/.md”
- [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
A probe confirms Vercel publishes a machine-readable OpenAPI spec at https://vercel.com/openapi.json which validly contains the 'openapi' key, and Sandbox is part of Vercel's documented API/SDK surface. Missing for 10: no explicit confirmation that Sandbox-specific endpoints are included in that spec versus general Vercel API.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to Vercel SandboxCloudflare Sandboxes are explicitly designed as isolated VM/container environments for running untrusted code, separate from production infra, with sessions, snapshots, and opt-in bindings to access KV/R2/Durable Objects only when explicitly wired in — matching the AI-native 'test without touching production' need well (docs-34, docs-38, docs-50, docs-20, docs-24). Community feedback doesn't contradict the isolation guarantee itself, though it flags coarse outbound network controls and unclear persistence semantics as caveats (cloudflare-sandbox-comm-2, cloudflare-sandbox-comm-4). Missing for 10: independent hands-on validation that no production data leakage occurs in practice, and finer-grained egress/network isolation controls.
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
- [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
- [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
Vercel Sandbox is explicitly designed to run untrusted/agent-generated code in isolated Linux microVMs 'without exposing your production systems,' with per-agent isolation, ephemeral or persistent state, and no shared access to production infrastructure. This directly matches the AI-native story of testing agent code safely away from production data. missing for 10: independent/hands-on evidence of real-world isolation guarantees, and explicit documentation on data-boundary controls preventing production data leakage into sandboxes.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnCloudflare Sandboxesnone0/10The evidence pack contains extensive API documentation for the Sandbox SDK's features (exec, files, sessions, snapshots, etc.) but nowhere mentions API versioning schemes, version numbers, or a documented deprecation policy for the SDK/API surface. No evidence of semver commitments, changelogs with deprecation notices, or migration guides for breaking changes.
Vercel Sandboxnone0/10The evidence pack shows SDK/CLI docs, features, and an OpenAPI spec, but no mention of API versioning scheme or a documented deprecation policy for Vercel Sandbox's APIs. Some features are explicitly marked 'beta' (docs-14, docs-44), suggesting instability without a stated deprecation process. missing for 10: explicit API version numbers, a deprecation/sunset policy, changelog entries documenting breaking-change handling.
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to Cloudflare SandboxesCloudflare Sandboxes supports concurrent/parallel operations via a multiplexed connection that 'avoids subrequest limits when making many concurrent operations' (docs-17) and allows multiple isolated sessions per sandbox for parallel workflows (docs-9, docs-18, docs-39), plus getSandbox() to manage many sandbox instances by ID. However there's no documented batch/bulk API primitive for iterating over large item sets, and community feedback flags unclear resource limits and high per-vCPU pricing that would constrain large-scale bulk workloads (comm-3, comm-6, comm-11). Missing for 10: an explicit bulk/batch operation API or example, documented concurrency/resource ceilings, and independent evidence of successful large-scale parallel execution.
- [claimed-docs] “Multiplexes all SDK calls over a single persistent connection. It avoids subrequest limits when making many concurrent operations.”
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
- [claimed-docs] “Create additional sessions for separate workflows in the same sandbox:”
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
- [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
- [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
- [community] “I am keen to understand how I would limit sandbox resource usage.”
Vercel Sandboxnone0/10Vercel Sandbox docs describe creating/running individual sandboxes, multi-agent isolation, and SDK-driven command execution, but there is no evidence of a bulk/batch operation feature for processing many items at once (e.g., batch job APIs, fan-out orchestration, or bulk file/task processing).
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Cloudflare SandboxesThe SDK provides a file-system watch capability with an `onEvent` callback (inotify-based) that lets developers trigger custom actions when files change, which is a form of event-driven automation, but this is a narrow, code-level primitive rather than a declarative rules/automation engine. Missing for 10: no declarative rule-definition mechanism, no support for triggering on non-filesystem events (e.g., scheduled/cron, external webhooks, custom event types), and no evidence of a rules/condition-action system beyond raw watcher callbacks.
- [claimed-docs] “Monitor real-time filesystem changes using native inotify. Build development tools, hot-reload systems, and responsive file processing.”
- [claimed-docs] “const watcher = await sandbox.watch('/workspace/src', { include: ['*.js', '*.ts'],”
- [claimed-docs] “const watcher = await sandbox.watch('/workspace/src', { include: ['*.js', '*.ts'], onEvent: (event) => {”
ai-native userSchedule recurring jobs or workflows
weight 2 · round drawnCloudflare Sandboxesnone0/10The evidence describes on-demand sandbox execution, sessions, and lifecycle management, but nowhere mentions cron-style scheduling, recurring triggers, or workflow orchestration for repeated runs; community threads even highlight the lack of automatic idle/cleanup logic, implying no built-in scheduling primitives.
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Vercel Sandboxnone0/10Vercel Sandbox provides on-demand ephemeral/persistent execution environments with manual creation, timeouts, and resumption, but no evidence of a scheduler, cron-like trigger, or recurring job orchestration feature; scheduling would need to be built externally (e.g., Vercel Cron) which isn't documented here as part of Sandbox itself.
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
- [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”
ai-native userVersion, review, and roll back my automations
weight 1 · round to Cloudflare SandboxesSandboxes offer git clone/branch operations for code and R2-based directory snapshot/restore, which give raw building blocks for versioning and rolling back sandbox state, but there is no dedicated 'automation' versioning, review, or rollback UI/workflow — it's up to the developer to wire this together. Missing for 10: no built-in review/diff tooling for automations, no automatic rollback trigger, no evidence of a workflow-specific version history feature, and no independent confirmation these primitives are actually used for automation rollback in practice.
- [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
- [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
- [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
- [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
Capabilities hardware — stories about capabilities hardware in this arenaCapabilities hardware
Stories about capabilities hardware in this arena
Agent workloads
ai-native userRun coding agents like Claude Code or Codex inside the sandbox following the vendor's own recipe
weight 2 · round to Vercel SandboxCloudflare Sandboxesnone0/10The docs describe Sandboxes as ideal for building AI agents and provide generic exec/git/docker primitives, but there is no vendor-published recipe or guide specifically for running Claude Code or Codex inside a Sandbox. missing for 10: an explicit vendor tutorial/recipe naming Claude Code or Codex, any first-party integration guide, and community confirmation that such agents run inside the sandbox.
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “Run Docker commands inside a sandbox container.”
- [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
Docs confirm the default 'vercel/sandbox/universal' image ships with coding agents preinstalled and highlight agent workflows (e.g. Claude Code/Codex-style use), but the evidence pack lacks an explicit vendor 'recipe' walkthrough naming Claude Code or Codex step-by-step. missing for 10: a dedicated vendor tutorial/recipe explicitly running Claude Code or Codex inside the sandbox, and independent hands-on confirmation of this exact workflow.
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
Workloads
developerRun a headless browser or full desktop environment inside the sandbox
weight 2 · round drawnCloudflare Sandboxesnone0/10The evidence pack details shell execution, file I/O, sessions, tunnels, snapshots, and code interpretation, but nowhere mentions running a headless browser (e.g., Playwright/Puppeteer) or a full desktop/GUI environment inside the sandbox. This is a reasonable capability to ask of a code-execution sandbox product, but no docs or community evidence confirm it exists.
Vercel Sandboxnone0/10Evidence describes Linux microVMs, custom OCI images, and general code execution, but nothing mentions headless browser support, display/VNC, GUI desktop environments, or browser automation tooling. missing for 10: any mention of headless browser (e.g., Chromium/Playwright) support, GPU/display capabilities, or desktop environment provisioning.
developerAttach GPUs to sandboxed workloads
weight 2 · round drawnCloudflare Sandboxesnone0/10No evidence anywhere in the docs or community discussion mentions GPU support, GPU attachment, or GPU-accelerated workloads for Cloudflare Sandboxes; the product is described purely in terms of CPU-based containers/VMs for code execution.
Vercel Sandboxnone0/10No evidence anywhere in the docs mentions GPU support or GPU attachment for Vercel Sandbox; sandboxes are described only as CPU-based Linux microVMs with system-privileged process support, storage/drives, and networking. missing for 10: any mention of GPU hardware, GPU-enabled images, or GPU pricing/quota.
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
- [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
Code execution — stories about code execution in this arenaCode execution
Stories about code execution in this arena
Files
developerRead, write, upload, and download files in the sandbox filesystem via the SDK
weight 2 · round to Cloudflare SandboxesDocs explicitly cover readFile/writeFile/mkdir with absolute paths, streaming/binary uploads >32MiB via ReadableStream, and directory watching, giving comprehensive first-party coverage of file read/write/upload/download via the SDK. Missing for 10: independent hands-on developer confirmation of file upload/download behavior (community discussion focuses on persistence questions, not concrete failures).
- [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
- [claimed-docs] “This allows binary data and files greater than 32 MiB to be written to the sandbox. It replaces the "base64" encoding option.”
- [claimed-docs] “the writeFile() method supports passing a ReadableStream as the content parameter. This allows binary data and files greater than 32 MiB”
- [claimed-docs] “Read, write, and manage files in the sandbox filesystem. All paths are absolute (e.g., `/workspace/app.js`).”
- [claimed-docs] “the `writeFile()` method supports passing a `ReadableStream` as the `content` parameter.”
- [claimed-docs] “await sandbox.mkdir('/workspace/project/src', { recursive: true });”
Docs confirm the SDK provides a programmatic interface to manage files (mount remote storage, drives, filesystem persistence via snapshots) and general file access is implied through 'file edits' and FUSE-mounted storage, but no explicit documentation of discrete SDK methods like sandbox.writeFiles(), readFile(), or upload/download APIs is present. missing for 10: explicit SDK method documentation/examples for read, write, upload, and download file operations, and independent/hands-on confirmation of these specific API calls.
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “Mount an external object store such as Amazon S3 with a FUSE driver, and read and write remote files through the sandbox filesystem.”
- [claimed-docs] “Drives (beta): Attach persistent filesystem storage to sandboxes and reuse data across sandbox runs.”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
Runtimes
developerDefine custom sandbox templates or bring my own container image
weight 2 · round to Vercel SandboxCloudflare Sandboxesnone0/10The evidence describes running commands, files, sessions, Python/JS execution, tunnels, and Docker-command execution inside a sandbox, but nothing documents defining a custom sandbox template or supplying a custom base container image for the sandbox environment itself. Since bring-your-own-image is a standard, expected axis for a container/sandbox product, the lack of any supporting evidence yields 'none' rather than 'na'.
- [claimed-docs] “Run Docker commands inside a sandbox container.”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
Docs explicitly support custom sandbox templates and BYO container images: users can build custom OCI images stored in Vercel Container Registry, start sandboxes from managed, shared/public, or custom images, and Docker-image-based workflows are directly supported. Also supports snapshotting for reusable custom environments. missing for 10: independent/hands-on corroboration of custom image builds beyond first-party docs.
- [claimed-docs] “Build your system packages and tooling into an image, and share it across projects and teams.”
- [claimed-docs] “If you already use Docker images to define your environment, store the image in Vercel Container Registry (VCR) and create the sandbox with …”
- [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
- [claimed-docs] “Managed and custom images: Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel C…”
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
developerExecute code in multiple language runtimes (Python, JavaScript, and more) and get rich results back
weight 2 · round to Cloudflare SandboxesDocs clearly document a code interpreter API executing Python, JavaScript, and TypeScript with rich outputs (charts, tables, dataframes, stateful contexts), plus shell exec with stdout/stderr capture, matching the story directly. Missing for 10: independent/hands-on verification of the rich-output rendering quality and broader language support beyond the three named runtimes.
- [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
- [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
- [claimed-docs] “import pandas as pd data = {'product': ['A', 'B', 'C'], 'sales': [100, 200, 150]} df = pd.DataFrame(data) df['sales'].sum() # Last expressi…”
- [claimed-docs] “Contexts maintain state (variables, imports, functions) across executions.”
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “you'll create a Worker that can execute Python code and work with files in isolated containers.”
Docs confirm sandboxes run Linux images with Python 3.14 and Node.js LTS pre-installed by default, plus support for any other Linux distro via custom OCI images, enabling multi-language execution (JS/TS, Python, and more) (docs-5, docs-8, docs-34, docs-30). Execution results are surfaced via logs, streamed output, and file access (docs-19, docs-20, docs-26), but there's no explicit mention of structured/rich result formats (e.g., images, dataframes, plots) beyond logs and files. Missing for 10: explicit support for rich/structured output types (charts, tables, media) and independent hands-on confirmation of multi-language fidelity.
- [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
- [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
- [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
- [claimed-docs] “Stream logs from a detached command”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
Untrusted code
developerExecute untrusted, AI-generated code without risking my own infrastructure
weight 3 · round to Vercel SandboxCloudflare's docs explicitly market Sandboxes for running untrusted, AI-generated code with VM/container-based isolation, file/exec APIs, and strong security boundaries (cloudflare-sandbox-docs-34, -38, -50, -24). However, hands-on community feedback flags real gaps for this exact use case: outbound network access is 'all or nothing' with no fine-grained egress control, and there's no built-in auto-destroy for idle sandboxes, forcing manual cleanup. Missing for 10: granular network egress control, automatic idle sandbox teardown, independent security audit of the VM isolation claims.
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Vercel Sandbox's docs directly describe running untrusted or AI agent-generated code in isolated Linux microVMs without exposing production systems, with per-agent isolation, configurable timeouts, and managed images—precisely matching the story. Missing for 10: independent/hands-on verification beyond first-party docs.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
developerRun arbitrary shell commands and install packages inside the sandbox
weight 2 · round to Cloudflare SandboxesDocs explicitly document sandbox.exec() for running arbitrary shell commands with stdout/stderr/exit codes, stdin support, streaming/SSE output, background processes, plus Docker command execution and Git operations inside the sandbox, giving developers full shell/package-install capability. Community threads corroborate real-world usage of the sandbox for running containerized workloads, though none specifically contradict shell/package execution. missing for 10: independent hands-on verification of installing arbitrary packages (e.g., apt/pip) beyond docs examples.
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Pass input via stdin (no shell injection risks)”
- [claimed-docs] “Execute a command and return a Server-Sent Events stream for real-time processing.”
- [claimed-docs] “Run Docker commands inside a sandbox container.”
- [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
- [claimed-docs] “stdin - Data to pass to the command's standard input (enables arbitrary input without shell injection risks)”
- [claimed-docs] “onOutput - Callback for real-time output: (stream: 'stdout' | 'stderr', data: string) => void”
- [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
Docs clearly show running arbitrary commands (blocking/detached modes, `sandbox run echo ...`, CLI and SDK) inside Linux microVMs, with custom images and full Linux distros allowing package installs (e.g., Ubuntu/Arch, custom OCI images, system-privileged processes). missing for 10: no independent/hands-on report confirming package installation workflows beyond first-party docs.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
- [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
- [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
- [claimed-docs] “sandbox run echo "Hello Sandbox!"”
- [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
Dev experience — day-to-day developer experience — setup friction, docs, debugging, iteration speedDev experience
Day-to-day developer experience — setup friction, docs, debugging, iteration speed
Agent lifecycle
ai-native userMy agent can provision its own sandbox, execute code, read the results, and tear it down — end to end without a human
weight 3 · round to Vercel SandboxDocs clearly show an agent-driven lifecycle: getSandbox() to provision/reconnect, exec()/interpreter code execution with stdout/stderr capture, and readFile to retrieve results — all callable programmatically without a human in the loop. However, there is no documented explicit 'destroy/teardown' API, and community feedback confirms there's no built-in idle-timeout auto-destroy, forcing developers to implement their own cleanup logic. Missing for 10: a documented sandbox.destroy()/terminate call or auto-expiry mechanism, and independent hands-on confirmation of a full provision-execute-teardown loop working end-to-end.
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
- [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
- [claimed-docs] “Contexts maintain state (variables, imports, functions) across executions.”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Vercel Sandbox provides a full programmatic SDK/CLI to create sandboxes (with names, custom images, regions), run blocking or detached commands, stream logs/output, and stop/tear down sandboxes, with API-based authentication (OIDC/tokens) suitable for unattended agent use — no human-in-the-loop required. missing for 10: no independent/hands-on third-party report confirming an agent autonomously completing the full provision-execute-teardown loop, and no explicit example showing an agent reading command output/results programmatically end-to-end.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
- [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
- [claimed-docs] “Stream logs from a detached command”
- [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
- [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
- [claimed-docs] “sandbox run echo "Hello Sandbox!"”
Isolation security — stories about isolation security in this arenaIsolation security
Stories about isolation security in this arena
Isolation
platform-engineerRely on a documented hard isolation boundary (microVM or equivalent) between sandboxes and my systems
weight 3 · round to Cloudflare SandboxesCloudflare's own docs explicitly state 'VM-based isolation - Each sandbox runs in its own VM' and that each sandbox 'runs in its own isolated container with a full Linux environment, providing strong security boundaries' for running untrusted code (docs-38, docs-50, docs-34). This gives a documented isolation boundary, though the docs mix 'VM' and 'container' language rather than naming a specific microVM technology, and community discussion raises open questions about network egress granularity rather than disputing the isolation claim itself. Missing for 10: a clearer, consistent technical description of the isolation mechanism (e.g., naming Firecracker or similar) and independent third-party security audit/corroboration.
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
Vercel's first-party docs repeatedly and explicitly claim microVM-based isolation for running untrusted/agent-generated code without exposing production systems, plus additional isolation features (per-agent Linux users, system-privileged process support). However, all evidence is vendor documentation with no independent security audit, third-party penetration test, or technical deep-dive into the underlying microVM technology (e.g. Firecracker) confirming the boundary in practice. missing for 10: independent/third-party verification of the isolation boundary, technical detail on the hypervisor/microVM implementation, and any hands-on security assessment.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
- [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
ai-native userGive an agent a sandbox where host secrets and credentials are unreachable by the code it runs
weight 2 · round to Vercel SandboxCloudflare documents strong process/VM isolation ('VM-based isolation', 'isolated container with a full Linux environment', 'run untrusted code securely in isolated environments') which implies the host's runtime and secrets aren't directly reachable by sandboxed code, and bindings (KV/R2/DO) are explicitly scoped and passed in rather than ambient. However, there is no explicit documentation describing how host secrets/credentials are excluded or scrubbed from the sandbox environment, and community feedback notes only coarse-grained outbound network control ('all or nothing') rather than fine-grained secret/credential access restrictions, leaving open questions about exfiltration vectors. Missing for 10: explicit documentation on secret/credential isolation guarantees, independent security audit or hands-on test confirming host credentials are unreachable, and finer-grained egress/network controls to prevent secret exfiltration.
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
- [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
Vercel Sandbox docs explicitly describe running agent-generated/untrusted code in isolated Linux microVMs 'without exposing your production systems,' and support per-agent Linux user isolation, which directly implies host secrets/credentials are not reachable by sandboxed code. missing for 10: explicit documentation of how host secrets/env vars are excluded or scoped from the sandbox environment, and independent/hands-on verification of this isolation guarantee.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
- [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
Network policy
platform-engineerRestrict or allow the sandbox's network egress with explicit policy
weight 3 · round to Cloudflare SandboxesCloudflare Sandboxesdisputedcontradicted3/10Docs mention only a mechanism to 'Intercept and handle outbound HTTP from sandboxes using Workers' (docs-23), which is not the same as a declarative allow/deny egress policy, and no docs describe configurable network egress rules. A named community commenter explicitly states outbound network control is 'all or nothing right now' with no fine-grained control available, directly contradicting the story's requirement for explicit egress policy. missing for 10: documented egress allow/deny policy API, first-party confirmation of granular network restriction, and any independent verification that such a policy exists.
- [claimed-docs] “Intercept and handle outbound HTTP from sandboxes using Workers.”
- [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnCloudflare Sandboxes is an API/SDK-first product with no separate management UI described in the evidence; every capability (exec, file I/O, sessions, git, Docker, port exposure, snapshots, code interpreter, filesystem watch, even the browser terminal) is exposed and built entirely through the SDK/API, and the terminal UI itself is just a WebSocket client wired to the same API. Missing for 10: no explicit statement contrasting a Cloudflare dashboard GUI with the API, and no independent/third-party confirmation that no UI-exclusive controls exist (e.g., resource limits raised as unclear in community threads).
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [claimed-docs] “Connect browser-based terminal UIs to sandbox shells via WebSocket, with the xterm.js SandboxAddon for automatic reconnection and resize han…”
- [claimed-docs] “Run Docker commands inside a sandbox container.”
- [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
- [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
- [community] “I am keen to understand how I would limit sandbox resource usage.”
Vercel Sandbox is fundamentally API/SDK-driven (creation, commands, snapshots, tags, drives, custom images all documented via SDK/CLI), and the dashboard only offers a subset (viewing/stopping sandboxes) that mirrors API capability rather than adding unique UI-only features, and an OpenAPI spec exists confirming programmatic access. Missing for 10: an explicit vendor statement confirming full UI/API parity, and independent confirmation that every dashboard action (e.g., tag/drive management) is scriptable via API with no UI-exclusive features.
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
- [claimed-docs] “Connect to and manage Sandboxes from the dashboard”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
ai-native userExport all of my data in open formats and leave
weight 3 · round to Cloudflare SandboxesThe SDK exposes standard file I/O (readFile/writeFile), S3-compatible bucket mounting (R2/S3/GCS), and snapshot/restore to R2, which are open, non-proprietary formats a user could use to extract their data. However, there is no documented bulk 'export all my data' feature, no account-level portability tooling, and no independent confirmation that a user can fully migrate off the platform with all state intact. missing for 10: explicit data-export/account-portability feature, independent verification of full data extraction, documentation on non-file state (e.g., session/process state) portability.
- [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
- [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
- [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
- [claimed-docs] “Read, write, and manage files in the sandbox filesystem. All paths are absolute (e.g., `/workspace/app.js`).”
- [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
Vercel Sandboxnone0/10Vercel Sandbox stores state via drives, snapshots, and container images, so data portability is a fair question, but no evidence describes an explicit data-export feature or guarantee of open, exportable formats for that stored state. Missing for 10: any documented export/download-all-data capability, explicit open-format guarantees for drives/snapshots, or migration tooling to leave the platform.
- [claimed-docs] “Drives (beta): Attach persistent filesystem storage to sandboxes and reuse data across sandbox runs.”
- [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
- [claimed-docs] “If you already use Docker images to define your environment, store the image in Vercel Container Registry (VCR) and create the sandbox with …”
ai-native userRead the product's source under an open license
weight 2 · round drawnCloudflare Sandboxesnone0/10No evidence in the pack mentions an open-source license or a public source repository for the Cloudflare Sandbox SDK; all citations are product docs, pricing/feature discussions, or probes, none addressing source availability or licensing.
ai-native userSelf-host the core product
weight 3 · round drawnCloudflare Sandboxesnone0/10Cloudflare Sandboxes is built entirely on Cloudflare's proprietary Workers/Durable Objects/container infrastructure, and no evidence in the pack mentions any open-source release, self-hosted deployment option, or ability to run the core product outside Cloudflare's platform. Community discussion focuses on pricing, cold-start times, and resource limits, not self-hosting.
- [claimed-docs] “The SDK supports three transport protocols for communication between the Durable Object and container”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
Vercel Sandboxnone0/10Vercel Sandbox is a fully managed, hosted service running on Vercel's own microVM infrastructure (iad1/sfo1/cle1/cdg1 regions); there is no evidence of any self-hostable core, open-source runtime, or on-prem deployment option — it is inherently tied to Vercel's cloud.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
Performance scale — stories about performance scale in this arenaPerformance scale
Stories about performance scale in this arena
Latency
developerStart sandboxes with documented sub-second-to-few-second cold starts
weight 3 · round drawnCloudflare Sandboxesnone0/10No first-party Cloudflare documentation in the evidence pack states specific cold-start timing (sub-second to few-second) for sandboxes; the community threads discuss competitors' or ambiguous Firecracker boot times without confirming Cloudflare's own documented cold-start figures. missing for 10: official docs quantifying cold-start latency, benchmark data, or a first-party performance page addressing startup time.
- [community] “We rolled out our own that does pretty much the same thing but perhaps more... It does take 1-5 seconds to boot the environment (firecracker…”
- [community] “1-5 seconds seems high for Firecracker, depending on your requirements. We boot VMs (using Firecracker) at ~20-50ms.”
Vercel Sandboxnone0/10The docs describe microVM isolation, snapshotting for faster restarts, and persistence, but no evidence gives concrete cold-start latency figures (e.g., sub-second or few-second boot times) for starting a fresh sandbox. Missing for 10: documented benchmark numbers or explicit cold-start time claims, any independent performance measurement.
- [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
Scale
platform-engineerRun large concurrent fleets of sandboxes with documented concurrency limits
weight 3 · round to Vercel SandboxCloudflare Sandboxesnone0/10Docs describe per-sandbox features (sessions, exec, files) and one architectural note that multiplexing avoids subrequest limits, but there is no documentation of concurrency limits, fleet-level scaling guidance, or how many sandboxes/instances can run concurrently. Community comments explicitly flag unanswered questions about resource limits and lack of auto-cleanup, reinforcing the absence of concrete concurrency documentation.
- [claimed-docs] “Multiplexes all SDK calls over a single persistent connection. It avoids subrequest limits when making many concurrent operations.”
- [community] “I am keen to understand how I would limit sandbox resource usage.”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Docs mention that Sandbox usage is metered and that quotas apply per plan, plus region availability and spend management for cost control, but no concrete documented concurrency limits (e.g., max simultaneous sandboxes) are shown in the evidence. missing for 10: explicit concurrency limit numbers, guidance on running large fleets of sandboxes concurrently, and any performance/scale benchmarks.
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
- [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
- [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”
developerKeep a sandbox session running for hours or days for long agent tasks
weight 2 · round to Vercel SandboxCloudflare Sandboxesdisputedcontradicted5/10Docs describe stable-ID reconnection (getSandbox) and sessions with persistent state/env, suggesting sandboxes could be resumed across long tasks, but community reports explicitly say containers auto-shutdown after idle periods, that there's no built-in idle-timeout control (forcing manual cleanup), and that persistence semantics during idle states are unclear — directly undercutting reliable multi-hour/day continuous operation for unattended agent tasks. Missing for 10: first-party guidance on running sessions continuously for hours/days without disconnection, clear idle-timeout/keep-alive controls, and independent confirmation of long-duration reliability.
- [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
- [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
- [claimed-docs] “You can also set a default command timeout for all commands in a session”
- [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
- [community] “Cloudflares docs are written so hard for web dev. Can you host a monolith app that isn't serving http traffic on cloudflare tech like contai…”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Docs show sandboxes have a default 5-minute timeout that can be explicitly extended via `timeout` option or `sandbox.extendTimeout()`, and persistent sandboxes auto-snapshot on stop so you can quickly resume a long agent task across sessions rather than losing state. However, there's no evidence of an unbounded or multi-day continuous session—developers must actively manage/extend timeouts or rely on stop/resume snapshotting rather than a single always-on session. missing for 10: documented maximum extendable duration or explicit support for a single continuous multi-hour/day session without developer-managed timeout extensions, independent corroboration of long-running stability.
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
- [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
- [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
- [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Pricing
developerStart building with a free tier or included credits without talking to sales
weight 1 · round drawnCloudflare Sandboxesnone0/10The evidence pack documents extensive product capabilities and self-serve pricing figures (e.g., per-vCPU costs debated in community threads) but contains no mention of a free tier, free trial credits, or explicit self-serve signup flow that lets a developer start without contacting sales. missing for 10: explicit free-tier/credit offer, signup flow documentation, confirmation no sales contact is required.
- [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
- [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
Vercel Sandboxnone0/10The evidence pack mentions billing, plans, and quotas (e.g., vercel-sandbox-docs-42, docs-24) but never explicitly states a free tier or included credits usable without contacting sales. Missing for 10: explicit free-tier/plan pricing details, evidence of self-serve signup without sales contact.
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
- [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”
platform-engineerPay per second only for the compute a sandbox actually uses
weight 3 · round to Vercel SandboxCloudflare Sandboxesnone0/10No documentation in the evidence pack describes per-second or usage-based billing for sandbox compute; the only pricing-related evidence is community commentary describing flat, expensive per-vCPU pricing (comm-3, comm-6) and the absence of automatic idle shutdown, meaning engineers must build their own cleanup to avoid being billed for idle sandboxes (comm-7). This contradicts rather than supports the story of paying only for actual per-second compute use.
- [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
- [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Docs confirm Sandbox usage is metered on a pricing page with configurable timeouts and spend-management alerts to control costs, implying granular, usage-based billing, but no evidence explicitly states billing is charged 'per second' of compute used. missing for 10: explicit per-second billing granularity documentation, real-world billing statement/invoice examples showing sub-minute metering.
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
- [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to Vercel SandboxCloudflare Sandboxesnone0/10No evidence in the pack discusses data residency, region selection, or storage location controls for Cloudflare Sandboxes; docs focus on execution, files, sessions, tunnels, and R2 snapshots without any region/residency configuration options mentioned.
Docs confirm region selection (iad1, sfo1, cle1, cdg1) can be set per sandbox or as a project default, giving users some control over where sandboxes execute, and one changelog note claims availability 'in all regions.' However, there is no explicit data residency/compliance guarantee, no mention of where persistent Drives/snapshots/data-at-rest are stored, and no discussion of data sovereignty controls beyond compute region choice. missing for 10: explicit data-at-rest residency guarantees, compliance/certification details tied to region choice, documentation on storage location for Drives/snapshots, and independent confirmation of region enforcement.
- [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
- [claimed-docs] “Vercel Sandbox is now available in all regions”
ai-native userControl data retention and deletion
weight 2 · round drawnCloudflare Sandboxesnone0/10The docs describe file read/write, snapshot/restore to R2, and bucket mounting, but there is no documented mechanism for users to control data retention windows or guarantee deletion of sandbox data. Community evidence explicitly states 'it does not seem to be possible to auto destroy a sandbox after certain amount of idle time... forces whoever is implementing this to do their own cleanup,' and persistence semantics are described as unclear, indicating the product does not provide the retention/deletion controls an AI-native user would need.
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
- [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
- [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
- [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
Vercel Sandboxnone0/10Docs describe sandbox lifecycle (timeouts, stopping, persistence, snapshots) but there is no explicit statement about data retention policies, deletion guarantees, or privacy controls for stored sandbox data/drives. missing for 10: explicit data retention policy, explicit deletion/purge controls, privacy/compliance documentation for stored data.
- [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnCloudflare Sandboxesnone0/10No evidence in the pack addresses telemetry, usage tracking, or opt-out settings for Cloudflare Sandboxes; docs focus purely on execution, filesystem, sessions, and networking features. This is a fair privacy-posture question for a developer platform product, so absence of evidence yields 'none' rather than 'na'.
Provisioning lifecycle — creating, updating, and tearing down resources across their lifecycleProvisioning lifecycle
Creating, updating, and tearing down resources across their lifecycle
Lifecycle
developerSet timeouts so sandboxes shut down automatically and stop billing when idle or done
weight 2 · round to Vercel SandboxCloudflare Sandboxesdisputedcontradicted3/10Docs only describe a per-command timeout within sessions (cloudflare-sandbox-docs-19), not an idle-shutdown/auto-destroy mechanism for the whole sandbox tied to billing; one community comment claims the underlying Container platform auto-shuts down after no requests (cloudflare-sandbox-comm-5), but a hands-on developer explicitly states it does not seem possible to auto-destroy a sandbox after an idle period, forcing manual cleanup (cloudflare-sandbox-comm-7). This is a direct contradiction between vendor-adjacent claims and hands-on experience. Missing for 10: explicit first-party docs on idle-timeout auto-shutdown/destroy tied to billing, and independent confirmation it works as described.
- [claimed-docs] “You can also set a default command timeout for all commands in a session”
- [community] “Cloudflares docs are written so hard for web dev. Can you host a monolith app that isn't serving http traffic on cloudflare tech like contai…”
- [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
Docs explicitly state sandboxes have a default 5-minute timeout, configurable via the `timeout` option at creation, extendable via `sandbox.extendTimeout()`, and can be manually stopped from the dashboard, directly supporting automatic shutdown to stop billing when idle or done. Missing for 10: independent/hands-on confirmation that billing actually stops immediately upon timeout, and documentation of any maximum timeout limits or edge cases.
- [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
- [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
- [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
- [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
developerSpin up an isolated sandbox with one API/SDK call and get a live environment in seconds
weight 3 · round drawnDocs show a single call (getSandbox()) creates or reconnects to an isolated VM/container sandbox with immediate access to exec, file, and session APIs (docs-37, docs-38, docs-50), and community discussion corroborates boot times in the 1-5 second range consistent with 'seconds' provisioning (comm-1, comm-8). Missing for 10: an independent benchmark or first-party latency SLA confirming consistent sub-few-second cold starts across load, since community notes it's slower than some Firecracker-based competitors.
- [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
- [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
- [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
- [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
- [community] “We rolled out our own that does pretty much the same thing but perhaps more... It does take 1-5 seconds to boot the environment (firecracker…”
- [community] “1-5 seconds seems high for Firecracker, depending on your requirements. We boot VMs (using Firecracker) at ~20-50ms.”
Docs show a clear SDK/CLI path (`@vercel/sandbox`, `sandbox create`/`sandbox run`) to spin up isolated Linux microVMs, with fast startup via managed images or snapshots that skip dependency installation, matching the 'one call, live environment in seconds' story. Missing for 10: independent/hands-on timing benchmarks confirming 'seconds' latency and third-party corroboration beyond first-party docs.
- [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
- [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
- [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
- [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
- [claimed-docs] “sandbox run echo "Hello Sandbox!"”
- [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
- [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
Preview access
developerExpose a port from the sandbox on a public preview URL to reach services running inside
weight 2 · round to Cloudflare SandboxesDocs explicitly describe exposing a sandbox port and getting a public preview URL, including zero-config *.trycloudflare.com URLs via sandbox.tunnels.get(port) and Worker-side routing of HTTP/WebSocket requests to the correct sandbox container, directly matching the story. Missing for 10: independent/hands-on confirmation of preview URL reliability beyond first-party docs.
- [claimed-docs] “Expose services running in the sandbox via preview URLs. Access web servers and APIs from the internet.”
- [claimed-docs] “Expose services on zero-config `*.trycloudflare.com` URLs via `sandbox.tunnels.get(port)`. Best for quick development and `.workers.dev` dep…”
- [claimed-docs] “Expose a port and get a preview URL for accessing services running in the sandbox.”
- [claimed-docs] “Expose services on zero-config `*.trycloudflare.com` URLs via `sandbox.tunnels.get(port)`.”
- [claimed-docs] “Expose services running in your sandbox via public preview URLs.”
- [claimed-docs] “Route incoming HTTP and WebSocket requests to the correct sandbox container.”
Docs mention running dev servers with 'live previews' and testing agent-generated code with access to 'live previews', implying some port-exposure/public-URL capability, but no evidence pack item describes the actual API/CLI mechanism (e.g., a domain/getUrl method, port argument, or URL format) for exposing a sandboxed port publicly. missing for 10: explicit documentation of the port-exposure API or CLI command, example of the resulting public URL, and confirmation of access control/authentication on that URL.
- [claimed-docs] “Run development servers: Spin up and test applications with live previews.”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
- [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self”
Snapshot persistence — stories about snapshot persistence in this arenaSnapshot persistence
Stories about snapshot persistence in this arena
Snapshots
developerPause a running sandbox and resume it later with filesystem and memory state intact
weight 2 · round to Vercel SandboxDocs confirm directory-level snapshot/restore to R2 ('Create point-in-time snapshots of directories and restore them from R2') and idle-state persistence claims, giving filesystem-level pause/resume support, but there's no documented mechanism for preserving in-memory/process execution state across a pause, and community discussion notes ambiguity about exactly how idle-state persistence works. missing for 10: explicit memory/process-state preservation on pause, clear docs on what 'idle state' persistence actually preserves, independent verification that restored sandboxes resume mid-execution rather than just filesystem contents.
- [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
- [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
- [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
- [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
Docs explicitly describe persistent sandboxes that auto-save filesystem state on stop and resume where left off by default, with configuration preserved across sessions, plus explicit snapshotting to skip dependency reinstallation and resuming an existing sandbox by name. This directly matches the pause/resume-with-state story via first-party documentation. Missing for 10: independent hands-on verification that memory/process state (not just filesystem) is preserved across pause/resume, and no third-party corroboration beyond vendor docs.
- [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
- [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
- [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”
- [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
- [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
developerSnapshot a sandbox and later restore or fork new sandboxes from that snapshot
weight 3 · round to Vercel SandboxDocs confirm directory-level snapshot/restore via R2 (docs-8, docs-48), but there's no evidence of forking new independent sandbox instances from a snapshot — only restoring a directory's state, and community reports flag ambiguity in how persistence/restore actually behaves (comm-4). missing for 10: explicit 'fork sandbox from snapshot' API, clarity on full sandbox-state (not just directory) restoration, and independent confirmation that restore reliably recreates a working sandbox.
- [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
- [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
- [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
Vercel Sandbox docs clearly describe automatic snapshotting of a sandbox's filesystem/state on stop and restoring it on resume, with named sandboxes resumable and snapshots speeding up subsequent runs by skipping setup. However, the evidence only shows resuming the *same* sandbox from its own snapshot, not explicitly forking multiple independent new sandboxes from one saved snapshot. Missing for 10: explicit support/documentation for forking multiple new sandboxes off a single snapshot, and any hands-on/independent confirmation of this fork workflow.
- [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
- [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
- [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
- [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”
- [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
Not comparable on these axes
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableCloudflare Sandboxesn/aCloudflare Sandboxes is a code-execution/infrastructure primitive (VM-isolated containers, file I/O, command exec) for building agents or apps, not a product with its own dataset or built-in AI insight/suggestion features over user data. The evidence pack shows only execution/session/file/tunnel APIs — no AI-generated insights or analysis output is a first-party product feature, making this axis a category mismatch rather than a gap.
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableCloudflare Sandboxesn/aCloudflare Sandboxes is an infrastructure/execution-environment product (isolated containers/VMs for running code, files, commands) used by developers to build agents, not a product that itself ships a built-in AI assistant UI for end users to delegate tasks to. The 'delegate tasks to a built-in AI assistant' story is a category error for this kind of infra tool.
- [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
- [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableCloudflare Sandboxesn/aCloudflare Sandboxes is a developer infrastructure product for running isolated code execution environments, not a consumer-facing AI assistant/chat product with a data-training opt-out policy; the evidence covers execution, filesystem, networking, and architecture features but nothing about AI model training data usage or opt-out controls. This axis is a category error for this product type.
Vercel Sandboxn/aVercel Sandbox is a code-execution/microVM infrastructure product, not an AI model or AI-training data product; 'preventing data from being used to train AI models' is a data/privacy-policy axis for AI model providers, not for a sandbox execution service. This story is a category error for this product type.