Vercel Sandbox

Vercel Sandbox provisions agent sessions as Firecracker microVMs in the iad1 (US East) region. It is the turnkey option for teams already using Vercel - authentication reuses your existing Vercel integration credential, and Node.js is available by default.

How Vercel Sandbox sessions work

The Vercel provider uses the vercel sandbox CLI (via the vercel-cli-bridge module) rather than a direct REST API. When the platform dispatches a session to a vercel pool, VercelSandboxProvider.provision():

Resolves the Vercel install token (from the org's vercel credential, VERCEL_AUTH_TOKEN, or the CLI's stored credentials at ~/.vercel/credentials).
Calls vercel sandbox create --runtime node24 --silent [options] and captures the sandbox ID from stdout.
Returns a SandboxHandle with the sandbox ID.

execCommand is not implemented for Vercel Sandbox. Vercel Sandbox is build-time/serverless in design and does not expose an exec surface via the CLI. Pools using the Vercel provider cannot host the in-box runner via execCommand. The runner must be launched by the sandbox's start command (baked into the image/template). See the runner-in-box note below.

Capability profile

Capability	Value
`transportModel`	`dial-in` (Vercel Sandbox exec endpoint)
`supportsFsSnapshot`	true (p75 restore under 1 second)
`supportsPauseResume`	false (FS snapshot only, not full memory+FS)
`supportsCapacityQuery`	false (FaaS-style)
`maxConcurrent`	null (tier-gated by Vercel)
`maxSessionDurationSeconds`	18 000 (5 hours; Hobby plan is 45 minutes)
`regions`	`['iad1']` (US East only)
`os`	linux
`arch`	x86_64
`idleCostModel`	metered (sandbox standby is billed)
`billingModel`	active-cpu
`supportsGpu`	false
`supportsCustomNetworkPolicy`	true (allow-all or deny-all)
`egressDefault`	allow-all

Session duration limits

Vercel plan	Max session duration
Hobby	45 minutes
Pro	5 hours (18 000 seconds)
Enterprise	Contact Vercel

Plan for the 5-hour ceiling when assigning long-running agent tasks to Vercel Sandbox pools.

Substrate defaults

Vercel Sandbox has Node.js baked into the base runtime (DEFAULT_RUNTIME='node24'), so toolchain:node is a class default. Go is not bakeable in Vercel Sandbox the same way, so Go repositories degrade to survival-plus-TS-only analysis on Vercel pools.

Runtime kinds: npm, http, mcp-server, a2a-protocol
Requirement kinds: network-egress, git, full-history-clone, toolchain:node

Setting up a Vercel Sandbox pool

Step 1: Connect Vercel integration

In Settings → Integrations, connect your Vercel account. This stores your Vercel install token as a vercel credential in the platform. The same credential is used by both the Vercel integration (deployment webhooks) and the Vercel Sandbox provider.

Step 2: Install the Vercel CLI on the platform host

The Vercel Sandbox provider shells out to vercel sandbox commands. The Vercel CLI must be installed on the host running the platform service:

npm install -g vercel@latest

Step 3: Create a Vercel Sandbox capacity pool

Navigate to Settings → Execution → Capacity → New pool → Vercel Sandbox and configure the pool.

Pool configuration

Config key	Type	Default	Description
`vercelScope`	string	`VERCEL_SCOPE` env	Vercel team slug. Required for multi-team accounts.
`runtime`	string	`node24`	Sandbox runtime (currently only `node24` is available)
`networkPolicy`	string	`allow-all`	Network policy: `allow-all` or `deny-all`
`snapshotId`	string	-	Start from a pre-built filesystem snapshot

Example pool config

{
  "vercelScope": "my-team-slug",
  "runtime": "node24",
  "networkPolicy": "allow-all"
}

Filesystem snapshots

Vercel Sandbox supports FS-only snapshots with p75 restore under 1 second. Take a snapshot of a sandbox that has the donmai runtime and your project dependencies pre-installed, then set config.snapshotId on the pool to warm-start future sessions:

// Take a snapshot (via VercelSandboxProvider.snapshot)
const snapshotId = await provider.snapshot(handle)
// snapshotId: "snp_xxxxxxxxxxxxxxxx"

Then update the pool config:

{
  "vercelScope": "my-team-slug",
  "snapshotId": "snp_xxxxxxxxxxxxxxxx"
}

New sessions provisioned from this pool start from the snapshot, skipping the runner launch and dependency install steps.

Runner-in-box constraint

Vercel Sandbox does not implement execCommand. The platform cannot launch the donmai runtime post-provision via an exec call. The runner must be part of the sandbox's start command or template.

Because Vercel Sandbox uses the Node.js runtime and the vercel sandbox create CLI, the recommended approach is to use filesystem snapshots pre-built with the donmai runtime already started. Contact Rensei support for guidance on building a Vercel Sandbox base snapshot for your team.

Log streaming

streamLogs is implemented but the Vercel CLI v52 does not expose a sandbox logs subcommand. Log streaming yields a placeholder message and degrades gracefully. Logs can be retrieved from the Vercel dashboard for the sandbox's project.

Credential reuse

The Vercel Sandbox provider and the Vercel integration share the same credential. If you have already connected Vercel in Settings → Integrations for deployment webhooks, no additional credential setup is needed for Vercel Sandbox pools.

Credential resolution order:

vercel credential stored in the platform credentials table
VERCEL_AUTH_TOKEN environment variable
Vercel CLI's stored credentials at ~/.vercel/credentials

Region constraint

Vercel Sandbox is currently available only in iad1 (US East). Sessions routed to a Vercel Sandbox pool will always execute in iad1, regardless of the session's origin region. If regional proximity is required for your workloads, use a different provider.

Capacity Pools - pool management and substrate resolution
Integrations: Vercel - Vercel deployment integration (shared credential)
E2B - alternative cloud sandbox with execCommand and true pause/resume
Add a Provider - SandboxProvider interface

On this page