Martial Wehrling
FR
← All articles
By Martial Wehrling7 min read

GitHub Actions: test Node 24 before the June 2026 switch

GitHub ActionsNode.jsCI/CDDevOpsJavaScript

GitHub Actions isn't just a task orchestrator. It's also a runtime for JavaScript actions that many teams treat as invisible infrastructure. That layer is about to change: GitHub is preparing to move the actions runtime from Node 20 to Node 24.

The important point isn't that Node 24 exists. The important point is operational: if your production workflows use JavaScript actions, you should test their behavior under Node 24 now, before that runtime becomes the default used by the runners.

According to the GitHub Actions changelog, Node 20 reached end of life in April 2026. Runner v2.328.0 supports Node 20 and Node 24, but Node 20 remains the current default. GitHub states that from June 16, 2026, runners will start using Node 24 by default for JavaScript actions. FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true turns on testing; ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true allows a temporary opt-out.

So this is a classic migration window: early enough to test properly, close enough not to push the topic back to the next CI incident.

What really changes

The following fact is verified: the migration concerns the runtime used by JavaScript actions in GitHub Actions. It doesn't automatically mean that your Node application, your server, your front end or your npm scripts run on Node 24. Those parts still depend on your explicit choices, for example actions/setup-node or the container image used.

The risk area is more discreet: the actions you call with uses:. A JavaScript action declares its runtime in its action.yml or action.yaml file, through the runs.using field. Maintainers must migrate that value to Node 24. Users, for their part, must update the actions they consume and test their workflows with the compatibility variable.

Analysis: this is typically the kind of change that breaks business code less often than the integrations around it. Artifact upload, cache, publishing, deployment, pull request comments, changelog generation, cloud authentication: all these steps often rely on third-party actions. If one of them ships old dependencies, assumptions about the Node API, or an incompatible binary, the symptom will show up in CI, not in your local test suite.

Why test now

Node 24.16.0 has been released as Krypton LTS since May 21, 2026. The Node previous releases page lists it as the latest LTS version as of June 2, 2026. On the lifecycle side, the end-of-life tracking site also shows Node 24 in active support until October 20, 2026, then in security support until April 30, 2028, while Node 20's security support ended on April 30, 2026.

These dates don't mean your whole application fleet has to migrate today. They mean that, for GitHub Actions, silently staying on Node 20 is no longer a sustainable position. GitHub provides transitional compatibility, but the temporary opt-out has an explicit name: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. It isn't a targeted mode.

Node 24.16.0 also brings platform changes that can indirectly affect advanced actions: randomUUIDv7, req.signal on IncomingMessage, randomization in the test runner, mock timer support for AbortSignal.timeout, npm 11.13.0, OpenSSL 3.5.6, undici 7.25.0 and SQLite 3.53.0. These aren't promises of breakage. They're surfaces to be aware of when an action depends heavily on the network, TLS, the npm package manager, internal tests or experimental APIs.

Action plan for workflow users

Start by identifying your third-party actions. List the calls made with uses: in the .github/workflows directory, then separate official GitHub actions, actions from well-known vendors, internal actions and poorly maintained actions. The risk isn't the same everywhere.

Next, create a test run with Node 24 enabled. The simplest way is to temporarily add the environment variable at the level of the relevant workflow or job: env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true. The goal isn't to change your entire Node strategy at once. The goal is to run the same workflows with the targeted JavaScript actions runtime, then observe the failures. If something breaks, note precisely the action, its version, the step, the error message and the runner's operating system.

Then update the actions. If a third-party action blocks you, check whether there's a recent release, a Node 24-compatible branch, or a maintained alternative. For production-critical actions, avoid floating references if your supply chain policy requires reproducibility; at the very least, pin an explicit version according to your internal standards.

A point of attention verified by GitHub: Node 24 isn't compatible with macOS 13.4 or earlier in this context, and Node 24 has no official ARM32 support. If your workflows cover these environments, treat this topic as a platform constraint, not as a simple dependency update.

Action plan for action maintainers

If you maintain a JavaScript action, the first file to look at is action.yml. The expected migration is to declare runs.using on Node 24. But don't make only that declarative change.

Test the action on the operating systems you claim to support. Check native dependencies, network calls, TLS handling, uses of the fetch and undici APIs, npm scripts and tests. If your action itself runs Node commands, clearly distinguish the action's runtime from the Node version installed for the user.

Then publish a clear release. Mention Node 24 support, any excluded platforms and the minimal changes required. For a widely used action, a major version may be appropriate if you explicitly drop old platforms or behaviors. If the migration is transparent, a minor or patch release may be enough, depending on your semantic versioning and your contract with users.

Reasonable hypothesis: many problems will come less from Node 24 itself than from aging dependencies, actions that haven't been republished, or workflows that combine old operating system constraints with modern JavaScript actions. That's why a real CI test is worth more than a quick read of the changelog.

Production checklist

For a team that ships regularly, this migration should be treated as a small CI/CD reliability project.

The last point matters. An opt-out can save a release, but it mustn't become a rug to sweep CI debt under. If you use it, add a removal date, an owner and a tracking ticket.

Sources

FAQ

Will my Node application automatically run on Node 24 in GitHub Actions?

No. The announced migration targets the JavaScript actions runtime. Your configuration determines the Node version used by your application, your tests or your scripts, for example with actions/setup-node, your container or your runner image.

How do I test compatibility before June 16, 2026?

Add FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true to the environment of the workflow or job to test, then rerun your critical workflows. Read the failures per action called, not just per overall job.

What if a third-party action breaks under Node 24?

Look for a newer version, open an issue with a minimal log, or replace the action if it's no longer maintained. For a critical publishing or deployment step, don't discover this problem on the day of the switch.

Can we stay on Node 20 temporarily?

GitHub documents a temporary opt-out with ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. It's useful as a safety net, but Node 20 has already reached the end of security support according to the sources cited. So treat it as a short, tracked exception.

Are older macOS runners affected?

Yes, if your workflows depend on macOS 13.4 or earlier. GitHub notes that Node 24 is incompatible with macOS 13.4 or earlier in this context. These workflows must be tested and possibly migrated to a supported environment.