Are ARM64 GitHub Actions Runners Cheaper Than x64?

Yes. ARM64 starts at $0.003 per minute against $0.004 for the x64 runner at the same 2 vCPU and 8 GB shape, and that 25 percent gap holds at every size in the Linux catalog (cloud runners documentation, checked on 2026-08-13).

The rate is the easy half of the answer. Whether the lower rate reaches your invoice depends on how long the job runs after the switch, which is what the rest of this page works through.

Answer

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. Inside the Linux catalog, the two architectures ship the same five sizes with the same vCPU and RAM, so the comparison is exact at every row.

Every rate above comes from the cloud runners documentation, checked on 2026-08-13. The same five sizes exist on Ubuntu 26.04 under labels such as warp-ubuntu-2604-arm64-4x and warp-ubuntu-2604-x64-4x at identical rates, so pinning a release does not change the arithmetic.

The same question against GitHub-hosted runners

Line up each WarpBuild rate against GitHub's published rate for the same shape and the same architecture, and WarpBuild is lower on both lines at every size. Rates below come from the GitHub Actions billing reference and the GitHub pricing page, checked on 2026-08-13.

The 2 vCPU row uses GitHub's private-repository rate, which is what paying teams run against. GitHub gives public repositories a 4 vCPU, 16 GB shape at no charge, and no runner rate competes with free.

Read across one row for the full picture at 4 vCPU: warp-ubuntu-latest-arm64-4x at $0.006 is 25 percent under WarpBuild's own warp-ubuntu-latest-x64-4x at $0.008, which itself is 33 percent under the GitHub 4-core Linux larger runner at $0.012 (GitHub pricing, checked on 2026-08-13). The architecture switch and the platform switch stack, and the worked model below prices both.

Worked model on real job minutes

A repository runs 20,000 minutes a month of unit and integration jobs on a 4 vCPU shape. Same jobs, same duration, four different labels:

• warp-ubuntu-latest-arm64-4x at $0.006: 20,000 x $0.006 = $120.00 per month
• warp-ubuntu-latest-x64-4x at $0.008: 20,000 x $0.008 = $160.00 per month
• GitHub 4-core Linux ARM64 larger runner at $0.008: 20,000 x $0.008 = $160.00 per month
• GitHub 4-core Linux larger runner at $0.012: 20,000 x $0.012 = $240.00 per month

The architecture change alone is worth $40.00 a month, or $480.00 over twelve months, at this volume.

Run the same model at 8 vCPU and the spread grows in absolute dollars while the percentage holds: 20,000 minutes on warp-ubuntu-latest-arm64-8x at $0.012 is $240.00 against $320.00 on warp-ubuntu-latest-x64-8x, an $80.00 monthly difference for the same 8 vCPU and 32 GB shape.

Detail

The rate is only half the bill

A per-minute rate multiplied by minutes is the invoice, so a 25 percent lower rate survives only while the minute count holds. The break-even is arithmetic you can do before you move anything.

At the 4 vCPU pair, $0.008 divided by $0.006 is 1.33. The ARM64 job can take 4 minutes for every 3 minutes the x64 job took and produce the same monthly bill. Beyond that ratio the extra minutes cost more than the rate saves. The ratio is identical at every size, because the 25 percent gap is constant across the catalog.

Three things move that ratio in practice:

1. Toolchain maturity for your language. Compilers and runtimes with mature aarch64 backends land near parity on wall clock. Toolchains that fall back to a generic code path, or that pull a dependency with no prebuilt aarch64 wheel or binary and compile it from source at install time, add minutes to every run.
2. Dependency install shape. A step that fetches a prebuilt x86-64 artifact and finds no aarch64 equivalent turns into a source build. That single change can double the install step.
3. Cache behavior. Setup actions scope cache keys per architecture, so the first ARM64 runs on a repository start cold. Compare steady-state runs once the cache has filled, and discount the first pull request after the switch.

Measure your own numbers before you commit. Job duration by step is visible in the runner observability views, and the Graviton build guide covers the ordering teams use when they move a pipeline whose production target is already aarch64.

Native ARM64 and emulated ARM64 bill differently

The $0.003 rate applies to a native aarch64 machine. A QEMU-emulated build is a different billing event: it runs on an x64 runner through docker/setup-qemu-action with binfmt handlers registered, so the job bills at the x64 rate and pays instruction translation on top.

That combination moves the cost in both directions at once. The runner rate is the higher of the two, and the guest work takes longer than it would on native hardware, so the emulated route pays twice for producing the same aarch64 artifact.

Emulation earns its place in one situation: producing an linux/arm64 image layer inside a build that is otherwise x64, where the alternative is standing up a second job. For a test suite, a native ARM64 label runs the same binary you ship to aarch64 hosts, which is the point of testing on the architecture at all. The cross compiling comparison works through the third option, where the compile happens on x64 with a cross toolchain and only the test job moves to ARM64.

Toolchain support decides whether the job runs at all

Rate comparisons assume the workflow completes. Two image facts decide that.

