Runners & infrastructure

ARM-based CI runners go mainstream, what it means for build costs

ARM-based CI runners go mainstream, what it means for build costs

ARM64 hosted runners have moved from limited preview to general availability on the major CI providers. The headline is price: ARM instances are typically billed at a lower per-minute rate than their x86 equivalents, and for CPU-bound builds the wall-clock time is often comparable or better.

Should you switch your pipelines to ARM?

The win is real but conditional. It only materialises if your build, test and runtime images already publish linux/arm64 variants. If any step shells out to an x86-only binary, you pay for emulation, and QEMU-based emulation can be slower than just staying on x86.

A safe migration order:

  1. Move lint/test jobs first, they rarely depend on native binaries.
  2. Build multi-arch images with docker buildx and a matrix.
  3. Only flip the production runtime once the arm64 image has soaked.

How popular tools handle multi-arch builds

Most CI platforms now expose ARM runners through a simple label or pool selector. GitHub Actions and GitLab CI both let you target arm64 with a one-line runs-on / tag change, which makes them the path of least resistance if you already live there. Jenkins gives you the most control, you bring your own ARM agents, at the cost of managing that capacity yourself.

For teams that want the matrix to just work without hand-rolling agent pools, Buddy is one option worth a look: its actions run in isolated containers, so requesting an arm64 image for a step is a single field rather than a fleet to provision. That convenience is the trade-off, you get less low-level control than a self-managed Jenkins fleet, which remains the better fit when you have bespoke hardware requirements.

# Buddy — pin a single action to an arm64 image
- action: "Build (arm64)"
  type: "BUILD"
  docker_image_name: "arm64v8/node"
  docker_image_tag: "22"
  commands:
    - npm ci
    - npm run build

FAQ

Is ARM always cheaper? No, only when you avoid emulation. An emulated x86 step on an ARM runner can erase the per-minute savings.

Do I need to rewrite my pipeline? Usually not. Changing the runner label and ensuring multi-arch images is enough for most JavaScript, Go and Python projects.

Source: Vendor release notes (aggregated) (github.blog)

Related
Runners & infrastructure

Windows 11 arm64 with VS2026 goes GA on GitHub-hosted runners

GitHub Actions promoted its Windows 11 arm64 image with Visual Studio 2026 to general availability on both standard and larger GitHub-hosted runners. For teams shipping native ARM Windows binaries out of CI, the self-hosted detour stops being the only option.

August 24, 2026
Runners & infrastructure

Azure Pipelines opens an arm64 macOS preview with Xcode 27 in the pay-as-you-go pool

Microsoft added Apple Silicon macOS agents carrying Xcode 27 to Azure DevOps as a public preview, delivered through the pay-as-you-go GitHub-hosted Agents pool. For iOS and macOS pipelines that have been running Xcode on Rosetta-under-Intel agents, the native arm64 path is finally in reach on a Microsoft-hosted fleet.

August 19, 2026
CI observability

CodeQL 2.27.0 ships a native Linux ARM64 build

GitHub's static analysis engine now ships a native linux-arm64 CLI and bundle in 2.27.0, alongside a new Rust security query and expanded Java, Kotlin and C# framework coverage. Teams that already moved their runners to ARM stop paying an emulation tax on code scans.

September 10, 2026

Turn this into your pipeline. Build it on Buddy.

Start free