Regions

Daytona runs sandboxes in multiple geographic regions. Every sandbox is placed in exactly one region at creation time, and the resources that feed it — images and snapshots — follow it there. For most workloads you never have to think about this: a platform default region is always configured, and creates without an explicit region land there. When latency or data residency matters, you can steer placement per create.

Discovering regions

GET /regions returns the catalog of currently active regions. Each entry carries the region's id (the slug you pass at create time), a human-readable name, its status, and whether it is the platform default:

curl https://api.rl.trydaytona.com/regions \
  -H "Authorization: Bearer $RLP_API_KEY"

[
  {
    "id": "us-west-1",
    "name": "US West",
    "status": "active",
    "is_default": true,
    "toolbox_proxy_url": "https://toolbox.us-west-1.rl.trydaytona.com/toolbox",
    "preview_domain": "preview.us-west-1.rl.trydaytona.com"
  },
  {
    "id": "arm64-test-1",
    "name": "ARM64 (Graviton)",
    "status": "active",
    "is_default": false
  }
]

Each region also advertises where its data plane lives: toolbox_proxy_url (the base URL for toolbox calls to sandboxes in that region) and preview_domain (the front door for that region's HTTP preview endpoints). These fields are omitted when a region uses the platform-wide defaults. You rarely read them directly — a sandbox's DTO already resolves its own region's toolbox proxy and preview domain, and the SDKs follow it automatically.

Selecting a region at create

Pass region with a region slug when creating a sandbox over REST:

curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "python:3.12-slim", "region": "eu-central-1"}'

An unknown or disabled region fails the create with 400 Bad Request — placement never silently falls back somewhere else than what you asked for.

When no region is given, the default is resolved in order:

1. The project's default region, if configured.
2. Otherwise the organization's default region, if configured.
3. Otherwise the platform default region.

Note: the native SDKs do not send a region field on create yet. To place sandboxes in a specific region today, either use the REST API directly for the create call, or rely on a project/org default so SDK creates land where you want them. (The Daytona compatibility facade does accept a region via its target parameter.)

How regions behave

Region-tagged sandbox ids. A sandbox's external id encodes its region, so ids remain unambiguous across regions and tooling can tell at a glance where a sandbox lives.

Images and disk snapshots replicate on first use. Images and disk snapshots have a home region (where they were built or captured) and replicate to another region the first time something there needs them. While replication is in flight, the create returns 409 Conflict with a "replicating into region" message — simply retry shortly; once the replica is ready, creates proceed at full speed and stay local.

Full snapshots are pinned. A full (memory + disk) snapshot captures a running machine's state and can only be restored in the region where it was taken. Plan region choice up front for workflows built on full-snapshot restore.

Regions have an architecture. A region's CPU architecture — x86_64 or arm64 — is a property of its runner fleet. To run an arm64 sandbox you create it in an arm64 region; there is no separate architecture parameter. See Architecture support for the details.

Choosing a region

Two considerations usually decide it:

• Latency. Put sandboxes close to whatever talks to them most — your agents, your backend, or your users. Interactive workloads (terminals, dev servers) benefit the most.
• Data residency. If your data must stay in a jurisdiction, pick the matching region; sandbox disks and region-pinned snapshots stay in the region where the sandbox runs. Note that object stores connect to your bucket wherever it lives — bucket residency is governed by your storage provider, not by the sandbox's region.

Keep resources that work together in one region when you can: same-region creates avoid first-use replication delays, and full-snapshot workflows require it.