Berry Wiki

Vercel Sandbox

Properties2
tagsai, hosted
aliasesVercel Sandbox

10 min read

Vercel Sandbox

Summary

Vercel Sandbox is a hosted service for running untrusted or agent-generated code inside isolated Linux virtual machines. Applications can create and control sandboxes through JavaScript, TypeScript, Python, a command-line tool, or Vercel’s REST API.

  • Provider: Vercel
  • Repository: vercel/sandbox
  • License: Apache-2.0 for the open-source SDK and command-line tool
  • Service status: Generally available
  • Status checked: 2026-07-14

Problem

AI agents, code playgrounds, and user uploads may need to install software, execute commands, edit files, or start servers. Running that code beside production data can expose secrets, databases, and cloud accounts.

Vercel Sandbox moves the workload into a remote, short-lived machine. It is like giving a contractor a separate rented workshop instead of keys to the main building.

How It Works

  • Isolation unit: Each sandbox runs in a Firecracker microVM, a small virtual machine with its own kernel, filesystem, and network.
  • Base system: Amazon Linux 2023.
  • Control: The SDK or command-line tool creates sandboxes, runs commands, streams output, reads and writes files, manages ports, and stops or deletes instances.
  • Root capability: Workloads run as vercel-sandbox but can use sudo, including for system packages, Docker, VPN clients, and FUSE filesystem drivers.
  • Live previews: Up to 15 ports can be exposed through generated sandbox domains.
  • Persistence: Filesystem persistence is on by default. Stopping saves a snapshot; a later operation automatically starts a new session from that state. Ephemeral mode can discard state.
  • Reuse: Named sandboxes can be retrieved, resumed, forked, tagged, or deleted. Persistent drives and custom container images were beta features at check time.

Security Boundary

  • Separate kernel: Firecracker provides a stronger boundary than a normal container or process sandbox because guest code does not share the host kernel.
  • Remote boundary: The sandbox is separated from the developer’s laptop and the application’s production runtime.
  • No automatic production secrets: Vercel says production environment variables, database connections, and cloud resources are not exposed to sandboxed code unless the application deliberately provides access.
  • Network control: A firewall can allow all traffic, deny all traffic including DNS, or allow selected domains and address ranges.
  • Important default: New sandboxes use allow-all unless a stricter network policy is supplied. Isolation therefore does not automatically prevent data from leaving through the internet.
  • Writable guest: Root access lets code fully control its VM. This is intentional; the VM boundary, network policy, and supplied data must contain the risk.
  • Persistence risk: Persistent files can carry malicious changes into later sessions. Delete or use non-persistent sandboxes when state should not survive.
  • Provider trust: Source code and supplied data run on Vercel infrastructure. Users must trust Vercel’s service controls and Firecracker boundary.

Platforms And Agents

  • Host platforms: The service is remote. Any platform able to use the SDK, REST API, or command-line tool can control it.
  • SDKs: JavaScript/TypeScript through @vercel/sandbox; Python through vercel.sandbox in Vercel’s Python package.
  • Guest runtimes: Node.js 22, 24, and 26 plus Python 3.13. Other tools can be installed with root access or supplied through a custom image.
  • Agent fit: Agent-neutral. Vercel documents AI SDK, OpenAI Agents SDK, code-review bots, durable agents, and general agent workflows rather than requiring one coding agent.
  • Coding assistant support: The repository ships a Sandbox skill for Cursor, Codex, and other compatible assistants.

Setup

The normal JavaScript path is:

  1. Create or link a Vercel project.
  2. Authenticate with a Vercel OIDC token, which is a short-lived identity token tied to the project, or use a scoped access token outside Vercel.
  3. Install @vercel/sandbox.
  4. Create a sandbox with the desired source, runtime, resources, timeout, ports, persistence, and network policy.
  5. Run commands and exchange files through the SDK.
  6. Stop the session to save persistent state, or delete the sandbox to remove it.

The command-line tool supports creating a sandbox, opening an interactive shell, running commands, changing settings, and connecting through SSH.

