GitHub Actions ARM32 support on GitHub-hosted Linux and Windows runners is scheduled to end on December 8, 2026. The retirement affects native AArch32 user-space execution and follows GitHub’s move away from Node.js 20, because Node.js 24 does not support ARM32.
GitHub confirmed the deadline in its November 12 changelog announcement. The notice is brief, but the engineering implications can be significant for teams maintaining embedded software, legacy ARM applications, cross-compilation workflows and automated testing pipelines.
The important distinction is that ARM32 and ARM64 are not interchangeable execution environments. An ARM64 runner may be suitable for compiling 32-bit software, but it does not automatically guarantee that existing 32-bit binaries will execute successfully.
Developers should identify workflows that depend on native ARM32 execution, verify their build and test requirements, and complete migration testing before the deadline.
What Is Changing With GitHub Actions ARM32 Support?
GitHub says its hosted runners will end support for ARM32 job execution on Linux and Windows by December 8.
The announcement specifically includes native AArch32 user-space execution.
AArch32 is the 32-bit execution environment associated with Arm architectures. It is distinct from AArch64, the 64-bit execution environment used by modern ARM64 systems.
This distinction matters because the retirement concerns execution compatibility rather than the ability to produce ARM32 binaries.
For example, a build running on an x86-64 or ARM64 machine may still be able to cross-compile software for a 32-bit ARM target.
However, executing the resulting binary requires a compatible runtime environment, which may involve native support, emulation or dedicated hardware.
Why Node.js 24 matters
GitHub links the retirement to its end of support for Node.js 20.
Many GitHub Actions use Node.js as their execution runtime, even when the workflows themselves are written primarily in YAML.
Moving to a newer Node.js runtime changes the architecture compatibility requirements for the surrounding automation infrastructure.
Because Node.js 24 does not support ARM32, GitHub is retiring the corresponding hosted-runner execution support rather than maintaining an unsupported runtime configuration.
The announcement does not provide a comprehensive list of every workflow or third-party action that will be affected.
Therefore, teams should test their own pipelines instead of assuming that every ARM-related workflow will fail.
GitHub Actions ARM32 vs. ARM64: Understanding the Difference
The terminology can be confusing because ARM describes a processor architecture family rather than a single binary execution format.
| Architecture | Common designation | Practical meaning |
|---|---|---|
| ARM32 | AArch32, armhf or armv7 in some environments | 32-bit ARM software and user-space execution |
| ARM64 | AArch64, arm64 | 64-bit ARM execution environment |
| x86-64 | x64, amd64 | 64-bit x86 execution environment |
An ARM64 machine can sometimes execute ARM32 programs, depending on the operating system, kernel configuration, compatibility libraries and other runtime components.
But compatibility is not universal.
In particular, developers should not assume that a GitHub-hosted ARM64 runner provides supported AArch32 execution after the December retirement.
Does this mean ARM64 runners are being removed?
No. GitHub’s announcement concerns ARM32 execution support.
The current GitHub-hosted runners documentation lists ARM64 runner options for both Linux and Windows.
Examples include ubuntu-24.04-arm and windows-11-arm.
These are 64-bit ARM environments, not direct replacements for every 32-bit ARM workflow.
GitHub Docs
Which CI/CD Pipelines Could Be Affected?
The most obvious candidates are workflows that execute 32-bit ARM binaries or rely on ARM32 user-space components.
Potentially affected scenarios include embedded Linux testing, legacy ARM application validation, native dependency installation and integration tests that assume a 32-bit runtime.
A workflow may also depend indirectly on ARM32 through a container image, test utility, emulator configuration or custom build script.
Embedded Linux development
Embedded developers often build software for hardware with limited memory, specialized processors or older operating systems.
Some devices continue to use 32-bit ARM environments even when development workstations and CI servers are 64-bit.
A migration to an ARM64 runner may preserve compilation capability while requiring changes to test execution.
For example, a cross-compiler can generate ARM32 binaries without running them natively. Functional tests of those binaries require an additional execution strategy.
Legacy application testing
Some organizations maintain applications built for older ARM operating systems or libraries.
These systems may depend on specific application binary interfaces, runtime libraries or CPU features.
Moving to a newer runner can expose compatibility issues unrelated to the application source code.
That is why the migration should include executable tests, not only successful compilation.
How to Audit GitHub Actions ARM32 Dependencies
The first step is to inspect workflow definitions and supporting scripts.
GitHub Actions workflow files are typically stored in:
.github/workflows/
Search for architecture references such as arm, arm32, armv7, aarch32, armhf and any custom runner labels.
On a Unix-like development machine, one useful starting point is:
grep -RniE 'arm32|armv7|aarch32|armhf' \
.github/workflows scripts Dockerfile*
Adjust the paths to match the repository structure.
This search can identify explicit architecture references, but it will not detect every indirect dependency.
Teams should also inspect container images, build toolchains, third-party actions and executable artifacts.
Check the architecture actually used by a job
For Linux jobs, a diagnostic step can help establish the runner environment:
- name: Inspect runner architecture
shell: bash
run: |
uname -m
node --version
file /bin/sh
The uname -m command reports the machine architecture visible to the operating system.
The file command provides information about the executable format of the selected binary.
These checks are useful diagnostics, but they do not establish that every ARM32 application will run correctly.
Inspect the binary artifacts
On Linux, the file and readelf utilities can identify the architecture of compiled binaries.
For example:
file ./build/my-application
readelf -h ./build/my-application
The output can reveal whether an artifact targets a 32-bit or 64-bit execution environment.
If the artifact is ARM32, developers should determine whether their workflow merely builds it or also executes it.
That distinction guides the migration strategy.
Migration Options After GitHub Actions ARM32 Retirement
There is no single migration path that fits every project.
The appropriate approach depends on whether the application must remain compatible with ARM32 hardware and whether tests require native execution.
Option 1: Move eligible workloads to ARM64
For projects that can run entirely in a 64-bit ARM environment, migrating to a supported ARM64 runner may be the simplest approach.
A Linux workflow can specify a documented ARM64 runner label:
name: ARM64 Build
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-24.04-arm
steps:
- uses: actions/checkout@v4
- name: Check architecture
run: uname -m
- name: Build
run: echo "Replace with project build commands"
This is a minimal configuration example, not a complete application build.
Developers should verify that their tools and dependencies support ARM64 before replacing existing jobs.
Option 2: Cross-compile ARM32 applications
Cross-compilation allows software targeting one architecture to be built on another.
For example, an ARM64 or x86-64 runner may use an ARM32 cross-compiler to produce binaries for embedded hardware.
This approach can preserve ARM32 release artifacts without requiring native ARM32 execution during compilation.
However, compilation success does not prove runtime compatibility.
Projects should retain appropriate testing for the actual target environment.
Option 3: Use emulation for selected tests
Emulation can provide a way to execute ARM32 software on other architectures.
Tools such as QEMU support a range of emulated architectures and execution modes.
Emulation is useful for functional validation, but it may not reproduce hardware-specific behavior, performance characteristics or every operating-system interaction.
It can also introduce additional maintenance and execution overhead.
Teams should validate the emulator configuration and avoid treating an emulated test environment as identical to production hardware.
Option 4: Test on dedicated ARM32 hardware
For embedded systems requiring native execution, dedicated hardware may be the most representative option.
A team can use its own test infrastructure to execute software on actual target devices.
However, GitHub’s current general self-hosted runner documentation lists x64 and ARM64 as supported architectures; it does not establish ARM32 as a generally supported self-hosted runner configuration.
GitHub Docs
Therefore, teams should not assume that installing a GitHub Actions runner directly on an ARM32 device is a supported workaround.
A supported runner can instead coordinate testing on external hardware through a controlled test harness.
This separates workflow orchestration from execution on the target device.
How to Build a Safer ARM32 Migration Plan
A reliable migration starts with an inventory rather than a runner-label change.
Identify the workflows that build ARM32 software, the workflows that execute it, and the dependencies involved in each stage.
Then establish which parts can move to supported 64-bit runners and which require emulation or physical devices.
Preserve test coverage during migration
One risk is replacing an ARM32 job with an ARM64 job and accidentally removing meaningful compatibility testing.
A pipeline can become green while no longer testing the software architecture deployed in production.
To prevent this, define the expected outputs and test environments before making changes.
For example, a project might use ARM64 for compilation while retaining an ARM32 hardware test stage.
That approach preserves target validation without assuming the hosted runner itself can execute the legacy environment.
Separate build, test and release responsibilities
A useful CI/CD design separates three concerns:
-
Build: Produce the intended architecture-specific artifact.
-
Test: Validate that artifact in an appropriate execution environment.
-
Release: Package, sign and distribute the verified artifact.
Separating these stages makes it easier to move individual tasks between runners without changing the requirements of the final software.
It also improves failure diagnosis: an ARM32 runtime problem should not be confused with a compiler or packaging failure.
Why Runner Migrations Also Matter for Security
Runner architecture changes are primarily compatibility events, but they can affect security controls.
A new environment may use different container images, system libraries, credentials or permissions.
Migration testing should therefore include the security assumptions of the original workflow.
For example, ensure that untrusted pull-request code does not gain access to privileged deployment credentials when workflows are reorganized.
TechnologyHQ recently examined GitHub Actions workflow log secret scanning, which expands detection of supported exposed credentials in CI/CD output.
That capability addresses credential visibility, while the ARM32 retirement concerns execution compatibility.
Both illustrate why workflow infrastructure requires deliberate maintenance rather than one-time configuration.
Keep source-control tools patched
Runner migrations are also an opportunity to verify versions of Git and other developer utilities.
TechnologyHQ’s November 2026 Git security vulnerabilities guide covers six recently patched vulnerabilities affecting repository operations.
A migration should preserve security updates while avoiding unnecessary changes that make compatibility problems harder to diagnose.
The practical approach is to use supported runner images, verify tool versions and test the complete workflow before switching production automation.
What GitHub’s Announcement Does Not Confirm
GitHub’s November 12 notice establishes the retirement date and its connection to Node.js runtime support.
It does not provide a detailed compatibility matrix for every third-party action, container image or ARM32 workload.
Nor does it state that ARM32 software development itself is being discontinued.
The ability to compile ARM32 software, the availability of ARM64 hosted runners and the retirement of native AArch32 execution are separate technical matters.
Developers should avoid drawing broader conclusions from the announcement than the published details support.
What Developers Should Do Before December 8
With the deadline approaching, teams should prioritize an architecture audit of their GitHub Actions workflows.
Repositories with no ARM32 execution dependencies may require little or no action.
Projects that produce ARM32 artifacts but do not execute them may be able to retain their cross-compilation process.
Projects that depend on native AArch32 execution need a verified alternative before the deadline.
For critical pipelines, run the proposed replacement in parallel with the existing workflow where feasible, compare outputs and confirm that the same tests are performed.
Record the migration decision so future maintainers understand why a particular runner, emulator or hardware test environment was selected.
Frequently Asked Questions
When does GitHub Actions ARM32 support end?
GitHub says hosted Linux and Windows runners will end support for ARM32 job execution by December 8, 2026.
Is GitHub removing ARM64 runners?
No. The announcement concerns ARM32 execution. GitHub continues to document ARM64 hosted-runner options.
Can ARM64 runners execute ARM32 binaries?
Not necessarily. Execution depends on the operating system, compatibility support and runtime environment. Developers should test their specific workloads.
Can developers still build ARM32 software?
Yes, cross-compilation remains a possible approach. The announcement does not prohibit generating ARM32 binaries.
Why is GitHub ending ARM32 support?
GitHub connects the change to the retirement of Node.js 20 support and the fact that Node.js 24 does not support ARM32.
Can a self-hosted runner replace ARM32 hosted execution?
Not automatically. Teams should consult GitHub’s supported runner architecture documentation and consider a supported runner that orchestrates tests on separate ARM32 hardware.
The Bottom Line
The retirement of GitHub Actions ARM32 support on December 8, 2026, is a targeted infrastructure change with potentially significant consequences for embedded and legacy software development.
It does not mean that ARM32 binaries can no longer be built, nor does it mean that ARM64 hosted runners are disappearing.
The central challenge is preserving meaningful testing when the execution environment changes.
Teams that inventory their dependencies, separate compilation from runtime validation and test their migration paths before the deadline will be better positioned to maintain reliable CI/CD pipelines.
TechnologyHQ is a platform about business insights, tech, 4IR, digital transformation, AI, Blockchain, Cybersecurity, and social media for businesses.
We manage social media groups with more than 200,000 members with almost 100% engagement.
