Vercel Sandbox adds Docker support with persistent images and isolated container runs
Vercel Sandbox can now build and run Docker containers, persist images and installs across sessions, and host databases or full apps inside the sandbox. That broadens what coding agents and preview environments can validate without leaving Vercel.

TL;DR
- vercel_dev's launch post says Vercel Sandbox can now build and run Docker containers in full isolation, with installs and images persisting across sessions.
- The official Docker in Sandbox changelog, linked by vercel_dev, frames the feature around running databases, test suites, and full apps inside the sandbox.
- Two days earlier, vercel_dev's persistence GA post moved Sandbox to persistent-by-default, adding unlimited snapshots plus APIs like
getOrCreateandfork. - Those persistence primitives matter here because the Docker launch post explicitly promises cached installs and images across sessions, not just one-off container runs.
You can open the Docker launch changelog from vercel_dev's post, trace the persistence rollout in the Sandbox persistence GA changelog linked by vercel_dev, and cramforce's reaction gives the whole thing a succinct endorsement.
Docker containers
The new piece is straightforward: Sandbox now accepts Docker workloads inside Vercel's isolated runtime. vercel_dev's post lists three concrete use cases, databases, test suites, and full apps, which pushes Sandbox beyond lightweight code execution.
That makes the product look more like a container-capable harness for coding agents and previews. The public launch language centers on three capabilities:
- Build and run containers in full isolation, per vercel_dev's launch post
- Persist installs and images across sessions, again from the same post
- Run stateful local dependencies such as databases, according to the official changelog
Persistence primitives
The Docker ship landed on top of a persistence rollout from May 27. According to vercel_dev's persistence GA post, sandboxes are now persistent by default, with automatic unlimited snapshots plus new lifecycle and cloning APIs.
The GA post breaks that rollout into five visible primitives:
- Automatic, unlimited snapshots
getOrCreateforkonCreateandonResumelifecycle hooks- Tags for multi-tenant platforms
Those features explain how Vercel can promise reusable Docker state. Persisted images and installs are much more useful when the base sandbox already supports resume, cloning, and snapshot-style recovery through the persistence changelog.
What can live inside the sandbox
The most concrete product implication is workload scope. vercel_dev's launch post does not pitch Docker as a packaging nicety, it pitches whole classes of software that were awkward in ephemeral sandboxes: app servers, test environments, and local databases.
That means the same Sandbox surface now spans two layers that were announced separately this week:
- Persistent sandboxes with snapshot and fork semantics, from vercel_dev's GA post
- Dockerized services and app stacks with cached installs and images, from vercel_dev's Docker post
Taken together, the release gives Vercel a more credible place to run heavier preview and agent loops without ejecting to external container infrastructure.
Multi-tenant tags
One detail that only appears in the earlier rollout is tags support for multi-tenant platforms, per vercel_dev's persistence GA post. That points at platform builders, not just individual developers, and it is the clearest sign that Sandbox is being shaped for hosted agent products that need to create, resume, and isolate many user environments.
The Docker addition does not mention tags directly, but the timing makes the pairing hard to miss: persistence APIs arrived first, then container support followed two days later.