Regions

View as Markdown

Every Daytona sandbox runs in a region: a geographic or logical grouping of compute infrastructure. When creating a sandbox, you can target a specific region, and Daytona schedules the workload on available capacity within that region.

Daytona organizes regions in a four-level placement hierarchy:

Level	Description
Global	The root, with ID: `earth`.
Geo	Groups of macro regions that do not impose a geographic constraint.
Macro	One macro region per workload cell; every macro region belongs to one geo group.
Edge	The regions where runners place sandboxes; belongs to one macro region.

Every listed region is a valid region selector. A broad selector (global, geo, or macro) lets Daytona choose an edge region beneath it. A broad region whose edge regions all opt out of automatic placement stays listed but cannot be named in a create request. A listed region describes topology, not capacity: a create request can still fail for lack of capacity or matching hardware.

Shared regions

Regions managed by Daytona and available to all organizations:

Region	Target	Level
Earth	`earth`	Global
United States	`us`	Geo
Europe	`eu`	Geo

from daytona import Daytona

daytona = Daytona()

# Create a sandbox in the US region
sandbox = daytona.v2.create(region="us")

import { Daytona } from '@daytona/sdk'

const daytona = new Daytona()

// Create a sandbox in the US region
const sandbox = await daytona.v2.create({ region: 'us' })

# Create a sandbox in the US region
daytona sandbox create --region us

# Create a sandbox in the US region
curl 'https://api.daytona.com/sandboxes' \
  --request POST \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --data '{
  "region": "us"
}'

Dedicated regions

Dedicated regions are managed by Daytona and provisioned exclusively for an organization. The infrastructure is not shared with other organizations.

Custom regions

Custom regions run on compute that your organization provides. Daytona provisions the region and you enroll your own runner nodes through bring your own compute (BYOC) to control data locality, compliance, and infrastructure configuration, and scale capacity independently.

Operations

List regions

List regions. The list contains the regions available to you at every level, from the global root down to edge regions, as one flat list. Each region names its parent, and parents come before their children, so a client can rebuild the hierarchy from the list. Edge regions that cannot be used are left out, and so are broader regions with no listed edge region beneath them.

# Regions available to the current project
daytona region list

# Regions available to the current project
curl 'https://api.daytona.com/regions' \
  --header 'Authorization: Bearer YOUR_API_KEY'

The response contains regions, one entry per region:

Field	Description
`id`	Region ID. Valid as a `region` selector.
`name`	Display name.
`level`	`global`, `geo`, `macro`, or `edge`.
`parent_region_id`	ID of the parent region. `null` for the global root, `earth`.
`available`	Whether a create request can name this region. Always `true` for an edge region. `false` for a broader region whose edge regions all opt out of automatic placement.
`api_base_url`	Edge regions only. The API base URL of the edge region, when it publishes its own.