engineering
Migrating CI to arm64: what actually breaks
We moved 200 repositories to arm64 runners. Here is the complete list of what failed and why.
Priya Raghavan · Infrastructure · 2026-05-06 · 8 min read
arm64 is cheaper per minute and often faster. The migration is usually straightforward. When it is not, the cause is almost always the same category of thing.
What broke, in order of frequency
- Transitive native Node modules with no aarch64 prebuild, falling back to a slow source compile
- Python packages with no manylinux_aarch64 wheel, compiling from source
- Docker base images pinned to an amd64-only tag
- Service containers with no arm64 variant, silently falling back to emulation
- Cache keys without runner.arch, restoring x64 artefacts onto arm64 and producing linker errors
What did not break
Almost all pure application code. Go, Rust, Java, Ruby, PHP and modern Node all cross cleanly. The failures were concentrated in native dependency edges, not in the languages themselves.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
CI when your teammates are agentsAI coding agents push far more often than humans. Here is how that changes pipeline design and cost control.Why we publish instructions for leavingEvery migration page on this site includes the diff to migrate back off us. Here is the reasoning.What we learned running a million CI jobsQueue time, cache behaviour, right-sizing and the failure modes that only appear at scale.Stop retrying flaky testsAutomatic retries convert a real bug into an intermittent one, and train your team to distrust every failure.