GitHub Actions Drops Node 20; Older Runners Lose Support

On September 23, 2026, GitHub’s final changelog notice confirmed that Node 20 had been removed from GitHub Actions runners: JavaScript actions now use Node 24, the temporary opt-out is gone, and self-hosted runners using macOS 13.4 or earlier or ARM32 have lost support. The immediate audit has three parts: the code and metadata of JavaScript actions, the action versions workflows call, and the hosts assigned to those workflows.

A September release index separately records the completed removal and the platform limits. The change concerns the runtime that executes JavaScript actions. A project’s Node version, selected for its own build or test commands, is a separate setting; changing it alone does not update an action or make an unsupported runner host compatible.

The Node 20 fallback has ended

GitHub’s updated deprecation schedule set June 16, 2026, for the switch to Node 24 by default and allowed the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION variable to restore Node 20 temporarily, only until September 23. That fallback no longer works. Leaving the variable in a workflow or runner configuration can obscure the migration work, but it cannot bring back the removed runtime.

An action whose metadata still declares runs.using: node20 needs a maintained release, although the declaration alone does not prove that its current job fails. Runners now execute JavaScript actions with Node 24, including older action versions that have not been republished with new metadata. A successful run shows that the paths exercised in that run worked on that host; it does not establish compatibility for every input, dependency, or self-hosted platform.

Action maintainers: update the package and its published ref

Maintainers should inspect each JavaScript action’s action.yml or action.yaml and change runs.using to node24. From a repository root, rg -n 'node(12|16|20)' -g 'action.yml' -g 'action.yaml' . provides a quick discovery pass for older runtime declarations. Review matches rather than treating the search as a YAML parser: comments and examples can also contain those strings, while action metadata may live outside the usual workflow directory.

The release must include the code that the action actually runs. If a repository commits a bundled JavaScript entry point, rebuild and commit that bundle after reviewing dependencies for Node 24 compatibility. Exercise the action’s inputs, outputs, failure paths, and any pre- or post-run code on a supported runner; native modules and external programs warrant particular attention because a metadata edit cannot validate them. Publish a new release and inspect its tag or commit, since changing the default branch does not alter an existing published ref.

Workflow owners: inspect the actions actually referenced

A workflow audit starts with its direct action calls, local actions, reusable workflows, and runner selection. The command rg -n 'uses:|runs-on:|ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION' .github highlights likely references and obsolete opt-outs in a repository. It is an inventory aid rather than a complete dependency graph: a called workflow can introduce actions from another repository, and expressions or matrices can change which runner serves a job.

For each third-party uses: reference, inspect the action metadata at the exact tag or commit the workflow names. A maintainer may already have released a Node 24-compatible version while an older pinned SHA still points to earlier code. Review the newer release and its changes before updating the reference. A warning about an older declared runtime calls for investigation; it does not, on its own, show that the step has stopped executing.

Keep project commands separate from action execution in the inventory. The node-version input to actions/setup-node selects Node for commands such as installing dependencies and running tests. It does not rewrite runs.using inside another JavaScript action. A workflow can therefore have a suitable Node version for its application while still calling an action whose package and published ref need review.

Self-hosted operators: identify the host behind each label

Runner labels and groups say where jobs are routed, but a custom label need not reveal the operating system release or processor architecture beneath it. Map affected jobs to their actual hosts, check macOS with sw_vers -productVersion and architecture with uname -m, and record the runner software installed on each machine. This matters especially when a pool presents several machines under the same label: testing on one eligible host does not establish that every host in the pool is eligible.

Self-hosted runners on macOS 13.4 or earlier and ARM32 are outside the support stated for this change. Jobs assigned to those machines need a supported operating system or architecture, along with any build tools and access the workload requires. Updating an action release can address action code and metadata; it cannot change the compatibility of the host that runs it.

Validate without a Node 20 rollback

Use a controlled run to test candidate action releases on a supported runner, then exercise the workflows that call local actions, third-party actions, and self-hosted labels. Record the action refs and host used by each run so a passing result has a clear scope. If a job cannot reach an eligible runner, examine routing and host support; if a JavaScript action starts and fails, inspect its bundle, dependencies, and inputs; if later application commands fail, check their separately selected Node version.

After those paths pass, remove the obsolete opt-out and promote the tested action refs through the normal review process. The confirmed state is a completed Node 20 removal and Node 24 execution for JavaScript actions, with no temporary switch back. Remaining compatibility work lies in the published action releases workflows use and the platforms on which their self-hosted runners operate.