Vercel Drives explained: what it changes for agent storage
What Vercel launched and what it changes
Vercel launched Drives on October 15, 2026, as persistent storage for Vercel Sandbox, and it now describes the feature as generally available on all plans. Generally available: October 15, 2026, on all plans according to Vercel (2026).
For a small B2B company, the change is narrow. An agent's working files can now sit in a named drive that a sandbox mounts at a path, so the files remain after that sandbox stops, and a later sandbox with different tools can mount the same drive and continue. That removes one common reason agent work restarts from zero. It does not decide which agent platform you should run.
A Vercel Drive is a named, persistent directory that a Vercel Sandbox mounts at a path such as /workspace, and files written under that path stay on the drive after the sandbox stops.
TL;DR: Drives keep agent files alive across sandboxes, allow one read-write sandbox at a time, and bill storage per GB. Modal Volumes is the closest rival for shared files, and E2B's persistence pages describe pausing one running sandbox rather than sharing a drive. Act this month only if your agents already lose state between runs.
Naming check: none of the three products in this comparison was renamed, merged, or discontinued on the pages reviewed. Vercel's pricing page does mark older Sandbox runtimes as deprecated, and this guide does not cover them.
Key Takeaways
Vercel Drives became generally available for Vercel Sandbox on October 15, 2026, on all plans, after a public beta that began September 23, 2026.
A drive keeps files after a sandbox stops, but only one sandbox can mount it read-write at a time; other sandboxes read it through read-only snapshots.
Vercel's published Pro rates in the default iad1 region are $0.05 per GB-month for storage, $0.0015 per GB read, and $0.004 per GB written (sourced below).
Modal Volumes is the closer rival for shared files, and it brings commit and reload rules your team would have to operate.
E2B's pricing and persistence pages describe pausing a running sandbox with its memory, not a shared drive.
For a small B2B team, this month's decision rests on one question: does any agent workflow lose files between runs today?
Who this is for
This guide is for the founder, operations lead, or engineering lead at a small B2B software company who has heard about Drives and needs to know quickly whether it changes anything they run. It is written for a buyer choosing between staying put, adding Vercel's storage to an existing Sandbox setup, or comparing it with the main rivals.
Red flags: your team needs several agents to write to one shared workspace at the same time; your agents run once and discard everything, so there is no state to keep; or your data must live in a region other than the one where the drive is created, because a drive's region cannot change after creation.
How we evaluated these tools
We weighted six criteria against what a small B2B buyer actually decides. The weights are our judgment, not a vendor's or a survey's, and they are meant to be changed. If persistence matters less to you than cost, move 10 points from persistence to cost predictability and re-read the table.
| Criterion | Weight | Why it matters to this reader |
|---|---|---|
| Persistence across sandboxes | 25% | Decides whether files survive a new run or a new environment |
| Sharing and write rules | 20% | Decides whether several agents can work from one set of files |
| Cost predictability | 20% | Decides whether a monthly bill can be estimated from published rates |
| Operating limits | 15% | Covers size, mount counts, session length, and file counts |
| Stack fit and region control | 10% | Covers region lock-in and how many new vendors you add |
| Maturity and status | 10% | Covers beta, general availability, and format status at decision time |
Each criterion is scored only from the pages reviewed. Where a page is silent, the comparison says so rather than filling the gap.
What changed between the beta and general availability
The public beta opened on September 23, 2026 for Hobby, Pro, and Enterprise. The beta entry and the general-availability post give the same default sizes, 1 TiB by default and 1 GiB on Hobby, with up to 16 TiB available. The beta entry also states two limits that carry into general availability: a sandbox can mount up to four drives, and a drive supports one read-write mount at a time.
The general-availability post says forking is generally available. The beta entry we read does not describe forking in its text. The general-availability entry does not list what changed from the beta, and the launch post points readers to the changelog for that. The vendor has not published a durability or uptime commitment for Drives in the pages reviewed.
Side-by-side on the seven decisions
| Decision | Vercel | Modal | E2B |
|---|---|---|---|
| Files after the sandbox stops | Persist until deleted | Persist after commit; final commit runs at shutdown | Pause keeps disk and memory; paused sandbox kept indefinitely |
| Sharing across sandboxes | One read-write mount; read-only snapshots for others | Several containers can modify one volume; one writer per file advised | No shared volume described on the persistence page |
| Mount limit per run | Up to 4 drives | Mount options per container, including read-only and sub_path | Not described on the pages reviewed |
| Size cap | 1 TiB default (1 GiB on Hobby); 16 TiB default maximum | 500,000 inodes per volume (v1 hard cap) | Not described on the pages reviewed |
| Copy or fork | Fork copies data; forks do not merge back | Not stated on the pages reviewed | Not stated on the pages reviewed |
| Region control | Fixed at creation; default iad1 | Not stated on the pages reviewed | Not stated on the pages reviewed |
| Session limit | 45 minutes on Hobby; 24 hours on Pro | Not stated on the pages reviewed | 1 hour on Hobby; 24 hours on Pro |
Read across each row. Vercel and Modal both solve persistent files, with different sharing rules, while E2B solves keeping one running machine alive through a pause. Every figure in the matrix is cited in the pricing and vendor profile sections below.
What it costs: published rates and a worked example
Pricing checked October 17, 2026.
Drive storage: $0.05 per GB-month on Pro according to Vercel (2026). The same page lists the same drive storage rate for Pro and Enterprise in the default iad1 region, with reads at $0.0015 per GB and writes at $0.004 per GB. It gives Hobby 15 GB of drive storage over the drive's lifetime and 30 GB each of reads and writes per month, and it states the 1 TiB default drive size, or 1 GiB on Hobby. Drive rates vary by region, so a team outside iad1 must check its own region's rates.
Modal's volume storage costs $0.09 per GiB-month, according to Modal (checked October 17, 2026). On the same page, the Team plan is $250 a month plus compute, with $100 of monthly credits, and the Starter plan is $0 plus compute, with $30 of monthly credits. The page lists sandbox CPU at $0.00003942 per core-second and memory at $0.00000667 per GiB-second. The vendor has not published read or write charges for volumes on this page.
E2B's Pro plan costs $150 a month plus usage, according to E2B (checked October 17, 2026). The same page lists a Hobby tier at $0 with a one-time $100 usage credit, 20 GiB of included storage on Pro, and per-second rates of $0.000014 per vCPU-second and $0.0000045 per GiB-second.
| Cost line | Vercel | Modal | E2B |
|---|---|---|---|
| Storage rate | $0.05 per GB-month for drives on Pro, iad1 | $0.09 per GiB-month for volumes | No separate storage rate listed; 20 GiB included on Pro |
| Reads and writes | $0.0015 per GB read; $0.004 per GB written | Not published on the pricing page | Not published on the pricing page |
| CPU | $0.128 per active CPU-hour on Pro | $0.00003942 per core-second | $0.000014 per vCPU-second |
| Memory | $0.0212 per GB-hour on Pro | $0.00000667 per GiB-second | $0.0000045 per GiB-second |
| Plan fee | Pro sandbox usage draws on a $20 monthly credit | Starter: $0 plus compute; Team: $250 plus compute | Hobby: $0 with $100 one-time credit; Pro: $150 plus usage |
| Enterprise | Quote-based; drive rates match Pro | Quote-based | Quote-based |
The compute rates do not line up cleanly. Vercel bills active CPU per hour and excludes time spent waiting on input and output, such as AI model calls, which its pricing page states. Modal and E2B bill per second on core and vCPU units. Dividing Vercel's $0.128 per hour by 3,600 gives about $0.0000356 per second of active CPU. That figure is our arithmetic, not a vendor number, and the three rates are only comparable once you know how much of a workload's time is active.
Worked example, illustrative only and not a customer: a team's agent keeps 200 GB of working files on one drive for the whole month, reads 500 GB across its runs, and writes 80 GB. At Vercel's Pro rates in iad1, storage is 200 × $0.05 = $10.00, reads are 500 × $0.0015 = $0.75, and writes are 80 × $0.004 = $0.32, so the drive comes to $11.07 before compute. Pro sandbox usage draws on the same $20 monthly credit, so that drive total leaves little room for compute unless the rest of the team's sandbox usage is small. The same 200 GB is about 186.3 GiB, and 186.3 × $0.09 = $16.77 at Modal's volume storage rate, before any read, write, or compute charges, which the vendor has not published on the page reviewed. A team that needs a different maximum sets max_size_bytes in Python, which replaces the 1 TiB default.
Vendor profiles: best fit, limits, and implementation
Vercel Drives
Best fit: teams that already run agents on Vercel Sandbox and want working files to outlive a single sandbox without moving compute to another vendor.
Limitations: a drive takes one read-write mount at a time, it stays in the region where it was created, and a sandbox mounts at most four drives per run. The Drives documentation says you must mount a drive into a sandbox to read or write its files, so the pages reviewed describe access only through a mounted path. Forks do not merge back into the original. The vendor has not published a throughput figure for drives; its documentation describes NVMe-speed writes and cache-hit reads, with slower cache-miss reads, without numbers.
Implementation: create the drive once with Drive.getOrCreate in TypeScript or get_or_create_drive in Python, then pass it in the sandbox's mounts. The SDK takes maxSize in TypeScript and max_size_bytes in Python, and a drive's maximum size must be a multiple of 4096 bytes. Evidence: the Drives documentation and the launch post.
Modal Volumes
Best fit: teams already on Modal that want several containers to share one volume and can build commit and reload discipline into their code.
Limitations: changes from one container are not visible to another until they are committed, and a container that started earlier keeps its original view until it calls reload. Modal's documentation says the same file should not be written by more than one container at a time, and when two containers write one file, the last writer's version replaces the other. Modal advises against more than 5 concurrent commits for small changes, and a reload fails while files are open. According to Modal (checked October 17, 2026), v1 volumes have a hard limit of 500,000 inodes per volume, and volumes work best under 50,000 files and directories. The v2 format is in beta, and the docs say "We cannot yet guarantee that no data will be lost."
Implementation: attach the volume to a Function or Sandbox with mount options. The options can make the mount read-only or expose one subdirectory through sub_path, and they apply per container rather than being stored on the volume.
E2B
Best fit: teams whose agent needs a running environment kept alive, with its memory, between sessions, rather than a file drive shared across sandboxes.
Limitations: the persistence page describes pausing and resuming a sandbox. In the text reviewed, it does not describe a persistent volume or a storage mount that survives across sandboxes. Network connections do not survive a pause, and clients must reconnect after resume. Continuous running is capped at 1 hour on Hobby and 24 hours on Pro, and that cap resets after a pause and resume. Pausing takes approximately 4 seconds per 1 GiB of RAM, and resuming takes approximately 1 second, according to E2B (checked October 17, 2026).
Implementation: auto-pause on timeout is opt-in, and the default action on timeout is kill. The page says a killed sandbox is permanently deleted and cannot be resumed, so a team that relies on resume must enable pause before depending on it.
| Vendor | Choose it when | Skip it when |
|---|---|---|
| Vercel | Your agents already run on Vercel Sandbox and need files to survive between runs | Several agents must write to one drive at the same time |
| Modal | Several containers must share one volume, and your code can handle commits and reloads | You want a single-writer workspace with fewer rules to operate |
| E2B | The main need is pausing a running sandbox with its memory intact | Files must be shared across sandboxes |
What changes for a service business
The practical change for a service business is where a workflow's intermediate files live between runs. The two designs below are proposed US Tech Automations configurations, not deployed systems. Each names its prerequisites and its human review point.
Workflow A, proposed: the trigger is a HubSpot deal moving to a closed-won stage. A configured job reads the deal and contact fields through the HubSpot API, which needs an access credential the buyer issues inside HubSpot, and writes them as a JSON file into a drive mounted at /workspace/onboarding. An agent then drafts an onboarding brief in a sandbox, and the output goes to an approval queue rather than to the customer. The human review point is the account owner, who approves or edits the brief before anything reaches the customer or returns to HubSpot. Prerequisites are a Vercel project with Sandbox access, a drive created through the SDK, and a written rule for how long customer files stay on the drive, since drives persist until someone deletes them, as the Drives documentation describes.
Workflow B, proposed: the trigger is a new message in a shared support inbox. The drafting agent works from help docs mounted as a read-only snapshot, so it cannot overwrite them, and it pulls the customer's order or CRM record through API credentials the buyer grants. The output is a draft placed in an approval queue, with nothing sent automatically. The human review point is a named support lead who approves, edits, or rejects each draft. Prerequisites are Gmail API access for the shared inbox, the read-only snapshot mount, and an agreed escalation rule for angry or legal messages. This follows the approval-queue step the US Tech Automations homepage describes, and the buyer would still own the escalation rule.
Build it yourself, stitch it together, or hand it off
The realistic alternative for most teams is stitching these steps together in Zapier, Make, or n8n, or writing an in-house script. Those tools can keep run histories, retries, error branches, and audit evidence once you configure them, so a no-code build is not automatically unsafe. The buyer still owns the design of observability, idempotency so a retry does not send a second reply, escalation, access controls, and maintenance when a connected API changes. A managed design from US Tech Automations changes who builds and maintains those parts, not whether the review points exist. Its homepage says it maps the process, designs the workflow, and builds it on its own platform, and the buyer would still need the API access and approval steps described above.
When NOT to use US Tech Automations: a managed build is the wrong choice if one engineer can run a single scheduled script and read its logs, if your engineering team already runs agents on Vercel and wants full control over the code and its review, or if one trigger and one action cover the whole process, where a simpler no-code tool is the smaller commitment. For a comparison of coding agents on a narrow automation task, see Claude Code vs OpenAI Codex for accounting automation scripts. For how a buyer's guide sets out criteria for a small team, see Follow Up Boss vs Lofty for solo agents. For how a buyer's guide compares reporting tools, see best reporting and analytics software for real estate agents.
Market context: where small firms and builders stand
Firms with 250+ employees using AI: 37% according to U.S. Census Bureau (2026). The same Census release, published in May 2026, reports 32% for firms with 100 to 249 employees and less than 20% for firms with four or fewer employees, for the collection period ending May 3, 2026. Adoption rises with firm size, so a small B2B team should not assume that the overall AI usage numbers describe its own peers.
Builders rating security and governance top: 43% according to Theory (2026). That survey fielded 455 senior technical builders on September 22, 2026, and its author says 2026 shares are inflated for comparison with 2025 because the 2026 question allowed several answers. Only 10% say security tooling delivers the most value today, and 62% of the 259 teams whose agents write code host their sandboxes on Cloudflare. The sample is builders rather than small-business buyers, so treat these figures as direction, not a forecast for your market.
Signal vs speculation in this launch
Signal, from the pages reviewed:
Drives are generally available for Vercel Sandbox on all plans as of October 15, 2026.
Vercel's Pro drive rates are $0.05 per GB-month for storage, $0.0015 per GB read, and $0.004 per GB written in iad1.
Modal's volume storage is $0.09 per GiB-month, and its volumes need explicit commits and reloads.
E2B's pause keeps memory and disk, and resume takes about 1 second.
The vendor has not published a drive throughput figure or a durability or uptime commitment.
Speculation, our read and not in any vendor's text:
A team with one agent and one workspace is unlikely to hit the one-writer rule soon, so that rule matters most to teams planning parallel agents.
A lower storage rate per GB does not make Drives cheaper overall. Reads, writes, and compute decide the bill, and the three pricing pages bill different items.
Security will probably weigh more than storage price for buyers who keep customer files on a drive, given the survey's 43% figure, though that survey covers builders.
Terms used in this guide
Sandbox: an isolated compute environment where an agent's commands run.
Drive: a named persistent directory mounted into a sandbox at a path.
Read-only snapshot (drive): a point-in-time view of a drive that other sandboxes can mount; it does not include writes made after the mount.
Fork: an independent writable copy of a drive that starts with the source's data and does not merge back.
Commit and reload: Modal's rule that a write becomes visible to other containers only after a commit, and a container sees others' changes only after a reload.
Active CPU: CPU time that code actively uses; on Vercel, time spent waiting on input and output is excluded.
GiB and GB: a GiB is 1,073,741,824 bytes and a GB is 1,000,000,000 bytes, so the same data reads as fewer GiB than GB.
Checklist before you act this month
Name the agent workflow that loses files between runs today. If you cannot name one, stop here.
Confirm that each drive needs only one read-write sandbox at a time; other readers should use read-only snapshots.
Choose the region up front, since a drive cannot change region after creation.
Estimate stored GB and monthly reads and writes, then apply the rates in the pricing section.
Write a deletion rule, because drives persist until someone deletes them.
Name the person who approves any output that leaves the sandbox.
Ask your security owner to review what sensitive data a drive would hold, given that builders rank security first.
Re-check the Vercel changelog before you commit a budget.
Questions small teams ask about Vercel Drives
Is a Vercel Drive a database?
No, a drive is a directory of files that a sandbox mounts, and the Drives documentation describes it as persistent storage you mount into a sandbox as a working directory.
Can two agents write to one drive at the same time?
No, a drive takes one read-write mount at a time, and other sandboxes can read it through read-only snapshots.
Do files survive after a sandbox stops?
Yes, files written to a drive persist after the sandbox stops, and a later sandbox can mount the same drive to pick up where the last run left off.
Does forking merge changes back into the original drive?
No, a fork gets its own writable copy of the data, and forks do not merge back into the original drive.
What does a small team get on Hobby?
Hobby includes 15 GB of drive storage over the drive's lifetime, 30 GB each of reads and writes per month, and a 1 GiB default drive size, as the Vercel pricing page lists them.
Is Vercel Drives cheaper than Modal Volumes?
Per GB, Vercel's $0.05 storage rate is lower than Modal's $0.09 per GiB-month rate; converting Modal's rate to per GB gives about $0.084 by our arithmetic. The monthly bill also depends on reads, writes, and compute, and the two pricing pages do not bill the same items, so the answer depends on your workload.
Should a small team act this month?
Act this month only if an agent workflow already loses files between runs and you can name the person who owns the drive's data and its deletion.
Whether to act this month
Vercel Drives changes one thing for a small B2B team: working files can outlive the sandbox that made them, under published rates and clear one-writer rules. If an agent workflow already loses state between runs, pilot one drive with one writer and a named deletion rule. If it does not, file Drives as an option for the next agent project and watch the Vercel changelog. For a team that wants the review steps and API connections built and run for it, see how US Tech Automations configures this for the approval queue and the support-inbox workflow described above.
About the Author

Helping businesses leverage automation for operational efficiency.