Daytona vs Vercel Sandbox (2026)

An agent in a Daytona sandbox reaches outside systems through what runs inside it. Git operations clone and push repositories, secrets hold credentials and external storage can be mounted. Firewall allow lists decide which hosts the agent may reach. Daytona has no catalog of connectors, OAuth actions or tool gateway of its own. The tools are the customer's code.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Credentials reach outside services without entering the sandbox. The firewall's credentials brokering adds an authorization header to outbound requests for named domains, with matchers on path, method, query and headers, request proxying sends chosen traffic through a proxy the customer runs, and Box Mount presents Box content to the agent as local files. The tools an agent calls with those credentials are the customer's own code, and the product carries no integration catalog or tool framework.

Sourcevercel.com/docs/sandbox/concepts/firewallread 2026-11-05

The platform manages sandboxes. It creates and resizes them, applies lifecycle rules and runs warm pools and fleet scaling. It does not sequence, branch, retry or route an agent's steps. In Daytona's guides, agents built in LangGraph, the OpenAI Agents SDK and other frameworks do that, and Daytona has no workflow logic that mixes fixed steps with agent steps.

Sourcedaytona.io/docs/en/sandboxesread 2026-09-22

There is no workflow logic in the product. Commands run blocking or detached from the customer's code, and lifecycle hooks run setup when a sandbox is created or resumed. Multi agent sandboxes give each agent its own Linux user and private home directory and share files through groups, which separates agents inside one machine without sequencing, routing or retrying their work.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

Events go outward. Webhooks notify the customer's endpoint when sandboxes are created or change state and when snapshots and volumes change. Automated lifecycle rules stop, pause, archive or delete idle sandboxes. An agent's work starts only when the customer's code starts it. There is no schedule, and a stopped sandbox does not wake on an inbound request.

Sourcedaytona.io/docs/en/webhooksread 2026-09-22

Work reaches a sandbox only when the customer's code or the CLI calls it. A stopped persistent sandbox resumes on the next SDK call that needs a running machine, and exposed ports serve traffic at a public URL while a session runs, but no schedule, webhook or inbound event starts or wakes a sandbox on its own.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

The agent's code runs on Daytona, but there is no retrieval structure over the customer's content. Volumes and mounted external storage hold files the agent's code reads, and there is no index to query. The language server in a sandbox serves code intelligence for the files there. Nothing in Daytona indexes, refreshes or sets permissions on the customer's sources.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

No retrieval index or knowledge base over the customer's content comes with Sandbox. Files on the sandbox disk, Vercel Drives and S3 buckets mounted through FUSE are storage the agent's code reads, and any search or embedding layer runs as the customer's own code inside the microVM.

Sourcevercel.com/docs/sandboxread 2026-11-05

Persistence is on by default at three layers. The filesystem survives stop, start and archive. On VM sandboxes, memory (running processes and loaded state) survives pause and resume and hot snapshots. Volumes and mounted external storage outlive any one sandbox. Sandboxes can also be forked, and the agent's code reads the restored state to carry on. Paused process state belongs to the machine, so the customer can resume or delete it but cannot review or edit it. There is no separate memory layer that sets what an agent keeps or for how long.

Sourcedaytona.io/docs/en/persistenceread 2026-09-22

Sandboxes are persistent by default. When a session stops, its filesystem is snapshotted automatically and the next SDK call resumes from it, snapshots can be kept for a set period or indefinitely, and Vercel Drives, in public beta, keep files across sandbox runs and can be shared between agents. The product does not remember anything for the agent. An agent keeps notes on a drive only when the application gives it file tools and instructions to do so, and running processes restart on resume.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

Work in a sandbox has no approval step, consent checkpoint or escalation to a person. VNC, a web terminal and SSH let a person watch a sandbox and step in by hand. A firewall on each sandbox (allow lists or block all, with organization tiers that sandbox settings cannot override) restricts what an agent's code can reach. Nothing holds an agent's action for a person to review.

Sourcedaytona.io/docs/en/network-limitsread 2026-09-22

Sandbox has no approval step, review queue or escalation to a person. The firewall can switch a running sandbox to deny all or narrow its allowed domains without a restart, which limits what an agent's code can reach but does not hold an action until someone reviews it.

Sourcevercel.com/docs/sandbox/concepts/firewallread 2026-11-05

Organizations sign in through OpenID Connect providers such as Google Workspace, Microsoft Entra ID and Okta, with provisioning and membership handled at sign in on the Enterprise plan. Collaborative organizations have owner and member roles plus granular assignments by resource, such as SSO Admin and access to the audit log.

API keys carry permissions and scopes, with managed child keys. An audit log covers user and system activity, and each sandbox has firewall allow lists or block all. Daytona says it meets HIPAA, SOC 2 and GDPR standards and has a Trust Center, but it names no report type or auditor.

Sourcedaytona.io/docs/en/ssoread 2026-09-22

Vercel's infrastructure holds SOC 2 Type II. Access to sandboxes follows Vercel's team roles (Owner, Member, Developer, Security, Billing, Viewer and Contributor) and, on Enterprise, project roles for administrators, developers and viewers, with permission groups for finer grants, and the SDK authenticates with project scoped OIDC tokens or access tokens. Each sandbox runs in its own Firecracker microVM with a dedicated kernel, and the firewall restricts egress by domain or address range and injects credentials so code inside never holds them.

Sourcevercel.com/docs/rbac/access-rolesread 2026-11-05

