Vercel Drives Launch: Persistent Storage for AI Agents

AI agents often need to handle complex tasks across multiple runs, potentially switching between different tools, runtimes, or compute environments along the way. The problem: after switching environments, what happens to the work files from before?

Vercel's answer is Vercel Drives—a persistent storage solution that keeps agent files independent of the execution environment. The feature is now generally available (GA) on Vercel Sandbox.

The Problem It Solves: The Agent's "Moving" Dilemma

Agent work is rarely one-and-done. A task might start with data preprocessing in a lightweight environment, then switch to a GPU-equipped environment to run a model, and finally return to a standard environment to generate a report. If every environment switch requires re-transferring data and rebuilding the workspace, the efficiency loss adds up quickly.

Vercel Drives takes a straightforward approach: separate the file layer from the execution layer. A Drive is an independent persistent volume, and a Sandbox simply mounts it. When an agent mounts the same Drive in a new environment, it immediately sees all the files left behind from the previous run—code repositories, intermediate data, generated results, all right where they were.

The key to this design is decoupling. Files are no longer bound to a specific Sandbox instance but exist as a reusable resource. Multiple Sandboxes can mount the same Drive simultaneously, and switching runtimes requires no additional data migration.

Vercel Sandbox is an ephemeral, isolated compute environment provided by Vercel for safely running untrusted or short-lived code. It is ephemeral by design: each creation allocates a new, clean microVM instance that is destroyed once the run completes. This ephemerality is Sandbox's core security property—it ensures one task cannot pollute or affect the next. But it also means Sandbox preserves no runtime state. Drives fills exactly this gap: placing the parts that need persistence onto a volume mounted outside the Sandbox, letting ephemeral environments and persistent data each play their proper role.

Basic Usage: Create, Mount, Run

The workflow has two steps. First create a Drive, then mount it when creating a Sandbox.

CLI approach:

sandbox drives get-or-create agent-workspace
sandbox create --mount agent-workspace:/workspace

SDK approach:

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

const drive = await Drive.getOrCreate({ name: 'agent-workspace' });
const sandbox = await Sandbox.create({
  mounts: { '/workspace': drive },
});
await sandbox.runCommand('git', ['clone', repoUrl, '/workspace/repo']);

Anything under the mount point—/workspace in this example—persists on the Drive, while everything else belongs to the Sandbox's ephemeral environment. The next Sandbox that mounts this Drive will directly find the previously cloned repository and all files written by the agent.

This pattern is especially well-suited for agent workflows that require multi-step, multi-environment collaboration. The agent doesn't need to care about what runtime is underneath—the workspace stays consistent throughout.

Mounting is the operation of associating an independent persistent storage volume with a filesystem path. In the context of Vercel Drives, --mount agent-workspace:/workspace means: mount the Drive named agent-workspace to the /workspace directory inside the Sandbox. Below the mount point, all read and write operations actually land on the Drive; outside the mount point, it remains the Sandbox's local ephemeral storage. This achieves a transparent separation between persistent and ephemeral regions within the same filesystem tree—from the agent's perspective, it's simply reading and writing ordinary file paths, with no need to be aware of the underlying storage boundary.

Cross-Sandbox Sharing and the Fork Mechanism

Drives' capabilities go beyond "handoff." It also supports state sharing and parallel exploration across multiple Sandboxes.

Shared reading is one typical scenario. After one agent builds a dataset on a Drive, other agents can mount a read-only copy for analysis or report generation without rebuilding it. Each agent's results are saved in its own space, without interference.

Fork is designed for situations requiring parallel experimentation. An agent can fork a Drive, with each fork starting from the original content and having its own writable workspace. Multiple agents can simultaneously try different data transformation approaches, with the original Drive unaffected and forks isolated from each other. Note that forks are not merged back into the original Drive—this is more of a "parallel universe"-style exploration mechanism than version control.

Fork is also now generally available.

Copy-on-write is key to understanding the Fork mechanism. When forking a Drive, the system does not immediately copy all data; instead, the new Drive shares underlying data blocks with the original, and only when a fork actually writes to a particular data block is that block copied out. This means fork operations cost approximately O(1)—regardless of how large the original Drive is, the fork completes instantly. Multiple forks remaining isolated from each other while maintaining a consistent read-only view of the original data is precisely the guarantee that copy-on-write semantics provide at the storage layer. Without this mechanism, the cost of exploring different data transformation approaches in parallel would grow linearly with data size.

Capacity and Availability

Vercel Drives is available on all Vercel Sandbox plans. The default capacity is 1 TiB, 1 GiB for the Hobby plan, and can scale up to 16 TiB. Configuration details, snapshot capabilities, and specific limitations can be found in the official documentation, with complete details of GA version changes recorded in the changelog.

Vercel also provides an eve agent starter template with one-click deployment, making it easy for developers to quickly experience Drives combined with agents.

Why This Matters

Agent infrastructure is moving from "can run" to "can keep running." Persistent storage may seem like a low-level capability, but it directly affects whether agents can handle long-cycle, multi-stage complex tasks.

Vercel chose to solve this problem at the Sandbox level rather than having developers build their own file synchronization logic, lowering the barrier to building reliable agent systems. The addition of the Fork mechanism also hints at a direction: future agent parallel collaboration and independent exploration may require native support at the storage layer.

For developers building agent applications, Drives offers an option worth evaluating—especially when workflows involve multi-environment switching or require multiple agents to collaboratively process the same data.

One-line Summary

Vercel Drives decouples agent files from execution environments, enabling cross-Sandbox persistence and Fork-based parallel exploration.

Paragraph Summary

Vercel Drives is a persistent storage solution for Vercel Sandbox, now generally available. It separates the file layer from the execution layer, so agents can switch runtimes or compute environments without migrating their workspace—simply mount the same Drive and continue. The article covers basic usage for creating, mounting, and running, and explains two collaboration patterns: multiple Sandboxes sharing read access to the same Drive, and forking isolated writable copies for parallel exploration (forks are not merged back into the original Drive). Capacity-wise, the default is 1 TiB, 1 GiB for Hobby, up to 16 TiB, available on all plans, with an eve agent template for quick onboarding.