Vercel Sandbox goes multi-region with four launch regions and failover

What changed

Vercel Sandbox, the isolated environment service that developers drive through an SDK and CLI, is no longer pinned to a single location. According to a Vercel changelog post, sandboxes can now run in four regions: iad1 in Washington, D.C., sfo1 in San Francisco, cle1 in Cleveland, and cdg1 in Paris. iad1 stays the default, and Vercel says support for all of its remaining regions is coming soon.

Latency is the stated motivation. Vercel advises choosing a region close to the databases, object storage, and other backing services a sandbox touches, cutting the round-trip time between the environment and its dependencies. Teams whose infrastructure sits in Europe previously had to accept a cross-Atlantic hop for sandbox operations.

Region selection on every plan

Region selection is available on all plans, Vercel says. A project's default region can be set from the Settings > Sandboxes page, or from the Vercel CLI:

vercel project update my-project --sandbox-region cdg1 --sandbox-failover-regions iad1,cle1

The SDK picks up the project's configured regions by default, so existing code needs no changes to inherit a new default. For per-sandbox control, Sandbox.create() accepts a region argument plus an optional failoverRegions list:

js import { Sandbox } from "@vercel/sandbox";

const sandbox = await Sandbox.create({ region: "cdg1", failoverRegions: ["iad1", "cle1"], });

The standalone Sandbox CLI exposes the same choice through flags:

sandbox create --name my-sandbox --region cdg1 --failover-regions iad1,cle1

Vercel notes that tooling must be updated first: @vercel/sandbox for the SDK, sandbox for the CLI, and vercel for the Vercel CLI.

Failover and the snapshot catch

Failover regions are reserved for Pro and Enterprise teams. When the primary region is unavailable, new sandboxes start in the closest configured failover region, which keeps automated pipelines that depend on sandbox creation from stalling during a regional outage.

Snapshots come with a constraint: they remain in the region where they were created and cannot be moved. Creating or resuming a sandbox from a snapshot normally requires both to be in the same region. During failover, Vercel handles this automatically by loading the snapshot across regions, so resumption still works even when the sandbox lands somewhere other than the region that originally hosted it.

Why it matters

Sandbox startup and execution speed is heavily influenced by the distance to the services the sandbox calls, so regional placement translates directly into measurable wait time for every preview run or automated workflow. A Paris region also gives teams a way to keep sandbox compute on the same continent as their data stores, which matters for latency and for anyone with data-location expectations.

Failover regions add a resilience story for workflows that treat sandbox creation as infrastructure: if one region degrades, work continues elsewhere without code changes. The one design wrinkle to plan around is snapshot locality. Since snapshots cannot migrate between regions, teams that rely on resume-from-snapshot should decide which region to pin as default before accumulating state in the wrong place.