Vercel Drives Hits GA: Persistent Storage for Sandbox

Vercel has announced that Drives is now generally available for Vercel Sandbox, across all three tiers: Hobby, Pro, and Enterprise. This marks the moment Vercel finally fills in the "persistent storage" piece of the puzzle when running AI Agents and code sandboxes.

What Problem Does Drives Solve

Until now, a typical pain point with Sandbox was that files inside the sandbox disappeared once it stopped. Every run had to prepare dependencies, datasets, or intermediate artifacts from scratch. Drives has a clear positioning — it's a piece of persistent storage that can be mounted as a directory into a Sandbox, files remain after the sandbox stops, and subsequent runs or other Sandboxes can access them directly by mounting the same Drive.

Officially, there are two main use cases: one is saving an Agent's workspace or file-based memory so the model retains state across runs; the other is sharing datasets, model weights, dependencies, and build artifacts across sandboxes. Both directly address the most common infrastructure gaps when deploying AI Agents today.

Why the Code Is So Short

Looking at the official example, the mounting logic is compressed to the bare minimum: get the Drive via Drive.get({ name: 'base-drive' }) from @vercel/sandbox, then mount it to the /data directory when calling Sandbox.create. What's interesting here is the API design — persistence is folded into Sandbox's mounts parameter rather than a separate storage SDK, so developers don't need to learn a new storage abstraction.

This "mount-and-go" form is very close to the familiar Volume mounting in the container ecosystem, with low migration cost.

Fork: An Isolation Solution for Parallel Workers

Drives also supports Fork: copying a Drive into an independent writable Drive. A Fork inherits the source Drive's data, region, and maximum capacity, but from then on each stores its own changes.

The official code example is exactly this scenario — deriving two Forks, worker-0 and worker-1, from base-drive, mounting each into an independent Sandbox, and deleting the Forks after the run finishes. This way multiple parallel Workers can start from the same saved workspace, their changes don't affect each other, and they don't pollute the original Drive.

For teams running batch jobs, parallel evaluations, or distributed Agents, Fork turns "shared initial state + isolated writes" into a two-line API.

Copy-on-Write (CoW) is the key design idea behind the Fork mechanism. In traditional approaches, copying a piece of storage often means fully copying all the data, with cost growing linearly with data volume; CoW lets a forked Drive initially retain only a lightweight reference to the source data, and only when a Fork actually modifies a file does it copy out the changed data blocks separately. This means that no matter how large the source Drive is, Fork creation is nearly instantaneous, and the read-only portions shared by multiple Workers don't consume duplicate space. Understanding this helps in judging the applicable boundaries of Drives: Fork suits scenarios of "starting from the same initial workspace and producing different results," rather than high-write workloads that need to continuously write large amounts of new data after forking.

What It Means for AI Agent Infrastructure

The value of Drives goes beyond "files don't get lost." It extracts the Agent's memory and workspace from the volatile execution environment, turning them into a reusable, forkable resource — consistent with the current trend of Agent architectures moving from "one-off calls" to "long-running."

It should be noted that the above analysis is based on official release information and example code; actual performance, concurrency limits, and cross-region behavior still need to be validated under real workloads. Drives documentation is already public, and teams are advised to try it first in small-scale parallel Worker scenarios before deciding whether to use it as their core storage layer.

Agent Memory is usually divided into short-term and long-term categories. Short-term memory is the context within a single session, disappearing when the session ends; long-term memory needs to persist across multiple runs, with common implementations including vector databases, external key-value stores, or simply writing to files. Drives takes the "files as memory" route — the Agent writes its workspace, notes, and intermediate artifacts as ordinary files, and the next run can read them by mounting the same Drive, without introducing an extra memory service. This is especially natural for coding Agents centered on code operations, since they already interact with the outside world through the file system. However, file-based memory is inferior to dedicated databases in retrieval efficiency and concurrent write consistency, and still needs evaluation at scale.

One-line Summary

Vercel Drives is now GA, filling in the critical puzzle piece of persistent storage for Sandbox.

Paragraph Summary

Vercel has announced that Drives is now generally available for Vercel Sandbox, covering the Hobby, Pro, and Enterprise tiers, solving the previous pain point where files inside the sandbox disappeared once it stopped. Drives is a piece of persistent storage that can be mounted as a directory into a Sandbox; files remain after the sandbox stops, and other Sandboxes can access them by mounting the same Drive. Officially, there are two main use cases: saving an Agent's workspace or file-based memory to retain state across runs, and sharing datasets, model weights, and build artifacts across sandboxes. The API is folded into Sandbox's mounts parameter, so there's no need to learn an extra storage SDK. Drives also supports Fork, copying a Drive into an independent writable replica that inherits data, region, and capacity limit — ideal for parallel Workers sharing an initial state with isolated writes.