Vercel and GitHub Actions Are Ending Support for Node.js 20: What You Need to Do
Node.js 20 reached End-of-Life (EOL) on April 30, 2026.
Now, the consequences of that lifecycle milestone are becoming increasingly visible across the JavaScript ecosystem.
GitHub Actions removed Node.js 20 from its runners on September 23, 2026, moving JavaScript actions to Node.js 24. Vercel will follow on October 1, 2026, when Node.js 20 will no longer be available for new Builds and Functions.
These are not isolated platform decisions. They are part of the normal lifecycle of a Node.js release and a reminder that reaching EOL affects much more than the runtime installed on a production server.
If your applications, CI/CD pipelines, or deployment configuration still depend on Node.js 20, now is the time to identify where that dependency exists and plan the upgrade.
A Quick Look at the Node.js Release Lifecycle
Node.js follows a predictable release schedule.
Major releases move through different stages: Current, Active LTS, Maintenance LTS, and eventually End-of-Life. Odd-numbered releases are short-lived and do not become LTS releases, while even-numbered releases are the versions typically used for production workloads.
As of September 2026:
| Version | Status | EOL |
|---|---|---|
| Node.js 20 (Iron) | End-of-Life | April 30, 2026 |
| Node.js 22 (Jod) | Maintenance LTS | April 30, 2027 |
| Node.js 24 (Krypton) | Active LTS | April 30, 2028 |
| Node.js 26 | Current | April 30, 2029 |
Node.js 20 was originally released in April 2023 and became an LTS release later that year. After three years of Current, Active LTS, and Maintenance support, its official lifecycle ended on April 30, 2026.
The important part is what End-of-Life actually means.
Once a Node.js release reaches EOL, the Node.js project stops publishing regular updates for that release line, including security fixes.
That creates a growing gap over time. Newly discovered vulnerabilities may be fixed in supported releases while remaining unpatched in Node.js 20. Dependencies and development tools may also stop testing against it, operating-system compatibility can drift, and infrastructure providers eventually remove it from their supported environments.
The Node.js project specifically highlights security vulnerabilities, toolchain breakage, ecosystem drift, and compliance concerns among the risks of continuing to operate an EOL release.
Node.js End-of-Life documentation
GitHub Actions Has Removed Node.js 20
On September 23, 2026, GitHub completed the removal of Node.js 20 from GitHub Actions runners.
JavaScript actions now run using Node.js 24, and the temporary ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION opt-out that allowed users to continue using Node.js 20 is no longer available.
There is an important distinction here: this does not simply mean that every application tested through GitHub Actions must use Node.js 24.
GitHub Actions uses Node.js internally to execute JavaScript-based Actions. Action authors specify that runtime through the runs.using property in their action.yml metadata.
For example:
runs:
using: 'node24'
main: 'dist/index.js'
If you maintain a JavaScript Action, GitHub recommends updating runs.using to node24 and publishing a new release.
If you consume Actions in your workflows, the task is different: review the Actions your workflows depend on and update them to versions that support Node.js 24.
For example, a workflow may contain dependencies such as:
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
The relevant question is not only which Node.js version your application tests against, but also whether the Actions executing parts of the workflow have been updated for the new runtime.
GitHub also notes an infrastructure implication: Node.js 24 does not support macOS 13.4 and earlier or ARM32. Self-hosted runners using those environments therefore need additional attention.
GitHub: Node 20 is no longer available in GitHub Actions
GitHub Actions metadata syntax for JavaScript Actions
Vercel Is Disabling Node.js 20 on October 1
Vercel announced a similar change for applications deployed on its platform.
Starting October 1, 2026, Node.js 20 will be disabled for Vercel Builds and Functions.
Projects configured to use Node.js 20 for Functions will encounter an error when attempting to create a new deployment.
Existing deployments are an important exception.
Vercel states that already-deployed Serverless Functions running Node.js 20 will continue to work. The restriction applies to new deployments.
That means an application continuing to serve traffic successfully on September 30 may still fail the next time a deployment is triggered if its runtime configuration remains pinned to Node.js 20.
You can identify affected Vercel projects using the CLI:
npm i -g vercel@latest
vercel project ls --update-required
Vercel allows the runtime to be configured through Project Settings or the engines field in package.json.
For example:
{
"engines": {
"node": "24.x"
}
}
Node.js 22 remains a supported LTS line, but Node.js 24 is currently Vercel's default runtime for new projects and provides a longer remaining support window.
Vercel: Node.js 20 is being deprecated on October 1, 2026
Vercel Node.js runtime documentation
Why Are Platforms Removing Node.js 20?
The timing is not accidental.
Both GitHub and Vercel explicitly connect their Node.js 20 deprecations to the runtime reaching EOL.
Infrastructure providers maintain runtimes across build systems, serverless environments, CI/CD runners, operating systems, architectures, and internal tooling. Continuing to provide an unsupported runtime means carrying compatibility and security responsibilities for software that is no longer maintained by the upstream Node.js project.
That is why EOL should not be treated as the day an application suddenly stops working.
It is better understood as the point at which the ecosystem begins moving forward without that release.
A Node.js 20 application may continue running after April 30. But over time, the surrounding environment changes: CI/CD platforms remove runtimes, cloud providers change supported versions, packages raise their minimum Node.js requirements, and security fixes continue landing only in supported release lines.
Vercel and GitHub Actions are two visible examples of that process happening now.
What Should You Do If Your Project Still Uses Node.js 20?
Start by identifying every place where the runtime is defined, not just the version installed on a developer machine.
A Node.js version can be pinned across multiple layers of a project:
package.json
.nvmrc
.node-version
Dockerfile
CI/CD configuration
GitHub Actions
Vercel Project Settings
deployment configuration
development environments
production infrastructure
Then determine whether Node.js 20 is being used by the application itself, by build infrastructure, or by both.
If your project runs on Vercel
Check whether the project is affected:
vercel project ls --update-required
Review the Node.js version under your Vercel Project Settings and check package.json, .nvmrc, .node-version, and any other runtime configuration committed to the repository.
Where appropriate, move the application to a supported LTS release, test the application under that runtime, and redeploy.
Vercel currently defaults new projects to Node.js 24.
If your project uses GitHub Actions
Review the Actions referenced by your workflows and upgrade outdated versions to releases compatible with Node.js 24.
If you maintain your own JavaScript Action, inspect action.yml:
runs:
using: 'node24'
main: 'dist/index.js'
Do not assume that changing the Node.js version used to test your application automatically updates the runtime used internally by third-party Actions. They are separate concerns.
For self-hosted runners, also verify operating-system and architecture compatibility with Node.js 24.
If your production application itself runs Node.js 20
Treat the platform warnings as a signal to review the application more broadly.
Before upgrading:
- Identify Node.js version constraints across the repository and infrastructure.
- Audit dependencies and native addons for compatibility.
- Run the application and test suite against the target Node.js release.
- Review deprecated or changed runtime APIs.
- Validate build and deployment pipelines.
- Test production-representative workloads before rollout.
- Monitor the application after deployment for runtime, memory, CPU, and performance regressions.
Moving from Node.js 20 to a supported release is not just changing the output of node -v. A major runtime upgrade can also change V8, npm, OpenSSL, built-in APIs, native addon compatibility, dependency behavior, and application performance.
The Bigger Picture: EOL Eventually Reaches the Entire Toolchain
The Vercel and GitHub Actions announcements illustrate an important part of runtime lifecycle management.
EOL does not necessarily break your application on day one. It changes who is still responsible for keeping the runtime working.
After April 30, 2026, Node.js 20 stopped receiving official maintenance from the Node.js project. GitHub has now removed it from its Actions runners. Vercel is removing it from new Builds and Functions.
Other parts of the ecosystem will continue making similar decisions.
For engineering teams, the lesson is not simply to react whenever a cloud provider announces a deadline. Node.js lifecycle management should be part of normal platform maintenance: know which runtime versions your applications depend on, understand their support windows, and plan upgrades before infrastructure starts forcing the transition.
If Node.js 20 is still somewhere in your stack, this is a good time to find it.
And, more importantly, to understand what depends on it.
Running an Unsupported Node.js Version?
Knowing that a runtime needs to be upgraded is often easier than completing the upgrade.
Legacy dependencies, native addons, deprecated APIs, testing requirements, and production constraints can turn a version change into a significant engineering project.
That is why NodeSource participates in the Node.js LTS Upgrade & Modernization Program with the OpenJS Foundation.
The program helps organizations identify upgrade blockers, understand migration risk, and build a practical path from unsupported Node.js versions to supported releases. NodeSource's Upgrade Discovery tooling can inspect dependencies, native addons, and Node.js API usage to help turn an uncertain migration into a measurable engineering project.
If your application is still running Node.js 20, Node.js 18, or another End-of-Life release, start by understanding what is actually preventing the upgrade.
