GitHub Actions has completed its removal of Node 20 from Actions runners. As of September 23, 2026, JavaScript actions run with Node 24 instead, and the temporary opt-out that allowed continued use of Node 20 is no longer available.
The change affects both action maintainers and teams that consume actions in workflows. Maintainers need to publish releases configured for Node 24, while workflow owners need to update their action references to compatible releases. Teams using self-hosted runners also need to review operating-system and architecture limitations that apply to the Node 24 runtime.
What changed in GitHub Actions
GitHub’s September 23 announcement confirms that Node 20 is no longer available on GitHub Actions runners. JavaScript actions now use Node 24, and the change applies to both GitHub.com and GitHub with Data Residency.
The transition followed a staged rollout. GitHub previously enabled Node 24 testing, made Node 24 the default beginning June 16, 2026, and retained a temporary Node 20 opt-out until the final removal date. That opt-out used ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION; it cannot be used after Node 20’s removal.
GitHub’s announcement does not provide a guaranteed error message for every action that remains configured for Node 20. Teams should therefore treat failures as a signal to inspect the action versions used by the workflow rather than relying on a particular error string.
Action maintainers must publish a Node 24 release
For a JavaScript action, the action metadata must identify the runtime through runs.using. The supported migration path is to change that value from node20 to node24, retain the required runs.main entry that identifies the action’s entry file, and publish a new release.
runs:
using: 'node24'
main: 'dist/index.js'The metadata reference documents both node20 and node24 runtime values, as well as the required metadata fields. Updating a repository’s metadata alone is not enough for existing workflow users: the compatible change must be included in a published release, and workflows must consume that release.
Action maintainers should also test their Node 24 release against the environments and dependencies they support. The supplied GitHub documentation does not establish that every third-party action has already published a compatible version, so workflow owners should verify each action rather than assuming that all dependencies have migrated.
What workflow owners should review
Start by inventorying the actions referenced by each workflow and checking whether the action publisher offers a release that supports Node 24. Update workflow references to those releases. GitHub’s metadata guidance describes references by Git ref, SHA, or Docker tag and identifies a released commit SHA as the safest choice for stability and security.
The immediate concern is not every step that happens to run JavaScript. The documented change concerns JavaScript actions whose action metadata selects the GitHub Actions Node runtime. An action still tied to Node 20 may require an updated release from its maintainer, and the supplied sources do not provide a guaranteed repository-wide command that finds every direct and transitive dependency using that runtime.
After updating action references, run the workflows that exercise affected paths. Pay particular attention to build, release, deployment, and scheduled workflows that may not run during ordinary pull requests. If a failure appears, check the action’s release notes and metadata where available, then confirm that the workflow is actually using the intended version.
Self-hosted runners have additional limits
The Node 24 transition matters for self-hosted runner fleets as well as GitHub-hosted environments. GitHub’s announcement identifies macOS 13.4 and earlier as incompatible with Node 24 and says that the runtime does not officially support ARM32. Node.js migration guidance further states that pre-built binaries require macOS 13.5 or later and that pre-built binaries are no longer provided for 32-bit Linux on armv7.
These runtime constraints should not be confused with the general self-hosted runner requirements. The self-hosted runner documentation lists macOS 11.0 or later as a general runner operating-system requirement and ARM32 Linux as generally supported runner architecture. That broader support does not override the narrower Node 24 limitations for JavaScript actions.
Runner operators should review the operating systems and architectures in their fleet, particularly older macOS installations and ARM32 systems. They must also continue meeting GitHub’s requirements for the runner application, hardware, communication, and network access. The runner application updates automatically when a job is assigned or within a week of a release if it has not received a job, but an automatic runner update does not make an unsupported Node 24 platform compatible.
How to collect diagnostic information
If a workflow fails after an action update, GitHub provides two relevant diagnostic switches. Set ACTIONS_RUNNER_DEBUG=true to enable runner diagnostic logging and ACTIONS_STEP_DEBUG=true to enable step debug logging. Diagnostic logs can be downloaded from the workflow log archive.
These settings can provide more information about runner and step execution, but GitHub’s supplied documentation does not describe a Node 20-specific failure message or a complete Node 20 migration troubleshooting procedure. Treat the logs as evidence for investigating the failing action, runner, or step rather than as a substitute for checking action compatibility.
What you should do now
- Action maintainers: change
runs.usingtonode24, verify the requiredruns.mainfield, test the action, and publish a new release. - Workflow maintainers: update every affected action reference to a released version that supports Node 24. Verify the version actually used by each workflow.
- Platform administrators: inspect self-hosted runner operating systems and architectures, with special attention to macOS 13.4 or earlier and ARM32.
- Teams diagnosing failures: enable
ACTIONS_RUNNER_DEBUG=trueand, when needed,ACTIONS_STEP_DEBUG=true, then download the diagnostic logs from the workflow archive. - Security-conscious maintainers: choose action references according to the documented stability and security trade-offs, with a released commit SHA identified as the safest reference.
The former Node 20 opt-out is no longer a fallback. The supported path is to move action metadata and published releases to Node 24, consume compatible versions in workflows, and ensure that self-hosted infrastructure can run the new runtime within its documented platform limits.
Retention for checks, workflow runs, and statuses is a separate Actions change, covered in GitHub Actions retention.
