Multi-arch Docker builds in 2026 — shipping ARM and x86 from the same pipeline

A few years ago, "ARM in production" was a hobby project. In 2026, AWS Graviton instances are routinely 20-40% cheaper for the same workload, GCP Axion is mainstream, Azure Ampere is GA, and half the development team is on Apple Silicon. If your container images don't run natively on ARM, you're leaving meaningful money and developer experience on the table.

The good news: multi-arch Docker builds in 2026 are easier than single-arch builds were in 2019. The trick is knowing where the time and cost actually go.

Native parallel builds beat QEMU emulation

build-amd64:
  runs-on: ubuntu-latest
  steps:
  - run: docker buildx build --platform linux/amd64 \
      -t ghcr.io/example/app:${SHA}-amd64 --push .
 
build-arm64:
  runs-on: ubuntu-24.04-arm
  steps:
  - run: docker buildx build --platform linux/arm64 \
      -t ghcr.io/example/app:${SHA}-arm64 --push .
 
manifest:
  needs: [build-amd64, build-arm64]
  steps:
  - run: docker buildx imagetools create \
      -t ghcr.io/example/app:${SHA} \
      ghcr.io/example/app:${SHA}-amd64 \
      ghcr.io/example/app:${SHA}-arm64

Native parallel builds finish in roughly the same time as a single-arch build. QEMU-emulated arm64 builds for compute-heavy stacks (Rust, Go release builds) take 4-8x longer than native.

The full write-up covers:

• OCI manifest lists — what a multi-arch image actually is
• The TARGETARCH and TARGETPLATFORM Dockerfile variables
• Common Python/npm transitive-dep traps when crossing architectures
• Registry-based build cache, kept separate per arch
• Smoke-testing both variants as a CI step (not optional)
• Real GitHub Actions cost numbers — emulated vs native

We run this pipeline for every managed Docker customer on Graviton / Ampere.