Migrate GitHub Actions to Node.js 24 Before the Deadline

If you've been scrolling past the yellow deprecation warnings in your GitHub Actions logs, it's time to stop. GitHub has confirmed that Node.js 24 becomes the default runtime for all JavaScript-based actions on June 16, 2026. After that, Node.js 20 gets removed from GitHub-hosted runners entirely later in fall 2026. Any action still pinned to a Node 20 runtime will fail outright.

This isn't a soft nudge. Node.js 20 reached end-of-life in April 2026, which means zero security patches going forward. Running your CI/CD pipelines on an unpatched runtime is a supply-chain risk that most security teams won't tolerate. Here's how to audit your workflows, test the migration, and land it cleanly.

The timeline, verified

GitHub's official changelog post (last updated May 19, 2026) lays out two milestones:

1. June 16, 2026 — Runners begin using Node.js 24 by default for all JavaScript-based actions. Actions built for Node 20 will still execute, but on a runtime they weren't designed for. Expect subtle breakage.
2. Fall 2026 — Node.js 20 gets completely removed from GitHub-hosted runners. No fallback, no opt-out. Workflows that still reference Node 20 actions will fail hard.

The deprecation process started back in September 2025, and the date has shifted twice since then (originally fall 2026, then June 2, now June 16). The runner codebase already includes Node 24 enforcement logic as of runner v2.333.0, so the mechanism is live and ready to flip.

Step 1: Audit which actions use Node 20

The warning message in your workflow logs already tells you which actions are affected. It looks like this:

Warning: Node.js 20 actions are deprecated. The following actions
are running on Node.js 20: actions/checkout@v4, actions/setup-node@v4.
Actions will be forced to run with Node.js 24 by default starting
June 16th, 2026.

But relying on log output means you only catch what ran recently. For a proper audit, grep across all your workflow files:

# Find all action version pins across your workflows
grep -rn 'uses:' .github/workflows/*.yml | grep -E '@v[0-9]+' | sort

This gives you a full inventory. For each action you find, check the action's action.yml manifest on GitHub. If the runs.using field says node20, that action needs an update.

The most commonly affected first-party actions and their Node 24-compatible versions:

• actions/checkout — v4 → v5 (or v6 for latest)
• actions/setup-node — v4 → v5
• actions/cache — v4 → v5
• actions/upload-artifact / download-artifact — v4 → v5
• actions/setup-python / setup-go — v5 → v6

Third-party actions are the bigger risk. If a maintainer hasn't shipped a Node 24-compatible release, you're stuck waiting on someone else's timeline. Check the action's repo for open issues or PRs mentioning Node 24. If there's nothing, open one now while you still have runway.

Step 2: Test with the opt-in flag

Don't wait for June 16 to find out what breaks. GitHub provides an environment variable to force Node 24 right now:

env:
  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true

jobs:
  test-node24:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: '20'
      - run: npm ci && npm test

Set this in a test branch and run your full pipeline. You'll catch compatibility issues while you still have the fallback option. This is the single most valuable thing you can do this week.

After June 16, there's also a temporary opt-out: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. GitHub baked the word "unsecure" right into the variable name, which tells you how they feel about it. It's a stopgap for emergencies, not a strategy. It won't work once Node 20 is removed from runners entirely.

Step 3: Run parallel matrix builds

For teams that need to validate before committing, a matrix build lets you run the same workflow under both runtimes simultaneously:

jobs:
  ci:
    strategy:
      matrix:
        force-node24: [true, false]
    runs-on: ubuntu-latest
    env:
      FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: ${{ matrix.force-node24 }}
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: '20'
      - run: npm ci && npm test

This approach lets you compare results side-by-side. When the Node 24 leg passes consistently, you can drop the matrix and commit to the new versions.

What actually breaks on Node 24

Most well-maintained first-party actions will just work after a version bump. The real problems come from edge cases in custom actions and less-maintained third-party code.

ESM-only packages. Node 24 tightens ESM enforcement. Packages that dropped CommonJS support may behave differently if your action's bundler or loader configuration assumes CJS resolution. You'll see errors like ERR_REQUIRE_ESM at runtime.

V8 API changes. Node 24 ships V8 13.x, which changes some internal APIs. Native addons compiled against Node 20's V8 may need a rebuild. This mainly affects actions that use native modules for cryptography, file watching, or platform-specific operations.

Deprecated API removals. APIs that were merely deprecated in Node 20 may be fully removed in Node 24. The url.parse() legacy behavior, Buffer() constructor without new, and certain crypto methods are all candidates.

Silent vs. loud failures. The dangerous category is silent breakage. An action that calls a deprecated API might get a different return value instead of throwing. Your workflow passes, your artifact looks fine, and you don't discover the problem until production. That's why testing with the opt-in flag on real workloads matters more than a quick smoke test.

Platform-level gotchas

Beyond action code, there are two platform constraints worth knowing about:

• macOS 13.4 and below are incompatible. Node 24 doesn't support macOS Ventura 13.4 or earlier. If your self-hosted macOS runners are on older OS versions, you'll need to update them before the switch.
• ARM32 self-hosted runners lose support. Node 24 has no official ARM32 support. If you run self-hosted runners on 32-bit ARM hardware, those will stop working after Node 20 removal.

Using custom runner images to control the rollout

If you use self-hosted or third-party runners, you don't have to wait for GitHub's rollout schedule. Custom runner images let you pin the Node version and control exactly when the switch happens. This is useful when you need to migrate dozens of repositories on a coordinated schedule rather than having GitHub flip the default under you.

Tenki Runners plug into your existing GitHub Actions setup and support custom runner images, so you can bake Node 24 into your image, test it across all repositories, and then roll it out team by team. You avoid the scenario where GitHub flips the default on June 16 and half your org's pipelines go red before anyone's had coffee. Tenki's runners are also around 50% cheaper than GitHub-hosted runners, which makes running parallel matrix builds during the migration less painful on the bill.

The migration checklist

Here's the sequence that works, week by week:

1. This week: Grep all workflow files for action version pins. Build a spreadsheet of every action, its current version, and whether a Node 24-compatible release exists. File issues on any third-party action that hasn't shipped one.
2. Before June 16: Set FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true in a test branch. Run your full pipeline against it. Fix what breaks. Bump action versions in your main branch once green.
3. After June 16: Confirm no workflow in your org still uses the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION escape hatch. If any repo still needs it, that's a red flag worth escalating.
4. Before fall removal: Do a final sweep. Check workflow templates in your org's template repositories, since outdated templates silently seed the problem into every new project.

The version bumps themselves take five minutes per repo. The audit and testing are what take the real time, and they're worth every minute. A broken CI pipeline on a Monday morning doesn't just block one developer. It blocks every pull request, every deployment, and every team that depends on that repository.