Vercel Sandbox Drives: Persistent Storage for Disposable VMs

Vercel Sandbox drives just landed in private beta, and the interesting part is not the feature itself but what it admits: disposable compute and persistent storage want to be separate things. Vercel announced it in their changelog on 5 June 2026. A drive is persistent, attachable storage with a lifecycle of its own. You create it once, mount it at a path when a sandbox starts, and it survives after the sandbox stops.

If you have ever watched an ephemeral VM throw away a 400 MB node_modules you just installed, you already understand why I think this is a bigger deal than a one-line changelog suggests.

---

🔍 What a drive actually changes

Before this, a Vercel Sandbox was a clean room you walked into and then burned down. Great for isolation, painful for anything you wanted to keep. Drives split the two concerns apart.

The official wording is short, so here is the honest version of what is and isn't on offer:

Property	Sandbox (compute)	Drive (storage)
Lifecycle	Disposable, dies on stop	Persists independently
Mount	The running environment	Mounted at a configurable path
Concurrent access	Many sandboxes	One read-write sandbox at a time (during beta)
Production-ready?	Yes	No — beta, not for production data

That "one sandbox read-write at a time" line is the constraint to internalise. This is not shared network storage you fan out across a fleet. It is a disk you hand to one worker, then pass to the next.

Key takeaway: Drives decouple what you keep from what you run. Compute stays cheap and throwaway; your repo, dependencies, and build cache stop dying with it.

---

🛠️ Where this earns its keep

Vercel lists three use cases, and each maps to a real pain I have hit:

1. Keeping agent workspaces across disposable sandboxes. An AI agent that clones a repo, edits files, and runs tests can now resume from where it left off instead of re-cloning every loop.
2. Retaining cloned repositories, dependencies, and build outputs. The classic CI tax — reinstall everything on every cold start — gets cheaper.
3. Managing data independently from the sandbox lifecycle. Storage you can attach, detach, and reattach without coupling it to a single run.

The agent angle is the one I would watch. If you are building anything that runs untrusted or self-written code in a loop, the install-everything-again step is pure dead time and wasted compute. A persistent drive turns that into a warm cache.

# Install the beta tooling (names per the Vercel changelog)
npm i @vercel/sandbox@beta
# or the CLI
npm i sandbox@beta

I am deliberately not pasting a full create-and-mount script here, because the exact API surface is moving under beta and I would rather you read the current docs than trust a snippet that ages in a week.

---

💡 Why I read this as a pattern, not a product

Every serious "run code in the cloud" platform eventually rediscovers the same split: ephemeral execution plus durable state. We have seen it with serverless functions bolting on persistent volumes, with CI systems adding dependency caches, with notebooks adding attached disks. Drives are Vercel arriving at the same conclusion for their Sandbox product.

For a Sri Lankan builder on a learning budget, the lesson is portable even if you never touch Vercel:

• Treat compute as cheap and replaceable. Do not pay to keep a VM warm just to keep its disk.
• Treat state as the thing worth persisting. Cache dependencies and build outputs deliberately, not by accident of an idle server.
• Design so a worker can die and resume without redoing expensive setup.

That mental model is free. It works on a $5 droplet, a GitHub Actions runner, or a sandbox in a private beta.

The bottleneck for most small teams is not raw compute. It is wasting compute re-doing setup that should have been kept.

---

⚠️ The fine print I would not skip

This is a private beta, and Vercel is explicit on two points worth repeating:

• Do not put production data on a drive yet. Beta storage is for experiments, not your customers' records.
• Access is waitlisted — you sign up and wait, you do not flip it on today.

There is also the single-writer limit. If your design assumes several sandboxes hammering the same drive at once, that does not work here during beta. Plan for one writer, or a hand-off pattern where workers take turns.

Decision	Safe in beta?
Cache deps for an agent loop	✅ Yes
Persist a build cache for CI experiments	✅ Yes
Store user/production data	❌ No
Multi-writer shared volume	❌ No (one writer at a time)

---

🚀 What this means for you

If you are experimenting with AI agents, automated CI, or any "spin up a clean environment, do work, tear it down" pattern, Vercel Sandbox drives are worth joining the waitlist for. The value is the warm cache: clone once, install once, and let throwaway compute reuse it.

If you are not on Vercel, take the design idea anyway. Split your stack into disposable compute and durable state, and you will spend less money and less time on cold-start busywork no matter where you host.

For my own AI-tool work I lean on browser-side execution wherever I can, precisely to avoid keeping servers warm. If you want to see that philosophy in practice, the free tools on induwara.lk run as much as possible in your browser, so there is no sandbox to persist in the first place. Different scale, same instinct: keep the expensive part replaceable, keep the valuable part close.

For now I would file drives under "promising primitive, beta caveats apply." The feature is small. The pattern it endorses is not.