Each step an agent takes in the sandbox is recorded. SDK tracing instruments every Daytona API operation and SDK call from the customer's application, such as each command run, file written or process started. Sandbox telemetry collects traces, logs and metrics from inside the sandbox.

Both export over OpenTelemetry to the customer's own collector, and Daytona keeps sandbox telemetry for three days. A separate audit log records user and system activity with the user, action and time, and logs can be streamed. The model's reasoning runs outside Daytona. Audit export is not available yet, and Daytona says it is coming soon.

Sourcedaytona.io/docs/en/observability/otel-collectionread 2026-09-22

Each sandbox has a dashboard page with its configuration, an activity log of lifecycle events and its snapshots, the CLI lists every session a sandbox has run, and the Observability tab charts CPU and memory per sandbox, with alert monitors on Observability Plus. Command output streams through the SDK, and request proxying can route chosen traffic through a customer proxy for logging. What an agent decided between commands is not recorded, since the agent's loop runs in the customer's code.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

Sandboxes run in two shared regions, the United States and Europe, chosen per sandbox. Under Bring Your Own Compute, an organization instead creates custom regions and attaches its own runner nodes, with an optional proxy and snapshot manager for each region, for control over data locality and compliance.

Daytona's control plane manages them, and BYOC is sold on the Enterprise plan. The platform sold today cannot be self hosted from open source. Core development has moved to a private codebase, and the public github.com/daytonaio/daytona repository gets no further updates. Its last release, v0.190.0, stays public under AGPL 3.0.

Sourcedaytona.io/docs/en/bring-your-own-computeread 2026-09-22

Sandboxes run in 19 regions, chosen per sandbox or set as a project default, with iad1 as the default, and snapshots and drives stay in the region they were created in. Secure Compute sends a sandbox's internet traffic through static IPs and reaches the customer's own AWS VPC over VPC peering. Sandboxes run only on Vercel's infrastructure.

Sourcevercel.com/docs/sandbox/pricingread 2026-11-05

Ready made starting points for running agents include default sandbox snapshots in several sizes, a Declarative Builder for images and an agent skill for coding agents. More than forty guides run coding agents (Claude Code, Codex, Devin, Gemini CLI, OpenClaw, OpenCode), as well as framework agents and reinforcement learning setups, in sandboxes, and a reference implementation runs Cursor's Cloud Agents on self hosted Daytona sandboxes. Developers build from these environments and walkthroughs. There is no browsable catalog of agents a customer can adopt.

Sourcedaytona.io/docs/en/agent-skillsread 2026-10-23

The default universal image ships Node.js, Python and coding agents, rebuilt nightly from open source definitions, and one CLI command starts OpenCode, Pi, Claude Code or Codex inside a sandbox. Integrations cover Cursor Cloud Agents, Devin Outposts, Herdr, Hermes and Paseo, frameworks such as the AI SDK, LangChain, Mastra, Flue and TanStack AI, and the OpenAI Agents API. These are configured third party agents and building blocks, not prebuilt agents of Vercel's own.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

The customer chooses the model. Guides run agents on Claude, OpenAI Codex and the Agents SDK, Gemini, Kimi and AWS Kiro, and on open models through OpenCode and other frameworks. GPU sandboxes serve the customer's own LLMs with vLLM or SGLang. Daytona imposes no model, and customers bring their own providers and keys, with guides on setting them up.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

The customer chooses the agents and models that run in a sandbox. Any coding agent or framework can run inside it and model calls happen in the customer's code, and Vercel's examples route them through its optional AI Gateway with many providers or the customer's own keys. Sandbox itself imposes no model.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

Outside callers reach Daytona through SDKs in five languages (Python, TypeScript, Ruby, Go and Java), a REST API with published OpenAPI specifications, and a CLI. The specifications cover the Daytona API, the Toolbox API inside the sandbox and an Analytics API. An MCP server lets Claude, Cursor and Windsurf manage sandboxes, and an agent skill serves coding agents.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Outside code drives sandboxes through the open source @vercel/sandbox JavaScript and TypeScript SDK, the Python SDK in the vercel package and the sandbox CLI, covering creation from images or snapshots, commands, files, network policy updates, snapshots, drives, tags and listing. Authentication uses Vercel OIDC tokens or access tokens, so sandboxes can be driven from Vercel Functions, other clouds or CI systems.

Sourcevercel.com/docs/sandbox/sdk-referenceread 2026-11-05

Evaluations and reinforcement learning run on Daytona, but it does not score them. Its guides run training with HUD, TRL, veRL and OpenEnv in sandboxes, along with a benchmark agent across several languages. The datasets, reward functions and scoring belong to those frameworks. Daytona offers no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

There are no test cases, scoring or quality gates of the product's own. Harbor runs Terminal Bench and other benchmark trials in sandbox microVMs, and Scale AI's AgentEnv evaluates agents in separate environment and agent sandboxes, but those harnesses do the scoring, not Sandbox.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

The Computer Use API gives an agent programmatic control of a desktop in the sandbox, from mouse and keyboard to screenshots, screen recording and display operations, on Linux and Windows. VNC lets a person watch or take over. The desktop runs remotely on Daytona's infrastructure. macOS sandboxes run on Mac hardware reserved for the customer through use.computer, with their own API key, and the Daytona SDKs, CLI and API do not manage them.

Sourcedaytona.io/docs/en/computer-useread 2026-10-23

No browser or desktop for an agent to drive comes with the product. The managed images carry language runtimes, coding agents and utilities, and an agent that needs a browser has to install and run one itself inside the microVM.

Sourcevercel.com/docs/sandbox/concepts/imagesread 2026-11-05