--- title: Vercel Sandbox vs CodeSandbox description: "A detailed guide to Vercel Sandbox vs CodeSandbox: compute isolation, credential brokering, Active CPU billing, Docker support, persistent environments, and when to choose each product for your AI workloads." url: "https://vercel.com/kb/guide/vercel-sandbox-vs-codesandbox" published: 2026-03-20 last_updated: 2026-10-27 authors: Vercel install_vercel_plugin: npx plugins add vercel/vercel-plugin --- Vercel Sandbox and CodeSandbox provide isolated environments for running untrusted code, including code generated by AI agents. Both support saved environments that you can return to across runs. Vercel Sandbox is persistent by default. It automatically saves the filesystem when a session stops and restores it when you resume. A sandbox can continue across unlimited successive sessions, with a fresh timeout for each session. Snapshot retention determines how long its saved state stays available. This guide compares the lifecycle models, environment customization, security controls, and cost considerations that matter when choosing between them. ## How Vercel Sandbox and CodeSandbox compare | Capability | Vercel Sandbox | CodeSandbox SDK | | ------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Execution isolation | Firecracker microVM with a dedicated kernel | MicroVM infrastructure | | Saved environments | Persistent by default, with automatic filesystem snapshots on stop and restore on resume | VM checkpointing, hibernation, and resume | | Environment customization | Managed Linux images, custom OCI images from Vercel Container Registry, and Docker inside the sandbox | Templates and Dockerfiles | | Reusing setup | Resume a named sandbox or create sandboxes from a saved snapshot | Resume a sandbox or clone VMs and snapshots | | Agent workloads | Run commands and tools in an isolated workspace | Run commands and tools in an isolated workspace | The [Vercel Sandbox documentation](https://vercel.com/docs/sandbox) and [CodeSandbox SDK repository](https://github.com/codesandbox/codesandbox-sdk) describe the supported APIs and environment models. ## Persistence and session duration ### Vercel Sandbox persists across sessions by default Vercel separates the sandbox from its running sessions: - A sandbox is the long-lived workspace, identified by a name within your project. - A session is one running VM instance within that sandbox. - Stopping a persistent sandbox saves its filesystem automatically. - Resuming it starts a new session from the saved filesystem, with a fresh timeout. Installed dependencies, source files, and generated artifacts can carry forward across sessions without manually tracking snapshot IDs. This supports an agent returning to the same repository, a user reopening a coding workspace, or a job continuing from saved progress. The maximum session duration is 45 minutes on Hobby and 24 hours on Pro and Enterprise. These limits apply to each session, not to the lifetime of the sandbox. Unlimited successive sessions does not mean one uninterrupted VM runs forever, or that you can run unlimited sessions concurrently. Concurrency and usage remain subject to plan quotas and billing. By default, snapshots expire 30 days after their last use, and using a snapshot resets that timer. Set `snapshotExpiration: 0` to retain snapshots indefinitely. Snapshot storage is billed separately from compute. For disposable work, you can explicitly opt out of persistence with `persistent: false`. See [persistent sandboxes](https://vercel.com/docs/sandbox/concepts/persistent-sandboxes) for the lifecycle and retention settings, and [Sandbox pricing and limits](https://vercel.com/docs/sandbox/pricing) for session caps and quotas. ### CodeSandbox supports hibernation and VM checkpointing CodeSandbox SDK supports snapshotting and restoring VMs, cloning VMs and snapshots, and hibernating environments between uses. Its SDK also exposes an inactivity timeout that controls when automatic hibernation occurs. Its resume behavior depends on the saved state: the SDK distinguishes resuming a hibernated sandbox from a clean boot when its snapshot has expired. Evaluate the state your application needs to recover, alongside retention and restart behavior, rather than treating persistence alone as the deciding feature. ## Images, dependencies, and Docker Vercel Sandbox supports managed Linux images and custom OCI images stored in Vercel Container Registry. You can package system dependencies and tools into an image, then use that image as the starting environment for your sandboxes. Vercel Sandbox also supports running Docker inside its microVMs. Workloads that require system-level privileges run within the sandbox's dedicated kernel boundary. For custom images, Sandbox does not automatically execute Docker `ENTRYPOINT` or `CMD`; start the required processes explicitly after creation. CodeSandbox SDK supports Dockerfiles and templates for preparing environments. Both products therefore offer ways to define the tools and dependencies your code needs. Compare the image format, startup behavior, and services required by your workload rather than assuming Docker support is exclusive to CodeSandbox. See [Sandbox images](https://vercel.com/docs/sandbox/concepts/images) for managed and custom image behavior. ## Security beyond the VM boundary Vercel Sandbox provides a dedicated Firecracker microVM for each sandbox. For agent workloads, also consider which destinations generated code can reach and how it authenticates to external services. The Sandbox firewall supports outbound network policies that you can update while a session runs. You can block outbound access or allow specific destinations. Credential brokering can add authentication headers to matching outbound requests without placing the credentials inside the sandbox. Outbound internet access is allowed by default. Configure a restrictive policy for workloads that handle private data or should only call approved services. VM isolation and outbound access policy address different parts of the security boundary. See the [Sandbox firewall documentation](https://vercel.com/docs/sandbox/concepts/firewall) for policy behavior, credential brokering, and protocol limitations. ## What to include in a cost comparison Vercel Sandbox bills Active CPU separately from provisioned memory. CPU time spent waiting for model responses, network requests, or other I/O does not accrue Active CPU charges. Provisioned memory continues to accrue charges for the time the session runs, including idle time. For a persistent workspace used intermittently, stopping between tasks avoids keeping compute provisioned solely to preserve files. Saved snapshots still incur storage charges. Estimate costs using your actual CPU activity, allocated memory, running time, snapshot storage, and network traffic. When comparing CodeSandbox, use the current rate and billing rules for the VM configuration and plan you intend to use. Include any base subscription and check concurrency limits separately from usage charges. A concurrency quota is not an allowance for free compute. The [Sandbox pricing documentation](https://vercel.com/docs/sandbox/pricing) lists current rates, included usage, regional differences, and quotas. ## Which should you choose? Vercel Sandbox supports both persistent workspaces and disposable executions. Consider it for agents that return to saved files across sessions, code execution that needs controlled outbound access, or workloads where Active CPU billing fits periods of I/O wait. Use non-persistent mode when you want to discard the environment after a run. CodeSandbox SDK is worth evaluating when its VM checkpointing, cloning, and template-based development environments match your application. Test the specific recovery behavior and developer interactions you need. Choose based on the state you need to preserve, how work resumes, the controls required around untrusted code, and the cost of your workload. Persistence is available on both products; Vercel provides it by default. ## Get started with Vercel Sandbox Start with a persistent sandbox for a workspace you want to reuse. Choose a session timeout for each run and a snapshot retention policy for the saved environment. Opt out of persistence only when the workload calls for a disposable sandbox. To learn more, see the [Vercel Sandbox documentation](https://vercel.com/docs/sandbox). ## Related Documentation - [Vercel Sandbox](/docs/vercel-sandbox) ## More Vercel Sandbox guides - [Running Docker on Vercel](/kb/guide/docker): Run Docker on Vercel for HTTP apps and background workers, store images in Vercel Container Registry, and test containers with Vercel Sandbox. - [How to use Vercel Container Registry](/kb/guide/how-to-use-vercel-container-registry): Push, store, and pull OCI container images with Vercel Container Registry, then deploy them to Vercel Functions and Vercel Sandbox. - [Vercel Sandbox vs E2B](/kb/guide/vercel-sandbox-vs-e2b): A detailed guide to Vercel Sandbox vs E2B: compute lifecycle, security controls, code execution, pricing, and when to choose each sandbox for your AI agent workloads.