Workflow

  • Seed: Start empty, upload files, use a Git source, restore a snapshot, or use a custom image.
  • Prepare: Install dependencies and system packages while streaming output.
  • Restrict: Change the firewall without restarting. A useful pattern is to download dependencies first, then switch to deny-all before running untrusted code.
  • Execute: Run attached or detached commands and start development servers.
  • Inspect: Read logs, retrieve generated files, connect interactively, or expose selected ports.
  • Continue: Stop and later resume a named persistent sandbox, or fork it for parallel work.
  • Clean up: Disable persistence for disposable jobs or explicitly delete retained state.

Network And Credentials

  • Firewall modes: allow-all, deny-all, or a deny-by-default custom allow-list.
  • Filtering: Domain rules support HTTPS by TLS hostname and TLS-required Postgres. Address ranges handle other traffic, including plain HTTP.
  • Live tightening: Policies can change during a run, so setup and untrusted execution can use different access.
  • Credential brokering: Pro and Enterprise plans can add credentials to matching outbound HTTPS requests without putting the secret inside the VM. Rules can match path, method, query values, and headers.
  • Proxying: Pro and Enterprise plans can forward selected requests to a user-controlled proxy for checks, logging, or changes.
  • TLS inspection: Vercel terminates TLS only for requests using transformation or forwarding rules and installs a unique certificate authority inside that sandbox.
  • Authentication: OIDC is recommended. Local development tokens expire after 12 hours; Vercel refreshes them automatically in production. Scoped access tokens are the fallback outside Vercel.
  • Caution: Any secret explicitly written to a file, environment variable, or command becomes readable to guest code. Brokering avoids that exposure only for supported outbound HTTPS requests.

Pricing

Official rates checked 2026-07-14:

  • Hobby included use: 5 active CPU hours per month, 420 GB-hours of provisioned memory, 5,000 creations, 20 GB transfer, and 15 GB lifetime snapshot storage. Creation pauses after a limit is reached; Hobby does not incur overage charges.
  • Pro and listed Enterprise rates: 0.0212 per provisioned GB-hour, 0.15 per GB transferred, and $0.08 per GB-month of snapshot storage.
  • Pro credit: Usage draws from the plan’s $20 monthly credit before added billing.
  • Enterprise: Vercel also states that Enterprise pricing and limits can be customized through sales.
  • Billing detail: Waiting for network, database, or model responses does not count as active CPU, but provisioned memory continues to be measured while the sandbox runs.

Limits at check time:

  • Maximum run: 45 minutes on Hobby; 24 hours on Pro and Enterprise.
  • Concurrent sandboxes: 10 on Hobby; 2,000 on Pro and Enterprise.
  • Resources: Hobby up to 4 vCPUs and 8 GB memory; Pro up to 8 vCPUs and 16 GB; Enterprise up to 32 vCPUs and 64 GB.
  • Disk: 32 GB temporary NVMe disk per sandbox.

Prices and limits can change; confirm the official pricing page before budgeting.

Strengths

  • Strong isolation: A separate Firecracker kernel contains root-level guest activity better than a normal container.
  • Managed scale: The service can support many concurrent, short-lived environments without developers operating VM hosts.
  • Fast interaction: Vercel states that sandboxes start in milliseconds.
  • Useful APIs: Commands, files, snapshots, persistence, ports, tags, images, and lifecycle controls are available programmatically.
  • Safer secret access: Credential brokering can authorize selected requests while keeping keys outside the guest.
  • Flexible networking: Policies can be defined at creation and tightened while a process is running.
  • Durable option: Default persistence supports agents that continue across sessions; disposable mode remains available.
  • Production signal: Vercel says v0, Blackbox AI, and RooCode use the service.

