Vercel Sandbox now runs globally, starting with four regions: iad1
(Washington, D.C.), sfo1
(San Francisco), cle1
(Cleveland), and cdg1
(Paris).
iad1
remains the default. Support for all Vercel regions is coming soon.
Choose a region close to the databases, object storage, and other services your sandboxes access to reduce latency.
Region selection is available on all plans. Pro and Enterprise teams can also configure failover regions. If the primary region is unavailable, new sandboxes start in the closest configured failover region.
Snapshots stay in the region where they were created and can't be moved. To create or resume a sandbox from a snapshot, both must be in the same region. During failover, Vercel handles this automatically by loading the snapshot across regions.
Update the SDK or CLI you use to the latest version:
pnpm install @vercel/sandbox@latest # Sandbox SDKpnpm install -g sandbox@latest # Sandbox CLI pnpm install -g vercel@latest # Vercel CLI
Configure the default region and failover regions from Settings > Sandboxes in your project, or with the Vercel CLI:
vercel project update my-project --sandbox-region cdg1 --sandbox-failover-regions iad1,cle1
Configure Sandbox defaults with the CLI.
By default, the SDK uses the regions in your project settings. To override those defaults, pass region
and, optionally, failoverRegions
to Sandbox.create()
:
import { Sandbox } from "@vercel/sandbox";
const sandbox = await Sandbox.create({ region: "cdg1", failoverRegions: ["iad1", "cle1"],});
Create a Sandbox in cdg1 with iad1 as a failover region using the SDK.
Or specify regions when creating a sandbox with the Sandbox CLI:
sandbox create --name my-sandbox --region cdg1 --failover-regions iad1,cle1
Create a Sandbox in cdg1 with iad1 as a failover region using the CLI.
Learn more in the Sandbox regions documentation.
Facts Only
* Vercel Sandbox runs globally starting in iad1, sfo1, cle1, and cdg1.
* iad1 is the default region.
* Region selection allows users to choose locations near databases for reduced latency.
* Pro and Enterprise teams can configure failover regions.
* New sandboxes start in the closest configured failover region if the primary region is unavailable.
* Snapshots remain fixed in their creation region and cannot be moved.
* Creating or resuming a sandbox requires both operations to occur in the same region unless automatic cross-region loading occurs during failover.
* The Sandbox SDK and CLI can be updated using `pnpm install` commands.
* Region and failover regions can be configured in project settings or via the Vercel CLI (`vercel project update`).
* Sandbox creation parameters (region, failoverRegions) can be passed directly to API calls or CLI commands.
Executive Summary
Full Take
The implementation of multi-regional sandbox infrastructure introduces a layered resilience structure where location and availability are explicitly managed by the user through configuration. The default setting of iad1 establishes a baseline operational reality, while the provision of multiple regions (iad1, sfo1, cle1, cdg1) directly addresses performance concerns by linking sandbox execution to physical proximity to data stores. This creates an expectation that latency reduction is a primary driver for regional architecture.
The mechanism surrounding snapshots and failover reveals an attempt to balance immutability with availability. The constraint that snapshots cannot be moved suggests a prioritization of data integrity over immediate geographic mobility, yet the automatic handling of snapshot loading during failover demonstrates an operational commitment to service continuity across geographical boundaries. This setup implies a tension between local consistency (snapshot location) and global resilience (failover).
The command-line interface and SDK integration suggest that control over this complex system is distributed: users can manage defaults via settings, or exert explicit control over sandbox creation via CLI parameters. The pattern here suggests an evolution from monolithic deployment to finely tuned, policy-driven infrastructure where regional awareness becomes a feature of the service layer, moving beyond simple hosting to encompass data and execution topology. What does this imply about managing distributed state when local constraints (snapshot immutability) clash with global requirements (failover availability)?
Sentinel — Human
This text reads like official product documentation announcing a feature rollout and providing configuration steps, exhibiting high technical specificity consistent with source material.