Vercel Drives Goes GA: Agent State That Outlives Sandboxes

Summary: Vercel Drives is now generally available for Vercel Sandbox on Hobby, Pro, and Enterprise, per Vercel’s announcement on October 15, 2026. A Drive is persistent storage you mount as a directory in a sandbox, and its files survive after the sandbox stops. For anyone building agents that span multiple runs or environments, this removes the awkward part where state lives and dies with the compute.

Why persistent storage changes the agent loop

Vercel’s launch post makes the case plainly: agents handle work that continues across runs, and as that work evolves they may need a new environment with different tools, runtimes, or compute. The files should come along. Drives keep an agent’s files independent of its execution environment — create a drive once, mount it into any sandbox, and the next run picks up exactly where the last one stopped.

Concretely, everything under the mount point persists on the drive; everything else belongs to the ephemeral sandbox. An agent can clone a repo into /workspace, die mid-task, and a fresh sandbox with the same mount finds the repository and any partial work intact. No transfer scripts, no checkpointing layer you have to build yourself.

import { Sandbox, Drive } from '@vercel/sandbox';

const drive = await Drive.getOrCreate({ name: 'agent-workspace' });
const sandbox = await Sandbox.create({
  mounts: { '/workspace': drive },
});

There’s also a CLI path (sandbox drives get-or-create plus sandbox create --mount) if you prefer driving sandboxes from scripts.

Two patterns in the announcement go beyond simple persistence.

First, shared inputs. One agent can build a dataset on a drive, and other agents mount read-only copies to analyze it or produce reports — without anyone rebuilding the dataset. That turns a drive into a lightweight data product between agents.

Second, forking. You can fork a Drive into independent writable copies that inherit the source’s data, region, and maximum size, then store their own changes. Parallel workers start from the same files and diverge without touching the original or each other. Notably, forks don’t merge back into the original — this is branch-and-discard, not git-style collaboration. Treat a fork as an isolated experiment: run it, keep the results you care about, delete the fork.

const drive = await Drive.get({ name: 'base-drive' });

for (let i = 0; i < 2; i++) {
  const fork = await drive.fork({ name: `worker-${i}` });
  const sandbox = await Sandbox.create({
    mounts: { '/data': fork },
  });
  // Run the session, then delete the fork
  await fork.delete();
}

If you’ve been thinking about Vercel’s three-layer model for agentic infrastructure, Drives slot naturally into the compute-and-state layer: the model routing and workflow pieces stay the same, but agents no longer lose their workspace when the environment gets recycled.

Limits and sizing at GA

A few numbers worth knowing before you plan around it:

Drives default to 1 TiB, or 1 GiB on Hobby, with up to 16 TiB available.
Forking is generally available alongside the core feature.
Vercel’s blog points to its documentation for configuration, snapshots, and limits — the supplied sources don’t detail snapshot mechanics, so check the docs before relying on point-in-time recovery.

How I’d evaluate it

The real test is whether Drives replaces the custom glue most agent projects carry: a blob store for state, some sync logic between runs, and ad-hoc handling of parallel experiments. If your agents already run in Vercel Sandbox, mounting a named drive is close to zero marginal cost. If your workloads live elsewhere, the fork semantics are the interesting idea to steal — isolated, writable divergent workspaces with no merge obligation is a clean contract for parallel agents.

One caveat to keep in mind: persistence is only useful if your state format survives environment changes. A drive preserves bytes, not compatibility — if the next run uses a different runtime or toolchain, your files carry over, but your assumptions about them may not. Start with one agent workflow that currently loses state between runs, mount a drive, and see how much glue code falls away.

Sources

Original post

View the original post on X