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

Xcode 27 lands on GitHub-hosted runners, and the naming rule quietly changed

GitHub Actions added an Xcode 27 image in public preview on its arm64 macOS runners. The bigger shift is buried in the changelog: images are now keyed to the Xcode major version instead of the OS, one Xcode per image.

July 19, 2026
Runners & infrastructure

Dynamic Resource Allocation hits GA in Kubernetes 1.35, and GPU CI jobs finally get a real API

DRA reached general availability in Kubernetes v1.35, and the NVIDIA DRA driver has dropped its Beta label. For teams running GPU workloads through Kubernetes-backed pipelines, it replaces a decade of nodeSelector gymnastics with a first-class request primitive.

July 2, 2026
Runners & infrastructure

GitHub-hosted larger runners pick up RHEL 9 and RHEL 10 in public preview

GitHub's larger hosted runners now offer Red Hat Enterprise Linux 9 and 10 images in public preview, a partnership with Red Hat aimed at shops that have been self-hosting Actions just to keep production-like CI on Red Hat.

June 29, 2026

Turn this into your pipeline. Build it on Buddy.

Start free