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.

Global regions

Beyond individual regions, the platform groups regions into global regions — broad placement targets like world, us, eu, and asia. Selecting a global region lets a runner in any of its member regions run the job, which is useful when you care about a broad area (e.g. "anywhere in the US") rather than a single data center.

GET /global-regions returns the catalog with the number of active member regions in each:

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

[
  { "id": "asia",  "name": "Asia",          "member_count": 0 },
  { "id": "eu",    "name": "Europe",        "member_count": 1 },
  { "id": "us",    "name": "United States", "member_count": 2 },
  { "id": "world", "name": "World",         "member_count": 3 }
]

Membership is shown on each region via the global_region_id field of GET /regions. Semantics:

• Selecting a second-level global region (e.g. us) restricts placement to that group's member regions.
• Selecting world allows any region that belongs to some global region.
• A region that is not part of any global region is excluded from every global selection (including world) — it is reachable only by its exact slug.

You use a global region exactly like a region slug: pass it as region at create time. The platform expands it to one concrete member region — preferring members that currently have an available runner — and places the sandbox there. The sandbox's own (concrete) region is reported on its DTO, so you can always see where it actually landed. A global region with no active members fails the create with 400.

If you need a sandbox in one specific data center — for example to co-locate with an earlier sandbox, or for strict data residency — pass that region's exact slug rather than a global region.

Selecting a region at create

Pass region with a region slug — or a global region id — 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 can mix architectures. A region's runner fleet may include both x86_64 and arm64 hosts. Architecture is not a region property — you select it per create with the cpu_arch parameter (or pin a specific CPU with cpu_type), independent of region. 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.