Architecture Support (x86_64 & arm64)

Daytona runs sandboxes on both x86_64 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.

Choosing an architecture

Architecture is not a create parameter. There is no arch or platform field on the create request. Instead, a region's architecture is a property of its runner fleet, so you select an architecture by selecting a region.

To run an arm64 sandbox, create it in an arm64 region. List the regions and their identifiers with GET /regions (see Regions), then pass the arm64 region's slug on create:

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": "arm64-test-1"}'

Everything else — SDK usage, toolbox calls, SSH, lifecycle — is identical to an x86_64 sandbox. A sandbox created in an arm64 region simply runs on arm64.

Note: the native SDKs do not send a region on create yet, so choose an arm64 region by setting it as your project or organization default (or issue the create over REST). See the region-selection note on the Regions page.

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 region's architecture:

• Multi-arch images just work. Most official images (for example python, node, ubuntu) publish a multi-architecture manifest. Daytona resolves it to the region's architecture automatically, so python:3.12-slim boots as arm64 in an arm64 region and as x86_64 in an x86_64 region.
• Single-arch images must match. If an image is published for only one architecture, using it in a region of 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 of the region you intend to run in.

What to expect on arm64

• First creates in a fresh arm64 region are slower. Each architecture keeps its own image and template cache; the caches are never shared across architectures. A newly provisioned arm64 region 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