Vercel Sandbox expands from 4 to all 20 compute regions with failover support

The expansion

Vercel Sandbox can now run in all 20 of Vercel's compute regions, up from four previously, according to an announcement on the Vercel blog. The most immediate effect is latency: sandboxes no longer need to run in a handful of fixed locations, and can instead sit in the same region as the databases, storage and other services they access. Requests between a sandbox and its dependencies then stay within a region rather than crossing continents.

Vercel also frames the change as a matter of control. Wider coverage lets teams decide where workloads execute, which the company says helps align sandbox usage with data residency and regional processing requirements.

Region defaults and failover

The iad1 region remains the default, and region selection itself is available on every plan. Pro and Enterprise teams get an additional option: configurable failover regions. If Vercel cannot create a sandbox in the primary region, it tries each configured failover region in order until one succeeds.

For teams with strict compliance postures, both the primary and failover regions can be limited to approved geographies. That closes a subtle gap — without restrictions on where failover can land, an automatic fallback could in principle move execution into a jurisdiction the team has not cleared.

How to configure it

The changelog describes three configuration surfaces:

• Project defaults: a default region for new sandboxes can be set in the project dashboard under Settings > Sandboxes.
• SDK: pass a region and a failoverRegions array to Sandbox.create(). Vercel's example provisions a sandbox in Sydney (syd1) with Hong Kong (hkg1) and Singapore (sin1) as failovers.
• CLI: sandbox create --name my-sandbox --region syd1 --failover-regions hkg1,sin1 produces the same result from the command line.

A region passed at creation time overrides the project default. Existing sandboxes are not migrated; they continue to run in the regions where they were created.

Pricing and compatibility

Two operational details accompany the rollout. Pricing is region-dependent: Vercel notes that Active CPU and Provisioned Memory rates vary by region, so teams moving workloads to a new location should check the Sandbox pricing rather than assume iad1 rates carry over. And tooling has a version requirement — the SDK and CLI must be updated to their latest versions before one of the newly supported regions can be selected.

Why it matters

Sandboxed compute is only as fast as the distance between the sandbox and the systems it touches. A workload that makes many small calls against a database or API pays a network round trip on each one, and cross-region latency can dominate the runtime of chatty tasks. Letting the sandbox run next to its dependencies removes that penalty without any changes to the code running inside it.

The residency angle may matter even more. As more development and testing work happens inside managed cloud environments, the question of where that processing runs becomes a compliance question, not just a performance one. The ability to pin both primary and failover regions to approved geographies is what turns regional availability from a latency feature into something a regulated team can actually adopt.

Failover regions add a resilience layer on top: a failure in one region no longer has to block sandbox creation outright, provided a fallback list is configured and the fallbacks themselves stay within approved borders.