Vercel Sandbox Drives, now in public beta, give sandboxed agents a persistent disk that survives across runs, ending the per-invocation rebuild of node_modules, datasets, and workspace state. The catch: exactly one read-write mount per Drive, concurrent reads only through point-in-time snapshots, and no failover regions. For single-region agent pipelines paying rebuild time per run, that trade is likely worth making at $0.05 per GB-month in iad1, per Vercel’s beta announcement.
Why ephemeral sandboxes tax every agent run
Coding and automation agents are heavy disk users. A typical run installs dependencies, clones or checks out a repository, writes intermediate artifacts, and caches model outputs or test results. In an ephemeral sandbox, all of that disappears when the run ends, so the next run pays the same setup cost again: dependency installation, dataset fetch, cache warm-up. For a pipeline that invokes a sandbox dozens or hundreds of times a day, that rebuild time is the dominant per-run overhead, and it compounds with every agent you add to the loop.
Teams have worked around this in two ways. The first is rebuilding from caches on each invocation, which keeps the sandbox stateless but re-derives state every time. The second is syncing state in and out of object storage, which persists data but adds transfer time at both ends of every run and forces you to write your own consistency logic. Neither is a disk. Both treat persistence as something you simulate around the sandbox rather than something the sandbox provides. Vercel’s new feature is an attempt to make persistence native, and it arrives on top of a sandbox product that was already pushing past laptop-scale limits on compute.
What a Drive actually is
According to Vercel’s beta announcement, a Drive is “persistent storage that you mount as a directory in a Vercel Sandbox,” available in public beta on Hobby, Pro, and Enterprise plans. The defining property is that it is not tied to a single sandbox: “you can reuse the same Drive across runs and different sandbox instances.” Each sandbox can mount up to four Drives at separate paths, so a workspace, a dataset, and a cache can live on distinct volumes with distinct lifecycles.
That is a real change in the programming model. Instead of an agent checkpointing its state by serializing it to an external store, it can checkpoint by simply leaving the filesystem where it is and disconnecting. The next sandbox, possibly a different instance on a different invocation, mounts the same directory and picks up where the last one stopped.
On the integration mechanics, the changelog’s code samples create a Drive with Drive.getOrCreate and attach it through the mounts option on Sandbox.create, with reads and writes going through the sandbox filesystem at the mount path. Confirm the current interface against Vercel’s beta announcement before coding against it; a beta API surface can shift.
Capacity math: 1 TiB by default, 16 TiB if you ask for it
The headline number needs a correction applied before it drives any architecture decision. Drives are not 16 TiB volumes by default. Per the changelog, “Drives default to a maximum size of 1 TiB (1 GiB on Hobby) and can be configured up to 16 TiB, with higher limits available by request.”
So the planning picture looks like this:
| Constraint | Beta term | Decision impact |
|---|---|---|
| Default max size | 1 TiB (1 GiB on Hobby) | Fine for workspaces and dependency caches; Hobby is evaluation-only |
| Configurable ceiling | 16 TiB | Covers large datasets without a quota conversation |
| Above 16 TiB | By request, unpriced | Plan a capacity conversation early if datasets approach it |
| Mounts per sandbox | Up to 4 Drives, separate paths | Lets you separate mutable workspace from read-mostly data |
| Concurrent writers | Exactly one read-write mount | Forces write serialization or Drive-per-writer partitioning |
| Region | Pinned to creation region, no failover regions | Breaks multi-region failover designs |
| Storage price (iad1) | $0.05 per GB-month | Warm 100 GB workspace costs about $5/month |
Two of those rows deserve their own sections, because they reshape multi-agent designs rather than just sizing them.
One writer, many snapshot readers
The concurrency model is the sharpest constraint in the announcement: “A Drive supports one read-write mount at a time. After the Drive has been written to, multiple sandboxes can read from it concurrently by mounting point-in-time, read-only snapshots.”
This is not a shared filesystem. It is closer to a versioned artifact store with a filesystem interface. One sandbox owns the Drive while it works; everyone else who needs the data mounts a frozen, read-only view of it. That has direct consequences for multi-agent pipelines:
- Fan-out pipelines fit naturally. An orchestrator agent builds a workspace (installs dependencies, prepares a dataset), disconnects, and then N worker sandboxes mount snapshots to run evaluations, tests, or analysis in parallel. The snapshot semantics give each worker an identical, immutable starting point, which is often what you wanted anyway.
- Collaborative writers do not fit. Two agents that both need to mutate the same workspace concurrently cannot share a Drive. Your options are serializing write access (a lock or queue around the mount), partitioning state across multiple Drives (one per writer, within the four-mount limit per sandbox), or keeping shared mutable state outside Drives entirely.
- Snapshots are point-in-time. A reader that mounts a snapshot sees the Drive as of snapshot creation, not the writer’s live state. Long-running readers will go stale. The changelog does not state snapshot creation latency or how snapshot versioning is exposed, so treat snapshot freshness as an open operational question, not a guarantee.
The pattern rhymes with what happened when Vercel moved to in-function concurrency: persistence across invocations is genuinely useful, but it transfers coordination problems (who writes, who reads stale data, who owns lifecycle) from the platform to your application.
Region pinning removes your failover story
The second architectural constraint is quieter but harder to design around: “Each Drive stays in the region where it was created. Sandboxes that mount it must run in that region and can’t use failover regions.”
Stateless sandbox designs inherit a pleasant property from serverless: if a region degrades, you run somewhere else. A mounted Drive voids that property. Any sandbox that depends on persistent state is anchored to the Drive’s home region, and the changelog explicitly rules out failover regions for mounting sandboxes. If that region has an outage, your agents do not degrade gracefully to another region with a cold cache; they stop, because their state is unreachable.
That does not make Drives wrong. It makes them a placement decision. The practical guidance:
- Put the Drive in the region where your agent fleet already concentrates, and accept that region as a hard dependency.
- Treat the Drive as a cache of re-derivable state where possible (dependencies, build artifacts, checkpoints), so a regional loss is a rebuild event, not a data loss event. The changelog says nothing about durability guarantees or replication, so assuming re-derivability is the conservative posture.
- If your availability requirements genuinely demand multi-region failover for agent state, Drives are the wrong layer. Keep canonical state in a replicated store and treat any sandbox disk as scratch.
What a warm workspace actually costs
Per Vercel’s changelog, iad1 rates are $0.05 per GB-month storage, $0.0015 per GB reads, and $0.004 per GB writes. The Hobby plan includes 15 GB of storage and 30 GB each of reads and writes per month, enough to evaluate the model but not to run a fleet.
Here is the arithmetic for one plausible workload, drawn from Vercel’s published iad1 rates rather than measurement. Storage runs about $5 per month for a warm 100 GB workspace of dependencies, a checked-out monorepo, and build caches, per the published storage rate. Daily writes of 20 GB and daily reads of 50 GB across snapshot-mounting workers cost, at the same rates, about $2.40 and $2.25 per month. Call it roughly $10 per month for a workspace that a stateless design would rebuild from scratch on every invocation.
Whether that undercuts your current rebuild cost depends on numbers that vary per team and aren’t published here: your per-invocation setup time, the compute rate you pay during setup, and Drive throughput, which Vercel has not published. If a cold rebuild takes two minutes of billable sandbox time per run across hundreds of daily runs, the Drive almost certainly wins on cost and wall-clock time. If your setup is a five-second cache restore, the calculus is thinner and the coordination overhead may not be worth it. Given that Vercel’s agentic infrastructure pricing has outpaced its pricing transparency before, it is worth wiring Drive spend into a usage-based cost gate rather than discovering it on an invoice. Also note the rates are iad1-only in the published material; other regions may differ, and beta pricing may change at general availability.
What happens to agent data when the agent dies
Vercel’s changelog is silent on lifecycle: retention, deletion semantics, and what happens to Drive contents when a project or account is wound down. Other platforms have already made choices here, and they are worth knowing before you let persistent agent state accumulate.
Microsoft’s agent platform illustrates both poles. Per Microsoft 365’s agent lifecycle documentation, deleting an agent removes it from inventory, deletes all associated files, and deletes the underlying SharePoint Embedded container, an irreversible process that can take up to 24 hours to propagate. By contrast, Microsoft Entra’s agent identity controls offer a softer option: disabling an agent blocks users from accessing it and prevents it from being issued tokens, and the documented Enable action reverses the suspension.
The lesson transfers directly. Once agents own persistent disks, you need a deliberate answer to what happens at end of life: suspend or delete, archive or purge, and who can authorize each. Whatever Vercel’s eventual deletion and retention semantics turn out to be, decide your policy now, because persistent storage accumulates state that ephemeral sandboxes never gave you the chance to mismanage.
The vendor-risk ledger
Every product claim in this article traces to a single source: Vercel’s own beta changelog. There are no independent durability figures, no throughput benchmarks, no snapshot-latency numbers, and no SLA terms in the available material. Pricing is published for one region. API names may shift before general availability. That is normal for a beta, but it means any architecture you build on Drives should be cheap to evacuate.
There is also vendor-trust context worth weighing. Vercel is a large, well-capitalized company, having raised a $300 million Series F at a $9.3 billion valuation in September 2025 according to Wikipedia’s Vercel entry. The same entry records that on April 19, 2026, Vercel disclosed a security breach in which unauthorized actors accessed certain internal systems, originating from the compromise of a third-party AI tool, Context.ai. That disclosure is not evidence about Drive security specifically, but it is relevant context when deciding how much sensitive agent state (credentials in workspaces, proprietary datasets, customer data) to place on a single vendor’s beta storage product. Agent workspaces tend to accumulate secrets; design your Drive contents as if you will someday need to rotate everything on them.
The decision
Mount a Drive when your agents run in one region, write from one sandbox at a time, and currently spend enough rebuild time per invocation to notice. The economics, at the published iad1 rates, strongly favor persistence for anything with a non-trivial working set, and the snapshot model fits fan-out pipelines well. Fan readers out through point-in-time snapshots rather than trying to share writable state, partition writers across multiple Drives if you must parallelize mutation, and keep canonical or failover-critical state in an external replicated store.
The honest limitation: this is one vendor changelog for a beta feature, with no independent verification of durability, throughput, or snapshot behavior, pricing for a single region, and terms that may change at general availability. Treat the cost example above as arithmetic from vendor rates, not a benchmark, and confirm the SDK surface and your region’s pricing against current documentation before committing a production pipeline to it.
Frequently Asked Questions
What is the default size limit for a Vercel Sandbox Drive?
Per the changelog, “Drives default to a maximum size of 1 TiB (1 GiB on Hobby) and can be configured up to 16 TiB, with higher limits available by request.”
How much does Vercel Sandbox Drive storage cost in iad1?
Per Vercel’s changelog, iad1 rates are $0.05 per GB-month storage, $0.0015 per GB reads, and $0.004 per GB writes.
Can multiple sandboxes write to the same Drive concurrently?
The concurrency model is the sharpest constraint in the announcement: “A Drive supports one read-write mount at a time. After the Drive has been written to, multiple sandboxes can read from it concurrently by mounting point-in-time, read-only snapshots.”
Join the discussion
Share a useful perspective or ask a question about this article.