Vercel Sandbox now supports Drives in private beta. This is the missing piece for anyone building workflows that need state to survive between sandbox runs.
The problem with ephemeral sandboxes is exactly that: they are ephemeral. Everything inside disappears when the sandbox stops. Drives change that. A drive has a lifecycle independent from any sandbox, so the data you write in one run is still there for the next.
The mechanic is straightforward. You create a drive once. When you start a sandbox, you mount that drive at a configurable path. The sandbox runs, writes whatever it needs, then stops. The drive stays. You can attach it to a later sandbox and pick up exactly where you left off.
This opens up use cases that were awkward or impossible before. Persistent caches, incremental build artifacts, datasets that grow across runs, long-running agent workflows that need to read and write durable state without rebuilding context from scratch every time.
To get started, you install the beta SDK (@vercel/sandbox@beta) or the beta CLI (sandb). From there, you can create and mount a drive in your sandbox setup.
The feature is in private beta, so access is limited for now. But if your current sandbox-based architecture is working around ephemerality with external storage hacks, workarounds, or re-downloading the same data on every run, this is worth tracking closely.
The concrete action today: install the beta SDK or CLI, request private beta access, and prototype the one workflow in your stack that suffers most from sandbox state being wiped on every stop. Drives are the direct fix for that pattern.