When should code run in Vercel Sandbox instead of a Vercel Function?

Vercel Sandbox runs code in its own Firecracker microVM with a dedicated kernel, so it is the right home for code you did not write and for jobs that need a full toolchain, a real browser or ffmpeg. We use it in Monogram Tools, our multi-tenant workspace of internal tools, to build decks, export PDFs, encode screen recordings and host live meeting relays, and we boot most of those jobs from pre-built snapshots so they skip the install step.

What is Vercel Sandbox, and how is it isolated?

A sandbox is a Linux environment you create from code with the @vercel/sandbox SDK or the sandbox CLI. Each one is a Firecracker microVM with its own kernel, its own filesystem and its own network namespace, which is a stronger boundary than a container that shares the host kernel. It boots from a Vercel managed image, a custom image or a saved snapshot, gives you root, and stops itself after a timeout. Sandboxes are persistent by default: when one stops, the SDK snapshots its filesystem so the next session resumes from it.

Every sandbox in Monogram Tools is created with persistent: false, so its filesystem is discarded when it stops and each job starts clean.

Most of our sandbox jobs share one shape. A Vercel Function writes the project files into a fresh microVM, runs the toolchain there, reads the output back, uploads it to Vercel Blob and stops the VM. Screen Recorder's jobs run detached and Meeting's relays serve live traffic, so those two differ. The function orchestrates; the sandbox does the heavy or untrusted part.

Is Vercel Sandbox safe for untrusted or AI-generated code?

Vercel designs Sandbox for exactly that case, and the microVM is the security boundary rather than a process or a container. You can also restrict where a sandbox may connect with a network policy, which matters when the code inside might try to send data out.

Deck Studio is our clearest example. Deck markdown is written by users, and Slidev compiles any HTML and Vue in it into the published site. So slidev build runs inside a sandbox, never inside the function that handles the publish request. What the build produces is still untrusted, so we serve published decks with their own restrictions to limit what a deck's script can reach.

When does work belong in a sandbox rather than a function?

Move work into a sandbox when the code is not yours, when its toolchain would bloat the function bundle, or when it needs system binaries or a browser that a function does not carry. Vercel Functions have a 250 MB uncompressed bundle limit on the standard path, and a toolchain like Vite plus a headless browser eats into that quickly.

The Deck Studio build keeps the whole Slidev, Vite and Vue toolchain inside the microVM, so the publish function stays small and, by design, well clear of that limit. The Diagram Creator renders Mermaid to PNG in a sandbox because Mermaid lays diagrams out with d3 and foreignObject HTML, which only a real browser paints correctly. Screen Recorder sends its ffmpeg work to sandboxes started in detached mode, so the function that starts the job returns immediately.

How do you stop every sandbox paying for a cold install?

Use snapshots. A snapshot saves a sandbox's filesystem, including everything installed, and a new sandbox can boot from it instead of from a bare image. Snapshots expire 30 days after their last use by default, and you can change or remove that expiry.

Deck Studio's PDF export restores a pre-baked snapshot with its dependencies, Chromium and system libraries already in place. Restoring it skips about 80 seconds of npm install, system package installs and Chromium download, and the restore itself takes under a second. A weekly Cron Job re-bakes it every Monday at 06:00 UTC with 30 days of expiry, so one missed run never leaves exports without a snapshot, and the previous snapshot is deleted on a best-effort basis after each bake. If the snapshot is ever missing or expired, the export falls back to a cold build rather than failing.

Screen Recorder boots its jobs from an ffmpeg snapshot, and Meeting boots each room's relay from one too; a relay booted from the snapshot reaches its first accepted socket in about 1.5 seconds, against about 3 seconds from the plain image.

How long can a sandbox run, and how much CPU can it have?

According to Vercel's pricing and quotas page, a sandbox times out after 5 minutes by default, and you can extend it. A single session can run for 45 minutes on Hobby and 24 hours on Pro and Enterprise. You can allocate 1 vCPU or an even number up to 8 on Pro and 32 on Enterprise, with 2 GB of memory per vCPU.

We size each job separately. Deck builds use the SDK default of 2 vCPUs, PDF export and Screen Recorder's media job take 4, and a Meeting relay takes 1. Screen Recorder's HLS job takes 8, because it encodes three quality levels at once from one decode.

Can a sandbox serve traffic, such as a WebSocket server?

Yes, through exposed ports, which Vercel makes reachable at a public URL. The docs warn that a WebSocket connection to a sandbox's public URL can close while the sandbox keeps running, so clients should reconnect and resume their state.

Meeting gives each room its own sandbox running a WebSocket relay on an exposed port. A room is short-lived, so the relay lives and ends with it. We would not host a permanent service this way; Vercel says plainly that sandboxes are not for 24/7 hosting.

Why choose Vercel Sandbox over E2B or Daytona?

We chose Sandbox for its integration with the platform we already run. Monogram Tools already deploys to Vercel, on Vercel the SDK authenticates with the project's OIDC token instead of a separate API key, and our longest sandbox jobs report back to durable Vercel Workflows runs through Workflow webhooks. If your app does not live on Vercel, or you need a long-lived development environment more than a disposable job runner, weigh the alternatives on those terms.

What does Vercel Sandbox cost?

Sandbox bills mainly Active CPU, provisioned memory and creations, plus data the sandbox sends out (including all traffic through exposed ports) and snapshot storage. CPU time spent waiting on a model or a network call is not billed; memory is billed for as long as the VM runs. The practical consequence is to stop a sandbox the moment its output is read. Our build and export jobs end by reading their output back and stopping the VM, and a Screen Recorder run stops its sandbox as soon as it has read the job's result.

When not to use Vercel Sandbox

A sandbox is the wrong tool for small, trusted, fast work. Booting a VM and installing a toolchain costs real seconds, and a function that already has what it needs starts faster.

It is also not a database. A persistent sandbox keeps its filesystem between sessions, but Vercel still advises pushing large or shared data to external storage. Ours run with persistence off, so anything a job produces leaves the VM before it stops, and it goes to Vercel Blob.

Snapshots are a maintenance item, not a one-off. They expire, so a snapshot you depend on needs something that rebuilds it; ours is a weekly cron, plus a cold fallback if the snapshot is ever missing.

If you are deciding where untrusted or heavy work should run, our Next.js and Vercel development team builds on this stack, and you can talk to us about your case.

FAQ

Can I run Docker inside a sandbox? Yes. Vercel supports system-privileged processes such as container runtimes inside the microVM.

Do snapshots last forever? No. They expire 30 days after last use by default, which is why we re-bake ours weekly.

Where can I read more about how we use Vercel? Our Vercel technology page covers the rest of the platform as we use it.