Limits

  • Cloud dependency: Work stops if Vercel or the network is unavailable.
  • Remote source handling: Code and selected data leave the local machine, which may conflict with company rules or client agreements.
  • Open network by default: Users must explicitly choose deny-all or an allow-list when preventing data loss matters.
  • Usage cost: CPU, reserved memory, transfer, and stored snapshots are separately metered on paid plans.
  • Finite sessions: It is not an unlimited general-purpose server; even paid sessions have a 24-hour maximum.
  • Vendor-specific control plane: Persistence, domains, identity, billing, and policy APIs tie the workflow to Vercel.
  • Limited guest choices: Official ready-made runtimes are Amazon Linux-based Node and Python images. Custom images improve flexibility but were beta.
  • Firewall edges: Plain HTTP cannot use domain filtering; Postgres needs TLS; credential transformation does not support Postgres.
  • Not a correctness check: Isolation limits damage but does not prove that agent output is secure or correct.

Activity And Maturity

Checked 2026-07-14:

  • Service: Generally available since 2026-01-30.
  • Persistence: Generally available since 2026-05-26 and enabled by default.
  • Repository: Created 2026-01-23; updated and pushed on 2026-07-14.
  • Latest SDK release: @vercel/sandbox@2.6.0, published 2026-07-13.
  • Repository interest: 163 stars and 33 forks.
  • Recent release work: Version 2.6.0 added multi-user and group management.
  • Assessment: A young public SDK backed by an established hosted platform. Its service maturity is stronger than most personal sandbox projects, while several advanced features remain beta.

Best Fit

Vercel Sandbox best fits teams that:

  • build a hosted product that executes user or agent code;
  • need remote Firecracker isolation without operating their own VM fleet;
  • want programmatic creation, previews, persistence, and high concurrency;
  • can send source code to Vercel;
  • will configure strict firewall rules and credential brokering for sensitive work;
  • accept usage-based cloud billing.

It is a weaker fit for offline work, organizations that forbid third-party code hosting, developers seeking a free local shell around an existing repository, or workloads needing uninterrupted runs beyond 24 hours.

Comparison With Clawk And Other Sandboxes

  • Versus Clawk: Both use separate-kernel virtual machines and destination-aware network controls. Clawk is a local, coding-agent-focused tool that mounts the developer’s worktree and keeps source on the laptop. Vercel Sandbox is remote, agent-neutral infrastructure with managed scale, APIs, persistence, and billing.
  • Security default: Clawk blocks unlisted destinations by default. Vercel Sandbox allows all public internet traffic by default, although its firewall can enforce deny-all or explicit allow-lists.
  • Credentials: Clawk proxies the host SSH agent and passes selected secrets into the guest. Vercel’s paid brokering can inject headers after traffic leaves the VM, keeping supported HTTPS credentials outside it.
  • Host protection: Clawk protects most laptop files but exposes mounted worktrees and selected host capabilities. Vercel keeps the execution off the laptop entirely, but requires trust in a cloud provider and remote source handling.
  • Versus local process sandboxes: Bubblewrap, Landlock, and similar tools are lighter and usually cheaper. They share the host kernel, while Vercel uses a separate Firecracker guest kernel.
  • Versus local VM managers: Local Firecracker, Apple Virtualization, Incus, or Lima tools keep data under the user’s control. Vercel removes host setup and fleet operations, adds managed persistence and public preview domains, and charges for use.
  • Versus other hosted sandboxes: Vercel competes on tight integration with its deployment, identity, AI, and workflow products. Buyers should compare isolation, regions, startup time, network controls, persistence, runtime limits, pricing, and data terms against E2B, CodeSandbox, Modal, and similar services.

Direct Sources

Unknowns

  • Independent testing: The reviewed public pages do not identify a Sandbox-specific third-party security audit or publish VM-escape testing results.
  • Data location: The reviewed pages do not clearly state which execution regions are available or how a user selects one.
  • Network internals: The documentation explains policy behavior but not every lower-level control or failure mode behind the managed firewall.
  • Performance variance: “Starts in milliseconds” is a provider claim; no independent benchmark was checked.
  • Advanced feature stability: Custom images and persistent drives were beta and may change.
  • Full service source: The SDK and command-line tool are open source; the hosted control plane and execution infrastructure are not presented as fully open source.

Sources

    • imported AI research note for Vercel Sandbox.

Graph View