Vercel Sandbox vs CodeSandbox

AI agents read filesystems, run shell commands, and generate code. They are also fundamentally subject to prompt injection, which means an attacker can influence what code the agent writes. When prompt injection meets code execution, that influence becomes arbitrary action on your infrastructure: exfiltrating credentials, reaching internal services, or modifying files the agent was never intended to touch. Isolated sandbox environments solve this by giving generated code its own security boundary, separate from the agent and its secrets.

Both Vercel Sandbox and CodeSandbox provide this kind of isolation, but they start from different assumptions about what happens after the code runs.

Vercel Sandbox treats every execution as disposable. Create a sandbox, run code, get results, tear it down. CodeSandbox treats every execution as the start of a longer session. The sandbox persists, the filesystem survives, and running processes can be resumed later. That difference in lifecycle model shapes everything from billing to security to what you can run inside each sandbox.

This guide breaks down where each product fits so you can decide which one matches what you're building.

• How Vercel Sandbox and CodeSandbox compare
• Where Vercel Sandbox goes deeper
• Where CodeSandbox goes deeper
• What they cost
• When to choose Vercel Sandbox or CodeSandbox
• Get started with Vercel Sandbox

The ephemeral vs persistent design choice described above affects compute limits, security controls, pricing, and what you can run inside each sandbox.

Both products use Firecracker microVMs, giving each sandbox its own Linux kernel to prevent the cross-sandbox escapes that container-based isolation leaves open. The differences are in what each product optimizes for: running many short-lived executions concurrently, or running fewer long-lived environments with more resources per sandbox.

CodeSandbox offers higher per-sandbox resource ceilings because the product evolved from a cloud development environment where teams run databases, build tools, and multi-service stacks inside a single VM. Vercel Sandbox caps per-sandbox resources lower because the product optimizes for throughput: at Pro, a team can run 2,000 isolated sandboxes concurrently at a base cost of $20/month. Reaching 250 concurrent sandboxes on CodeSandbox requires the Scale tier at $170/month.

On the Vercel Sandbox side, snapshots save filesystem and installed packages when you need reproducibility across runs. On the CodeSandbox side, the git-backed workspace at /project/workspace automatically commits on hibernate or shutdown, and memory snapshots can resume running processes in 0.5 to 2 seconds (average 400ms in published benchmarks).

Vercel Sandbox is currently available in one region (iad1, US East). CodeSandbox operates across multiple clusters. For latency-sensitive workloads outside North America, this is worth factoring in.

Both products provide VM-level isolation and SOC 2 Type II certification. The key difference is what controls exist at the network boundary.

Vercel Sandbox adds application-layer controls on top of VM isolation: credential brokering keeps secrets outside the sandbox entirely, and a runtime network firewall controls what outbound connections the sandbox can make. CodeSandbox relies on VM-level isolation as its primary boundary, with AES-encrypted environment variables for secret storage. See the credential brokering and network firewall deep dives below.

The comparison tables above show where the two products overlap. The sections below go deeper into the capabilities that are specific to Vercel Sandbox.

AI-generated code that needs to call authenticated APIs creates a specific security problem. If you pass API keys into the sandbox as environment variables, the generated code can read them and send them anywhere. Credential brokering solves this by keeping secrets outside the sandbox entirely.

A proxy sits outside the sandbox security boundary and intercepts outbound requests. When the sandbox code calls an API endpoint without authentication headers, the proxy injects credentials into the HTTP headers in transit. If the sandbox code tries to set the same headers (to redirect authenticated requests to an attacker-controlled endpoint), the proxy overwrites them. When no transformation rules are configured, TLS passes through end-to-end without interception. Credential brokering transformation rules require Pro or Enterprise plans.

The sandbox network firewall controls what external services a sandbox can reach. Three modes are available: allow-all (the default), deny-all (blocks everything including DNS resolution), and user-defined rules combining domain and IP range matching.

Domain matching works through SNI (the TLS handshake field that identifies the target hostname), and CIDR rules handle IP-range and non-TLS traffic. Denied ranges always take precedence over allowed ranges and domain-based rules. Policies update at runtime through updateNetworkPolicy() without restarting running processes, so you can start with deny-all and selectively open access to specific APIs as an agent's execution progresses.

Active CPU pricing charges only for time the CPU is executing code. Time spent waiting on AI model inference, database queries, API responses, or any other I/O does not count. For AI agent workloads where sandboxes spend most of their time waiting on model responses, this means paying for minutes of compute instead of the full wall-clock duration.

