Running 32-bit ARM programs inside GitHub Actions? Check your workflows before December 8, 2026. GitHub is removing ARM32 execution support from its hosted Windows and Linux runners.
What is changing?
In a November 12 announcement, GitHub says hosted runners will stop supporting ARM32 job execution by December 8, 2026. That includes native AArch32 user-space execution.
The change follows the retirement of Node.js 20 support in Actions: Node.js 24 does not support ARM32. This is about executing 32-bit ARM programs on GitHub-hosted Windows and Linux runners, not a blanket announcement that every ARM-based build or every ARM64 workflow will stop working.
Who should check?
- Embedded-device developers: CI jobs that execute 32-bit ARM test binaries, not just compile them.
- Cross-platform maintainers: workflows that install AArch32 libraries or run 32-bit ARM utilities on hosted machines.
- Teams using emulation: inspect the exact execution path rather than assuming an emulator or container will remain supported.
A quick repository audit
Search workflow definitions for architecture references. From a local checkout, this example uses Git’s built-in search; it is a suggested audit, not a GitHub-provided migration command:
git grep -n -i -E 'arm32|aarch32|armv7|armhf' -- .github/workflowsAlso inspect scripts invoked by workflows and their downloaded dependencies. A search returning no matches does not prove the pipeline is unaffected: architecture-specific behavior can live in Dockerfiles, package installers or external actions.
What to do next
Identify jobs that execute ARM32 code. Where possible, move testing to a supported 64-bit target and validate the results. If the project must execute AArch32 binaries, evaluate a runner environment you control and verify its operating system, toolchain and maintenance requirements before switching.
Caveat: GitHub’s announcement does not promise a drop-in migration or specify that all forms of ARM32 emulation will work elsewhere. Test your actual CI job before the deadline; don’t confuse a successful cross-compile with a successful runtime test.