Node.js v20 Goes EOL April 30 — and Your Cloud Provider Is Pulling the Plug the Next Day

Node.js v20 reaches end of life on April 30, 2026. From that date, the Node.js project stops issuing security patches, CVE remediations, and bug fixes for the v20 release line. The branch becomes a static artifact. Security researchers who responsibly disclose vulnerabilities in v20 will receive a standard response: the version is EOL, no fix will be issued. Any CVE discovered in v20 after April 30 will be documented as affecting an EOL version with no upstream remediation path.

To make this concrete: the March 2026 Node.js security release patched nine CVEs across active release lines, including two high-severity process crashes in TLS and HTTP request handling. That kind of release happens because the Node.js project is actively maintaining those lines. After April 30, it does not happen for v20.

What makes this deadline more operationally significant than a standard upstream EOL is that all three major cloud providers — AWS, Azure, and GCP — align their managed runtime deprecation to the same date. The upstream EOL and the cloud provider deprecation begin simultaneously. You do not lose just upstream patches. You begin losing managed runtime-level security coverage from your cloud provider on the same day, and you begin losing the ability to create new deployments on that runtime according to each provider's specific schedule.

‍

AWS Lambda

AWS Lambda's deprecation schedule for Node.js 20 moves through three phases:

Starting April 30, 2026: AWS stops applying security patches to the Node.js 20 managed runtime. Functions on Node.js 20 lose technical support eligibility. The runtime is removed from the AWS Console, though you can still create and update functions via AWS CLI, CloudFormation, SAM, or CDK.

Starting June 1, 2026: You can no longer create new Lambda functions using the Node.js 20 runtime through any method.

Starting July 1, 2026: You can no longer update existing Lambda functions using the Node.js 20 runtime. This is the hard operational deadline. Your functions continue running and can be invoked after all three phases, but you lose all ability to modify them.

The less-discussed impact is the managed patching. AWS handles OS-level and runtime-level security patching for active Lambda runtimes as part of the service. For deprecated runtimes, that patching stops. The runtime environment your code runs on becomes a static, unpatched artifact from April 30 forward.

‍

Azure App Service

Azure App Service follows community support timelines for its runtime lifecycle. When Node.js 20 reaches EOL on April 30, Azure stops providing security patches and runtime-level support for that version. Your applications continue running on Node.js 20, but the runtime underneath is no longer receiving updates.

The support boundary changes immediately and operationally. Microsoft's support policy explicitly excludes runtime issues for deprecated Node.js versions. If you open a support case for a production incident that traces to Node.js 20 runtime behavior after April 30, the support team will note that the runtime is deprecated and decline to investigate the runtime-level issue. For teams in regulated industries where support SLAs are part of vendor assessments, this is a meaningful change to your support coverage model.

‍

GCP Cloud Run and Cloud Functions

GCP follows the same April 30 deprecation date but has a meaningfully different timeline from AWS and Azure. Per GCP's published runtime lifecycle schedule, Node.js 20 on Cloud Run enters deprecated status on April 30, 2026, with a decommission date of October 30, 2026.

During the deprecation window — April 30 through October 30 — you can generally continue to create new workloads and update existing ones. GCP continues applying patches per its automatic base image update policy through this window. Customer support for runtime-level issues ends at deprecation on April 30, but the hard deployment block and patching cutoff don't arrive until October 30.

This gives GCP teams a six-month buffer that AWS and Azure do not provide. It does not eliminate the urgency — the October 30 decommission is a firm deadline after which new deployments are blocked and existing workloads may be disabled — but it is a meaningfully different operational window than what Lambda teams are working with.

‍

The compliance dimension

For teams in regulated industries, this is not just a security question. PCI DSS 6.3.3 requires all system components to be protected from known vulnerabilities by installing applicable security patches. Running EOL software that cannot receive patches creates a documented control gap. The same logic applies to HIPAA Technical Safeguard requirements, FedRAMP continuous monitoring controls, and the EU Cyber Resilience Act's component-level vulnerability management requirements, which begin phasing in for manufacturers in September 2026.

The compliance-defensible path is either upgrading to a supported version or using an extended support provider with a documented CVE remediation process. Running EOL Node.js v20 without either is a gap that auditors and regulators will find.

‍

What to do before April 30

The right answer for most teams is upgrading to Node.js v22, which is in maintenance LTS support through April 2027. Most v20 applications are compatible with v22 with minimal code changes. For teams wanting the latest release, Node.js v24 is also available.

For teams in enterprise environments where a runtime upgrade requires change management review, QA cycles, and coordinated deployment — which is most of them — completing that upgrade before April 30 may not be realistic. A runtime upgrade in a production system with dozens of dependent services and a multi-week release cycle does not happen because a calendar date arrives.

For those teams, Never-Ending Support for Node.js provides continued security patch backporting for v20 after the upstream EOL date. NES closes the security gap during the migration window. It is not a permanent alternative to upgrading — v22 is the right long-term position — but it makes the migration timeline a technical and organizational decision rather than a security emergency.

‍

FAQ

What happens to Node.js v20 applications after April 30, 2026?Applications running on Node.js v20 will continue to function — the runtime does not stop working. However, the Node.js project will no longer issue security patches or CVE remediations for v20. Any vulnerability discovered on or after May 1 will not receive an official fix. Over time, the accumulation of unpatched vulnerabilities increases the attack surface for any application still running on v20.

Do AWS, Azure, and GCP all cut support on the same day?All three begin their deprecation process on April 30 — the same day as upstream EOL. However, the operational impact differs by provider. AWS stops managed patching April 30, blocks new function creation June 1, and blocks function updates July 1. Azure stops patching and runtime support April 30. GCP deprecates April 30 but continues patching through the deprecation window until the decommission date of October 30, 2026, when new deployments are blocked.

Can I still deploy Node.js v20 applications on AWS Lambda after April 30?Yes, briefly. You can still create and update functions via CLI and IaC tools until June 1. After June 1, new function creation is blocked. After July 1, function updates are blocked. AWS-managed runtime security patching stops on April 30 regardless.

What is the upgrade path from Node.js v20?The recommended upgrade path is Node.js v22, in maintenance LTS support through April 2027. Node.js v24 is also available. Most v20 applications are compatible with v22 with minimal code changes.

What if my team cannot upgrade from Node.js v20 before April 30?NES for Node.js provides continued security patch backporting for v20 after the EOL date, giving teams a secure bridge while they complete a proper, tested migration to v22.

Does running EOL Node.js v20 create compliance issues?Yes, in most regulated environments. PCI DSS, HIPAA, FedRAMP, and the EU Cyber Resilience Act all have requirements around using supported, patchable software. Running EOL software that cannot receive security patches creates a documented control gap. The compliance-defensible path is either upgrading to a supported version or using an extended support provider with a documented remediation process.

Is Node.js v22 stable for production use?Yes. Node.js v22 is in maintenance LTS support through April 2027 and is the production-recommended version from the Node.js project for teams migrating off v20.

‍

‍