Architecture Support (x86_64 & arm64)

Daytona runs sandboxes on both x86_64 (amd64) and arm64 (aarch64) hosts. The two architectures deliver the same product — the same isolation, the same toolbox API, the same lifecycle operations — on different silicon. arm64 is useful when you want to match production hardware (for example AWS Graviton or NVIDIA Grace/Vera-class CPUs), build and test native arm64 images, or run arm-native workloads without emulation.

The arm64 platform is validated on AWS Graviton bare-metal instances and covers the full path: architecture-aware image pulls, an arm64 guest kernel, the arm64 toolbox layer, and the same fast sandbox creation you get on x86_64.

Two placement constraints: cpu_arch and cpu_type

Both are optional create parameters. Leave them out and the sandbox lands on the platform's default fleet (amd64) — exactly the behavior before these fields existed.

• cpu_arch — the CPU architecture, "amd64" (default) or "arm64". This is the hard compatibility dimension: it decides which guest kernel and image architecture your sandbox runs.
• cpu_type — a specific CPU hardware tier, identified by a short slug from the platform's CPU-type registry (for example zen5, zen4, graviton). Choosing a type is more specific than an architecture, and each type implies its architecture, so you never set both — pick a cpu_type when you care about the exact silicon, or just a cpu_arch when any CPU of that architecture will do. Each type has an ordered tier within its architecture, and pinning one sets a floor: placement prefers that exact tier and only falls back upward to a higher tier (of the same architecture) when no exact-tier host is free — never to a lower one.

Unlike regions, architecture and CPU type are not tied to where a sandbox runs: a single region can contain a mix of amd64 and arm64 runners, and these parameters steer placement within it.

Discovering CPU types

GET /cpu-types returns the registry of CPU types the platform knows about. Each entry has an id (the slug you pass as cpu_type), a human-readable name, the cpu_arch it belongs to, and a tier — an ordered rank within the architecture (1 = lowest) that determines the upward fallback order:

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

[
  { "id": "zen3",     "name": "AMD Zen 3", "cpu_arch": "amd64", "tier": 1 },
  { "id": "zen4",     "name": "AMD Zen 4", "cpu_arch": "amd64", "tier": 2 },
  { "id": "zen5",     "name": "AMD Zen 5", "cpu_arch": "amd64", "tier": 3 },
  { "id": "graviton", "name": "Graviton",  "cpu_arch": "arm64", "tier": 1 }
]

The exact list depends on the hardware currently available on the platform, so query it rather than hard-coding slugs. The companion GET /network-classes and GET /disk-classes endpoints return NIC and NVMe classes in the same shape (id, name, tier).

Choosing an architecture

To run an arm64 sandbox, pass cpu_arch:

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", "cpu_arch": "arm64"}'

An unknown cpu_arch (anything other than amd64 or arm64) fails the create with 400 Bad Request.

Choosing a specific CPU type

When you need particular silicon — say, to benchmark on a specific microarchitecture — pass cpu_type instead. The architecture is inferred from the type:

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", "cpu_type": "graviton"}'

A cpu_type that is not in the registry — or one whose architecture contradicts an explicitly-set cpu_arch — fails the create with 400 Bad Request. So {"cpu_arch": "amd64", "cpu_type": "graviton"} is rejected, because graviton is arm64.

Everything else — SDK usage, toolbox calls, SSH, lifecycle — is identical regardless of architecture or CPU type. A sandbox pinned to arm64 or to graviton simply runs on that hardware.

Setting it from the SDKs and dashboard

• SDKs. Pass cpuArch / cpuType (TypeScript) or cpu_arch / cpu_type (Python) in the create params — see Parameter Reference.
• Dashboard. The create-sandbox dialog exposes a CPU type selector under the Advanced section. Leave it on Any for the default fleet, or pick a type to pin the sandbox (the architecture follows from your choice).

Images must match the architecture

A guest runs the host's architecture — there are no cross-architecture guests. That means the image you boot must be available for the architecture you request:

• Multi-arch images just work. Most official images (for example python, node, ubuntu) publish a multi-architecture manifest. Daytona resolves it to the requested architecture automatically, so python:3.12-slim boots as arm64 when you ask for arm64 and as x86_64 otherwise.
• Single-arch images must match. If an image is published for only one architecture, requesting a different architecture fails to resolve. Build or pull an image that includes the target architecture.
• Your own images: when you build from a Dockerfile or push to a registry, make sure the build targets the architecture you intend to run on.

What to expect on arm64

• First creates on a fresh arm64 fleet are slower. Each architecture keeps its own image and template cache; the caches are never shared across architectures. A newly provisioned arm64 fleet therefore starts "cold" and warms up as images are pulled and templates are built on first use — subsequent creates are fast.
• Snapshots are architecture-specific. A VM snapshot captured on one architecture cannot be restored on the other. Full (memory + disk) snapshots are additionally region-pinned.
• No cross-architecture migration or fork. These operations stay within an architecture, as they depend on machine-level state.

Summary