Confirmed public-beta limitsUp to four Drives per sandbox, one read-write mount per Drive, and region-matched sandboxes for every mount.
Vercel Sandbox Drives add persistent directories across sandbox runs
Vercel made Sandbox Drives available in public beta on September 23, 2026 for Hobby, Pro, and Enterprise plans. A Drive is a persistent directory that can be mounted into a Vercel Sandbox, updated during one run, then mounted again by a later sandbox. Vercel positions it for agent workspaces, on-disk memory, datasets, models, dependencies, and build artifacts. The release reduces the need to rebuild a working directory for every short-lived execution.
The public beta has explicit sharing, region, size, and billing rules
Vercel's September 23 announcement says one sandbox can mount a Drive read-write at a time. Concurrent readers use point-in-time snapshots that do not receive later writes. The model favors one controlled writer and many stable readers, not several agents editing the same workspace.
The current Drives documentation allows up to four Drives per sandbox. A Drive defaults to a 1 TiB maximum on paid plans and 1 GiB on Hobby, with a default maximum quota of 16 TiB. It stays in its creation region, and any sandbox mounting it must use that region without failover regions. Drives persist until manually deleted.
Billing covers logical storage, reads, and writes and varies by region. In `iad1`, Vercel lists $0.05 per GB-month stored, $0.0015 per GB read, and $0.004 per GB written. Price the real workload before treating a cache or model corpus as free infrastructure.
Seuil analysis: persistence turns hidden agent state into a product surface
A stateless sandbox can lose work. A persistent workspace can resume the wrong branch, reuse obsolete dependencies, trust an earlier file, or carry material into the wrong context. Model the Drive as shared application state, not a larger home folder.
Define ownership first: user, organization, project, task, or environment. Then set initialization, writers, retained paths, maximum age, version markers, quotas, deletion, and recovery. Keep authoritative workflow state and permissions in structured records. Use the Drive for files that need filesystem semantics and retain their provenance.
Test a clean start, correct resume, interrupted write, stale snapshot, full quota, deleted Drive, region mismatch, and attempted cross-tenant mount. Add those cases to the task-quality checks in Seuil's AI value measurement analysis. A fluent result from contaminated state still fails.
Persistent workspaces need trust boundaries and a recovery path
Files can contain untrusted instructions as well as data. NIST's agent hijacking evaluation work describes attacks hidden in emails, files, and websites. Persistence extends that exposure when repositories, notes, tool output, or configuration are reused without validation.
Separate trusted configuration from task data. Keep secrets and policy files out of model-directed storage. Classify inbound files, restrict executable paths, record the producing task and tool, and narrow write access. Read-only snapshots give reviewers an immutable point in time, but immutability does not make contents trustworthy.
Design recovery before the workspace matters. Keep a reproducible seed, version important artifacts, and review destructive changes. Vercel documents mounting and deletion, not application-level backup, rollback, malware scanning, or product-specific tenant isolation. The adopting team still owns those controls.
Choose a Drive when files must persist independently of the sandbox image
Vercel distinguishes Drives from sandbox snapshots. A snapshot gives each new sandbox an independent copy of a captured filesystem. A Drive keeps one mounted directory evolving across runs. Use a snapshot for installed tools and a Drive for project files or a shared cache.
Do not use a Drive merely because an agent needs memory. Summaries, permissions, approvals, job state, and audit events need structured queries, validation, and retention rules. Large immutable assets may fit object storage. Drives are strongest when tools expect files or rebuilding a directory is costly.
For a hypothetical coding agent, seed a known revision, mount one project Drive, allow one writer, and give test sandboxes read-only snapshots. Record the revision and snapshot behind every result. If the workspace cannot be reproduced or discarded cleanly, persistence has reduced operability.
| Option | How state behaves | Best fit |
|---|---|---|
| Drive | One mounted directory evolves across runs; one writer and concurrent point-in-time readers | Project files, shared caches, datasets, and on-disk agent workspaces |
| Sandbox snapshot | Each new sandbox receives an independent copy of the captured filesystem | Repeatable tools, dependencies, and a known environment seed |
Public beta status leaves reliability and operating details to verify
The feature is available now as a public beta. Vercel confirms limits, regions, mount behavior, persistence until deletion, and pricing. It does not publish a Drive-specific SLA, backup guarantee, recovery objective, encryption-key options, performance benchmark, or general-availability date. Do not infer them.
What product teams should verify before a pilot
- Choose the owner, region, maximum size, retention period, and exact paths that may persist.
- Use one controlled writer and versioned read-only snapshots for parallel review or tests.
- Separate trusted configuration, secrets, structured workflow state, and untrusted workspace files.
- Test clean start, resume, stale state, interrupted writes, quota exhaustion, deletion, and recovery.
- Measure regional storage, read, write, and compute costs with the real access pattern.
- Confirm beta support, durability, backup, compliance, and migration requirements directly with Vercel.
Drives remove an infrastructure obstacle, not the need to decide what an agent remembers or trusts. If persistence is a product requirement, Seuil Digital's AI product work can help frame state, evaluation, and recovery before the beta becomes an invisible dependency.