On Pro, Active CPU costs $0.128 per vCPU-hour with millisecond billing granularity. A 10-minute sandbox that actively uses the CPU for 2 minutes is billed for 2 minutes of CPU. CodeSandbox charges a combined hourly rate per VM tier ($0.1486/hr for a Nano VM with 2 cores and 4 GB) for the full provisioned duration, including idle time.

Both products bill memory on wall-clock time. Vercel's memory rate ($0.0212/GB-hr) is higher than CodeSandbox's ($0.0149/GB-hr), but the Active CPU savings on the CPU component more than offset that difference for workloads where the CPU is not running continuously.

Snapshots save the complete filesystem and installed packages of a running sandbox. Restoring from a snapshot skips dependency installation and setup, which matters for workloads that use the same base environment repeatedly. Snapshots default to 30-day expiration, configurable up to never-expires. Creating a snapshot automatically stops the sandbox.

Sandboxes can also initialize from a Git repository, a tarball URL, or an empty workspace, giving teams multiple paths to a consistent starting point.

CodeSandbox offers capabilities that fall outside Vercel Sandbox's focus areas. If your project relies on any of these, CodeSandbox may be worth evaluating alongside Vercel Sandbox.

CodeSandbox supports Dockerfile and Docker Compose definitions, so a single sandbox can run a Node.js application alongside PostgreSQL, Redis, and any other containerized service. The Dev Container specification (devcontainer.json) provides standardized environment configuration. Vercel Sandbox uses dnf package installation and snapshots instead of container images. This keeps the sandbox footprint minimal for single-process execution, optimized for the create-run-destroy pattern rather than multi-service orchestration.

Persistence is built into the workspace model. Files at /project/workspace are git-backed and survive reboots and hibernation. Memory snapshots preserve running process state, so dev servers resume without a cold start. The persistence tiers range from 0.5 to 2 seconds resume (memory snapshot) to 5-20 seconds (disk-only) to 20-60 seconds (archived after 7 days without access).

Both products let you duplicate an environment, but the mechanism and tradeoffs differ.

CodeSandbox clones a VM in under 2 seconds (average 921ms in published benchmarks) using copy-on-write memory sharing. The clone preserves full process state, so running dev servers and databases continue in the forked sandbox without restart. This supports workflows like giving every PR its own database copy.

Vercel Sandbox uses snapshots. A snapshot saves the complete filesystem and installed packages, and new sandboxes can restore from it to skip setup. Snapshots do not preserve running process memory, so processes start fresh in the restored environment. This fits the ephemeral model where each sandbox starts clean and deterministic.

CodeSandbox SDK includes built-in JavaScript and Python interpreters, persistent terminals with xTerm.js integration, filesystem change watching, a browser preview API with code injection, and multi-user sessions. These are designed for building interactive coding environments and collaborative tools. Vercel Sandbox SDK provides a programmatic command execution model rather than interactive development primitives.

The table below compares the paid tiers where each product first supports production-level SDK concurrency (more than 10 concurrent sandboxes).

Vercel's free hours are Active CPU time. A sandbox with 10% CPU utilization gets roughly 50 hours of wall-clock time from 5 Active CPU hours. CodeSandbox's 40 hours are wall-clock time regardless of CPU activity.

The examples below compare equivalent sandbox configurations on each product. Vercel Sandbox bills CPU at $0.128/vCPU-hr only during execution, and memory at $0.0212/GB-hr for the full wall-clock duration. CodeSandbox bills a combined rate for the full duration ($0.1486/hr at Nano, $0.2972/hr at Micro).

2 vCPU, 4 GB RAM (Vercel default / CodeSandbox Nano)

4 vCPU, 8 GB RAM (Vercel 4-vCPU / CodeSandbox Micro)

At scale (2 vCPU, 4 GB, 1,000 sandboxes/day for 30 days)

The monthly total includes both usage charges and the base plan cost. CodeSandbox's minute-level rounding and higher base plan compound at volume. Vercel's millisecond granularity means short-lived sandboxes are billed for exactly what they use.

The right product depends on what you're building and what happens to the sandbox after the code runs.

The choice comes down to the lifecycle pattern. Ephemeral workloads that create, execute, and destroy sandboxes in minutes benefit from Vercel Sandbox's billing model and security controls. Persistent workloads that maintain state across sessions, run multiple services, or present interactive UIs to developers benefit from CodeSandbox's broader tooling surface.

If your workload needs isolated code execution with Active CPU billing, credential brokering, and runtime network controls, try it now with npx sandbox create --connect or sign up for a free account.