Vercel Drives reaches general availability with persistent storage for sandboxed agents

Vercel has moved Drives, its persistent storage feature for Vercel Sandbox, to general availability. According to a Vercel blog post and an accompanying changelog entry dated October 15, 2026, the feature is now open to Hobby, Pro, and Enterprise plans.

What a Drive does

A Drive is durable storage that attaches to a sandbox as a mounted directory. Files kept on the drive outlive the sandbox: once a run finishes, a later run or an entirely different sandbox can mount the same drive and find everything where the previous session left it. Anything written outside the mount path belongs to the sandbox and is not preserved.

Vercel frames the feature around agents whose work stretches across runs and environments. As a task evolves, an agent may need to move to a new environment with different tooling, runtimes, or compute resources. Drives decouple the agent's files from where its code executes, so it can start a fresh sandbox or switch runtimes without first copying its workspace over.

Creating and sharing drives

From the CLI, a drive is created with sandbox drives get-or-create agent-workspace and attached with sandbox create --mount agent-workspace:/workspace. The Sandbox SDK offers the equivalent: fetch a handle with Drive.getOrCreate, then pass a mounts map such as { '/workspace': drive } to Sandbox.create. In the blog's example, everything written under /workspace lands on the drive, so a sandbox that clones a repository there leaves it ready for whichever run mounts the drive next.

Vercel suggests using drives to keep an agent's working files or file-based memory between runs, and to make datasets, models, dependencies, and build artifacts reusable across sandboxes. One agent can build a dataset on a drive while others mount read-only copies to analyze the data or produce reports without rebuilding it, writing their outputs separately.

Forking for parallel work

Drives can also be forked into independent writable drives. According to the changelog, a fork starts with the source drive's contents and matches its region and size cap, then records its own changes. Parallel workers can therefore begin from identical files without disturbing the original or each other. The blog adds a caveat: forks do not merge back into the source drive, so each fork is a one-way branch that callers delete when finished. The changelog's SDK snippet forks a base drive into two worker drives, mounts each in its own sandbox, and cleans the forks up afterwards.

Plans and limits

Drives default to 1 TiB of storage, or 1 GiB on the Hobby plan, and scale up to 16 TiB. Vercel points to the Drives documentation for configuration, snapshots, and limits, and offers an eve agent starter template that deploys the pattern in one click.

Why it matters

Sandboxed execution is usually ephemeral by design, which suits short-lived web workloads but clashes with agents that accumulate files, dependencies, and memory over longer tasks. Persistent, mountable storage closes that gap: state follows the agent rather than the container, and teams running agents no longer need to bolt object storage and sync logic onto every workflow. Forking also maps neatly onto a common agent pattern — launching several approaches over the same dataset and comparing results in isolation. With Drives at GA, Vercel rounds out Sandbox as an execution platform for agentic workloads rather than just isolated code runs.