The Ubuntu 24.04 ARM64 runners are compatible with GitHub's Ubuntu 24.04 ARM64 runners, and the package list is published at actions/partner-runner-images. Ubuntu 26.04 ARM64 tracks actions/runner-images. Read the list against the versions your workflow pins before you switch, because the ARM64 and x86-64 images do not ship an identical set.

The arm64 images for ubuntu-22.04 were deprecated on March 31, 2025 (preinstalled software documentation). Those images were thinner than their x86-64 siblings: they were based on the upstream ubuntu:22.04 image, the default user was root rather than runner, and tooling had to be installed with apt inside the workflow. Ubuntu 24.04 and Ubuntu 26.04 ARM64 closed both gaps, so any ARM64 pricing decision starts at 24.04.

The Ubuntu 24.04 ARM64 work directory difference

The arm64 images for ubuntu-24.04 set the work dir to /runner/_work, which differs from GitHub's /home/runner/work/ for the same instance (cloud runners documentation). This is the single most common reason a job that costs less on paper fails on the first ARM64 run.

Audit four places for a hardcoded /home/runner/work string before the switch:

• Docker -v bind mounts in run steps
• coverage and test-report upload paths
• actions/cache path globs
• any script that reconstructs a path instead of reading the environment

Use ${{ github.workspace }} in YAML expressions and $GITHUB_WORKSPACE in shell steps and the difference stops mattering.

Moving one job at a time

The cheapest way to test the price claim is to move one job, keep the rest where it is, and compare a week of runs. The runs-on label is the only line that changes.

name: ci

on:
  pull_request:

jobs:
  unit:
    runs-on: warp-ubuntu-latest-arm64-4x
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      - run: npm test

      - name: Confirm the architecture and the workspace path
        run: |
          uname -m
          echo "workspace=${GITHUB_WORKSPACE}"

  package:
    runs-on: warp-ubuntu-latest-arm64-8x
    needs: unit
    steps:
      - uses: actions/checkout@v4

      - run: ./scripts/build-release.sh

      - uses: actions/upload-artifact@v4
        with:
          name: release-linux-arm64
          path: dist/

  instrumentation:
    runs-on: warp-ubuntu-latest-x64-4x;nested-virtualization.enabled=true
    steps:
      - uses: actions/checkout@v4

      - run: ./scripts/run-emulator-tests.sh

uname -m prints aarch64 on the first two jobs. The third job keeps an x64 label on purpose: nested virtualization and /dev/kvm access are unavailable on ARM64 runners, and the nested-virtualization.enabled=true dynamic label is silently ignored on runner classes that do not support it (cloud runners documentation).

Priced at 500 pull requests a month with the shape above, and assuming 4 minutes for unit and 3 minutes for package: 500 x 4 x $0.006 = $12.00 plus 500 x 3 x $0.012 = $18.00, for $30.00 a month. The same two jobs on x64 labels are $16.00 plus $24.00, for $40.00.

Where the ARM64 rate does not apply

ARM64 coverage in the catalog is Linux and macOS. The Windows catalog is x86-64 only, from warp-windows-latest-x64-4x at $0.016 per minute through warp-windows-latest-x64-32x at $0.128, so a Windows job has no architecture choice to price. The macOS runners are already ARM64, which means a macOS job has no decision to make either.

Inside Linux, the ARM64 line covers everything a normal workflow does, including checkout, the language setup actions, caching, artifacts, and service containers. The one hard exclusion is nested virtualization.

Related Questions

Are ARM64 GitHub Actions runners cheaper than x64 runners?

On the per-minute rate, yes. warp-ubuntu-latest-arm64-2x is $0.003 per minute against $0.004 for warp-ubuntu-latest-x64-2x at the same 2 vCPU and 8 GB shape, and the 25 percent gap holds at every size from 2x through 32x. The invoice follows only when the ARM64 job keeps roughly the same duration. The full label list with sizes and rates is in the Linux ARM64 runner catalog.

How much longer can an ARM64 job run before it costs more than the x64 job?

One third longer. At $0.006 against $0.008 for the 4 vCPU pair, the ARM64 leg can take 4 minutes for every 3 x64 minutes and land on the same bill. Past that ratio the lower rate stops covering the extra minutes, so measure the duration on your own build before you move the job. The ARM64 migration guide covers the step types that change duration after a switch, and the Graviton build guide covers the case where production already runs on aarch64.

Do QEMU-emulated ARM64 builds get the ARM64 rate?

No. An emulated build runs on an x64 runner and bills at the x64 rate while translating every guest instruction, so it pays the higher rate and the translation overhead together. The ARM64 rate applies to native aarch64 labels such as warp-ubuntu-latest-arm64-8x. The cross compiling comparison sets out when to cross compile on x64 and when to build natively.

What changes besides the rate when a job moves from x64 to ARM64?

Three things. Toolchain availability differs because the ARM64 image ships its own package list, the Ubuntu 24.04 ARM64 image sets the work dir to /runner/_work instead of GitHub's /home/runner/work/, and nested virtualization stays on x64 because /dev/kvm is unavailable on ARM64 runners. The capability side of the question is covered in can GitHub Actions run ARM64.

Price the switch against your own job minutes on the pricing page, pick a label from the Linux ARM64 runner catalog, and confirm the image ships your toolchain in the preinstalled software documentation.