Agent Sandboxes & Code Execution Arena
Cloudflare Sandboxes vs Maritime
Cloudflare Sandboxes
Cloudflare, Inc.
Cloudflare Sandboxes wins · 18–14 (16 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 MaritimeA 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.
Maritime hosts a live llms.txt (confirmed by a 200 probe) plus a dedicated CLI llms.txt and an ai-agents docs page explicitly designed for agents (Claude Code, Cursor, etc.) to consume, authenticate, and act on — directly matching the story. Missing for 10: no independent third-party confirmation that agents actually navigate these docs successfully in practice.
- [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
- [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to MaritimeCloudflare 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…”
Maritime provides a CLI with --json flag on every command, machine-readable output, stable exit codes, and env-var (non-interactive) authentication via MARITIME_TOKEN, explicitly designed for automation/CI use and control by other AI agents rather than humans, plus a RESTful API and idempotent provisioning for scripted workflows. This directly supports headless/CI operation across CLI and SDK/API paths. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions/GitLab CI snippet) or independent third-party confirmation of CI usage.
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
- [claimed-docs] “Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOKEN`. Keys never expire; browser-login tokens do.”
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
- [probe] “official CLI documented at https://maritime.sh/docs/cli”
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.)
Maritimenone0/10Maritime is a platform for deploying and hosting agents built with frameworks (CrewAI, LangGraph, etc.), but the evidence pack shows no mention of MCP server integration or a mechanism for agents to consume external MCP tool servers. Nothing describes plugging in MCP servers to extend tool use.
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.).
Maritimenone0/10Maritime is a platform for deploying/hosting agents (not itself an agent), so an official MCP server is a fair axis to expect, but no evidence pack item mentions MCP, an MCP server, or MCP-compatible endpoints — only REST API, CLI, SDKs, and webhooks are documented.
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
ai-native userUse an official CLI
weight 2 · round to MaritimeCloudflare 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.
Maritime ships an official npm-installable CLI explicitly designed for AI-native use: machine-readable/--json output on every command, stable exit codes, a self-describing contract, and env-var (non-interactive) authentication via MARITIME_TOKEN, all documented at /docs/cli and /docs/ai-agents. It also supports agent-driven install/auth/deploy flows via prompted assistants. Missing for 10: independent/hands-on verification beyond vendor docs.
- [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
- [claimed-docs] “npm install -g maritime-cli”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
- [probe] “official CLI documented at https://maritime.sh/docs/cli”
ai-native userDrive the product through a documented public API
weight 3 · round drawnCloudflare 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”
Maritime documents a full public API (REST endpoints, TypeScript/Python SDKs, idempotent provisioning, webhooks, scoped bearer-token auth) plus a CLI explicitly built for AI agents with machine-readable JSON output and stable exit codes, directly enabling AI-native driving of the platform. missing for 10: a discoverable machine-readable spec (openapi.json/swagger.json returned 404) and independent third-party corroboration of the API's stability.
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
- [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
- [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
- [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to MaritimeCloudflare 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…”
Maritime documents scoped API keys explicitly: every key carries scopes, users should hand subsystems the narrowest key they need, and a dedicated example shows a Computers-only key being refused on all other endpoints — a concrete least-privilege mechanism. This pairs with CLI/env-based key minting (mk_ tokens) suited to agent automation. Missing for 10: an exhaustive scope catalog/reference and independent (non-vendor) verification of scope enforcement in practice.
- [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
- [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”
- [claimed-docs] “Every key carries scopes. Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”
- [claimed-docs] “a key whose only scope is `computers` is refused on every other Maritime endpoint”
- [claimed-docs] “Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”
- [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
- [claimed-docs] “Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOKEN`. Keys never expire; browser-login tokens do.”
ai-native userBuild against official SDKs
weight 2 · round drawnCloudflare 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.”
Maritime documents official TypeScript and Python SDKs with idempotent agent provisioning, scoped authentication, webhooks, messaging, and a Files API, plus an npm-installable CLI and RESTful API, all clearly aimed at building AI-native integrations. missing for 10: no public OpenAPI/swagger spec found (404s) and no independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
- [claimed-docs] “Give every one of your users their own agent with the TypeScript or Python SDK.”
- [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “The Maritime Files API: eight endpoints and both SDKs to browse, upload, download, and edit an agent's disk over HTTP, even while the agent …”
- [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
ai-native userSubscribe to events via webhooks
weight 2 · round to MaritimeCloudflare 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.
Docs explicitly describe subscribing a URL to receive signed JSON POSTs on every agent lifecycle event, replacing polling, which directly matches the story. missing for 10: independent/hands-on confirmation of webhook delivery reliability, payload schema details, and signature verification specifics.
- [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
- [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to MaritimeDocs 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…”
Maritime provides cron triggers with standard five-field expressions that wake agents on schedule and deliver prompts, plus agents can self-schedule their own wake triggers (e.g., 'send me a digest every weekday at 9'), and agents run persistently on always-on micro-VMs with sleep/wake economics, enabling true background autonomous automation. Missing for 10: independent/hands-on verification of trigger reliability and no mention of monitoring/alerting on automation failures.
- [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
- [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
- [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
- [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
- [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”
ai-native userOperate the product with natural-language commands
weight 2 · round to MaritimeCloudflare 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.”
Maritime documents natural-language operation at the agent level (chat with agents, cron-triggered prompts set via natural language like 'send me a digest every weekday at 9') and CLI/API designed to be driven by AI agents via prompts (paste a prompt into Claude/Cursor to install and operate). However, the core Maritime platform itself (dashboard, agent management) is not shown to be operable purely via natural-language commands by the end user — the NL interface is mediated through the CLI/API being agent-friendly rather than a native NL command surface for platform operations. missing for 10: evidence of a native NL interface for platform-level operations (not just agent chat/prompts), independent/hands-on confirmation of this workflow succeeding.
- [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
- [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
- [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “point Claude Code or your Maritime agent at a provider's runbook page and it can inventory the old provider with read-only credentials, recr…”
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”
Maritimenone0/10Docs describe a RESTful API and CLI but there's no evidence of an interactive API reference (e.g., Swagger/OpenAPI explorer) with runnable examples; probes explicitly show no openapi.json/swagger.json spec found at any candidate path. missing for 10: interactive API console/playground, OpenAPI spec, runnable code examples in docs.
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to Cloudflare SandboxesCloudflare'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…”
Maritimenone0/10Maritime documents a RESTful API and CLI with --json output, but there is no evidence of a downloadable machine-readable spec (OpenAPI/Swagger); active probes for openapi.json, swagger.json, and similar paths all returned 404.
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to Cloudflare SandboxesCloudflare 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 …”
Maritimenone0/10Maritime's docs cover deployment, keys/scopes, templates, triggers, and agent lifecycle, but nothing describes a sandbox/staging environment isolated from production data for testing purposes. Missing for 10: any mention of a sandbox/test mode, staging environment, or data isolation guarantees between test and production agents.
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.
Maritimenone0/10No evidence of API versioning scheme (e.g., v1/v2 paths) or any documented deprecation policy; OpenAPI spec probes all 404, and no docs mention version support windows or breaking-change policy.
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
- [claimed-docs] “RESTful API for managing agents programmatically.”
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.”
There is explicit support for bulk import of config/env vars (maritime-docs-11) and a scriptable CLI/API with JSON output (maritime-docs-9, maritime-docs-36) that an AI-native user could loop over to perform bulk actions, but there is no documented batch/bulk endpoint for operating on many agents or resources at once. missing for 10: a dedicated bulk-operation API/CLI command (e.g. bulk create/delete/update agents), evidence of scaling to many items reliably, and independent confirmation of bulk workflows in practice.
- [claimed-docs] “Bulk import from a .env file (or stdin), then hot-reload”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to MaritimeThe 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) => {”
Maritime supports triggers (cron with five-field expressions, natural-language schedule setting, webhooks for lifecycle events) that wake agents and fire actions automatically, which covers rule-based automation on events. However, this is event/schedule-based triggering rather than a general-purpose conditional rules engine (e.g., no evidence of arbitrary if/then logic across multiple event types or complex conditions). missing for 10: evidence of a general conditional rules/policy engine beyond cron and webhook triggers, and independent/hands-on confirmation of trigger reliability.
- [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
- [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
- [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
- [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to MaritimeCloudflare 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…”
Maritime explicitly supports cron triggers with standard five-field expressions that wake agents and deliver prompts on schedule, plus a natural-language flow where an agent sets its own recurring schedule ('send me a digest every weekday at 9') that syncs into real wake triggers. This directly covers recurring job/workflow scheduling for AI-native users. Missing for 10: independent/hands-on verification beyond vendor docs, and no detail on managing/editing/cancelling existing scheduled triggers via CLI/API.
- [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
- [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
- [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
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 MaritimeCloudflare 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.”
Maritime documents dedicated template recipes for running Claude Code and Codex inside its sandboxed micro-VMs (persistent storage, sleep/wake, metered LLM access by default, chat channels), directly matching the vendor's own recipe framing for these named coding agents. missing for 10: independent/hands-on verification beyond vendor docs, and no direct evidence of a step-by-step 'follow this exact recipe' walkthrough output for a live run.
- [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”
- [claimed-docs] “No key is required: the agent uses Maritime's metered LLM access by default.”
- [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”
- [claimed-docs] “point Claude Code or your Maritime agent at a provider's runbook page and it can inventory the old provider with read-only credentials, recr…”
- [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
Workloads
developerRun a headless browser or full desktop environment inside the sandbox
weight 2 · round to MaritimeCloudflare 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.
Maritime docs explicitly describe 'Computers': a persistent Linux desktop (XFCE, Chromium, LibreOffice) per user driven by a model, and the changelog confirms agents get a real Linux desktop with screenshot/mouse/keyboard control and live takeover — this covers full desktop environments including a browser (Chromium) inside the sandbox. missing for 10: no independent/hands-on corroboration of performance or headless-only browser mode, and no detail on resource limits or concurrency.
- [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
- [claimed-docs] “Agents are getting a real Linux desktop they can drive: screenshot, mouse, keyboard, and a live view you can take over.”
- [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”
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.
Maritimenone0/10No evidence anywhere in the pack mentions GPUs, GPU-accelerated instances, or hardware acceleration for sandboxed agent workloads; all compute descriptions reference micro-VMs, sleep/wake, and CPU-based containers only. Missing for 10: any mention of GPU attachment, GPU instance types, or hardware accelerator support.
- [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”
- [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”
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 });”
Maritimenone0/10No evidence pack item mentions SDK-based file read/write/upload/download operations against a sandbox filesystem; the docs cover agent provisioning, webhooks, auth scoping, triggers, computers (desktop), CLI, and migration but nothing about filesystem file I/O via SDK. Missing for full: no filesystem API/SDK method docs, no upload/download endpoint references, no code samples showing file operations.
Runtimes
developerDefine custom sandbox templates or bring my own container image
weight 2 · round to MaritimeCloudflare 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 confirm bring-your-own-image support via a documented three-endpoint contract that works with any Docker image (CrewAI, LangGraph, AutoGen, custom scripts), plus a build log and template system for packaging custom agents. However, there's no detailed spec of the contract itself, no example custom Dockerfile, and no independent/hands-on confirmation of successfully running a fully custom image end-to-end. missing for 10: full technical spec of the three-endpoint contract, a worked example of a custom image deployment, independent verification of custom image support beyond docs claims.
- [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”
- [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
- [claimed-docs] “The agent page streams the build log live under **Overview → Builds**.”
- [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”
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.”
Maritimenone0/10Maritime's evidence describes deploying persistent Docker-based agents (any Docker image with sleep/wake/channels/triggers), a Files API, and a Linux desktop 'Computers' feature, but nothing describes a code-execution/sandbox API that runs snippets in multiple language runtimes (Python, JS, etc.) and returns structured/rich results (e.g., stdout, images, dataframes) the way a code-interpreter tool would.
- [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”
- [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
- [claimed-docs] “The Maritime Files API: eight endpoints and both SDKs to browse, upload, download, and edit an agent's disk over HTTP, even while the agent …”
- [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”
Untrusted code
developerExecute untrusted, AI-generated code without risking my own infrastructure
weight 3 · round to Cloudflare SandboxesCloudflare'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…”
Maritime hosts agents as Docker images on 'serverless infrastructure' (maritime-docs-1, maritime-probe-1) and provides persistent isolated Linux desktops per end user (maritime-docs-5), which implies agent code runs off the developer's own machines/infra. However, there is no explicit documentation of sandboxing guarantees, resource/network isolation, or security boundaries specifically for running untrusted or AI-generated code safely. Missing for 10: explicit sandbox/isolation security model, resource-limit guarantees, and any independent verification that untrusted code cannot escape or affect other tenants/infra.
- [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”
- [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
- [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
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…”
Maritimenone0/10Maritime's docs describe deploying agents via Docker images, templates, and a custom framework contract, but there is no evidence of an interactive shell/terminal access or arbitrary package installation inside a running sandbox for a developer to use directly. The 'Computers' feature offers a persistent desktop for end-users, not a shell for arbitrary command execution by the developer.
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 Cloudflare SandboxesDocs 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…”
Maritime's CLI and SDK let an agent provision (idempotent) itself, run in a sandboxed micro-VM/container, and be managed via authenticated API/CLI calls with JSON output designed for machine consumption, and agents can be torn down/put to sleep automatically when idle. However, the evidence is docs-only with no hands-on trace of an agent actually reading back code-execution results or explicit 'delete/destroy' teardown call, and no independent verification of the full autonomous loop. missing for 10: concrete evidence of an agent reading execution output programmatically, an explicit teardown/delete API example, and independent/hands-on confirmation of the full provision→execute→read→teardown loop.
- [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
- [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
- [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
- [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
- [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”
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…”
Maritimenone0/10No evidence pack item documents a specific isolation mechanism (microVM, gVisor, container hardening, VM boundary) between sandboxes and host systems; docs mention Docker images, serverless infra, and scoped API keys but not the underlying execution isolation boundary. Missing for 10: any explicit statement of sandbox isolation technology, security model documentation, or third-party audit/confirmation of hard isolation.
ai-native userGive an agent a sandbox where host secrets and credentials are unreachable by the code it runs
weight 2 · round drawnCloudflare 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…”
Maritime's docs describe per-agent micro-VM isolation with secrets 'injected only into that agent's VM' and encrypted at rest, plus scoped API keys so a leaked key 'can only do what its scope allows,' which together imply host-level credentials aren't reachable by agent code. However, there's no explicit documentation of sandbox mechanics like blocking cloud metadata endpoints, filesystem isolation from the host, or independent security testing confirming secrets are truly unreachable. missing for 10: explicit host-credential isolation guarantees (e.g., no metadata service access, filesystem boundary details), independent/hands-on security verification.
- [claimed-docs] “Variables are **secret by default**: stored encrypted at rest, injected only into that agent's VM, and always masked in the UI.”
- [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
- [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”
- [claimed-docs] “a key whose only scope is `computers` is refused on every other Maritime endpoint”
- [claimed-docs] “Every key carries scopes. Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”
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 to Cloudflare SandboxesCloudflare 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.”
Docs show a broad API/SDK/CLI surface (provisioning, keys, webhooks, triggers, computers, templates, builds) and CLI --json mode implying the CLI itself is just an API wrapper, suggesting an API-first architecture. However there's no explicit statement of full UI/API parity and no discoverable OpenAPI spec (probes return 404s for all schema locations), so completeness of API coverage relative to every UI feature can't be confirmed. missing for 10: explicit parity statement, published OpenAPI/API reference, independent confirmation that every UI action has an API equivalent.
- [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
- [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
- [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
- [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
- [claimed-docs] “The agent page streams the build log live under **Overview → Builds**.”
- [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
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.”
Maritimenone0/10Evidence shows import/migration INTO Maritime (from AWS/Heroku/VPS, .env bulk import) and a CLI with --json output, but nothing documents exporting agent configs, data, secrets, or state OUT in open formats to leave the platform. missing for 10: an export command or documented data-portability feature, open-format export of agent state/configs, any migration-out guide.
- [claimed-docs] “Bulk import from a .env file (or stdin), then hot-reload”
- [claimed-docs] “Migrate from AWS, Heroku, or a VPS”
- [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
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.
Maritimenone0/10Maritime is a closed commercial SaaS platform; there is no evidence of an open-source license or public source repository anywhere in the docs or probes. missing for 10: an open-source license, a public source code repository, any mention of licensing terms for the platform's own code.
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 …”
Maritimenone0/10Maritime is explicitly described as a cloud platform with agents running on serverless infrastructure, and no documentation offers a self-hosted deployment option for the core platform itself (Docker images are for agent frameworks running atop Maritime's cloud, not for self-hosting Maritime).
- [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
- [claimed-docs] “Migrate from AWS, Heroku, or a VPS”
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.”
Maritimenone0/10Maritime's docs describe sleep/wake behavior (e.g., 'Sleeping agents wake automatically', 'puts it to sleep when idle, and wakes it on the next visit') and an 'always-on' add-on for millisecond reaction, but no evidence anywhere documents actual cold-start latency numbers (sub-second to few-second) for waking a sandboxed agent from sleep.
- [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
- [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL. Maritime builds it, runs it serverlessly, puts it to sleep when id…”
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
Scale
platform-engineerRun large concurrent fleets of sandboxes with documented concurrency limits
weight 3 · round drawnCloudflare 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…”
developerKeep a sandbox session running for hours or days for long agent tasks
weight 2 · round to MaritimeCloudflare 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…”
Maritime advertises serverless infra by default with an 'always-on' add-on for agents that must run continuously, and a persistent Linux desktop model for end users, suggesting long-lived sessions are possible but only via a paid add-on rather than a default guarantee for hours/days-long sandbox sessions. missing for 10: explicit documentation of session/session-timeout limits, confirmation that a sandbox session can run unattended for hours or days without the always-on add-on, and independent verification of long-running task stability.
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
- [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
- [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
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 to MaritimeCloudflare 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 …”
Docs explicitly state the free plan includes 3 agents with no card required, and quickstart/CLI docs show a self-serve path (npm install, deploy in under 5 minutes) with no sales contact implied anywhere. missing for 10: independent/third-party confirmation of the free tier's real-world limits and no hands-on verification of the signup flow.
- [claimed-docs] “the free plan includes 3 agents, no card required”
- [claimed-docs] “Deploy your first agent and talk to it, in under 5 minutes.”
- [claimed-docs] “npm install -g maritime-cli”
- [claimed-docs] “One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bil…”
platform-engineerPay per second only for the compute a sandbox actually uses
weight 3 · round drawnCloudflare 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…”
Maritimenone0/10Maritime's own billing docs explicitly state the opposite of per-second usage billing: 'One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bill' and 'Always-on is a flat add-on.' There is no evidence of any per-second or usage-metered compute pricing for sandboxes.
- [claimed-docs] “One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bil…”
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
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 drawnCloudflare 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.
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.”
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 Cloudflare SandboxesCloudflare 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…”
Maritimenone0/10The docs describe Maritime as serverless agent hosting and mention an 'always-on' paid add-on (implying default agents are not always running), but no evidence describes a developer-configurable idle timeout or automatic shutdown-to-stop-billing mechanism. Missing for 10: any documented timeout setting, idle-detection policy, or billing-pause behavior tied to inactivity.
- [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
developerSpin up an isolated sandbox with one API/SDK call and get a live environment in seconds
weight 3 · round to Cloudflare SandboxesDocs 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.”
Maritime's SDK exposes an idempotent `provision` call that creates/returns a live agent environment, and docs claim full agent deployment (image pull → live, chat-ready) in under 5 minutes, with CLI/API equivalents (`maritime keys create`, RESTful API). This matches the 'one call, live environment fast' story well, though the fastest documented time is minutes not literal seconds and there's no independent/hands-on latency benchmark or public OpenAPI spec confirming the exact call shape. Missing for 10: independent timing/benchmark evidence corroborating 'seconds', and a verifiable OpenAPI/API schema (probe shows openapi.json 404).
- [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
- [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
- [claimed-docs] “Deploy your first agent and talk to it, in under 5 minutes.”
- [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”
- [claimed-docs] “RESTful API for managing agents programmatically.”
- [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
- [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
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.”
Maritime's docs describe deploying any Dockerfile-based repo to a public, no-login HTTPS URL that reaches the running container's service, matching the core story of exposing an internal service via a public preview URL (maritime-docs-29, maritime-docs-47). However, the docs never explicitly describe port-selection mechanics (e.g., multiple ports, custom port binding) and all evidence is first-party with no independent/hands-on corroboration. missing for 10: explicit port-selection/multi-port docs, independent verification that the public URL reaches an arbitrary internal port.
- [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL. Maritime builds it, runs it serverlessly, puts it to sleep when id…”
- [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL.”
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 Cloudflare SandboxesDocs 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 …”
developerSnapshot a sandbox and later restore or fork new sandboxes from that snapshot
weight 3 · round to Cloudflare SandboxesDocs 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 …”
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.”
Maritimenone0/10Maritime's evidence describes agent deployment, hosting, webhooks, CLI/SDK tooling, and templates, but nothing shows the platform itself surfacing AI-generated insights or suggestions from a user's own data within the product UI — the docs describe running agents, not an analytics/insights layer on user data.
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.”
Maritimenone0/10Maritime is presented as infrastructure for hosting/deploying user-built AI agents, not as a product with its own built-in assistant for task delegation. Evidence shows external assistants (Claude, Cursor) can drive the Maritime CLI on the user's behalf, but nothing indicates Maritime itself ships an embedded assistant the user delegates tasks to inside the product.
- [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
- [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
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.