48 Hours to Node.js v20 EOL: What Actually Happens to Your App on May 1

Two days out — what the operational picture looks like

April 30 is Thursday. If your team has Node.js v20 running in production and the upgrade to v22 is not complete, here is the precise operational picture of what changes when May 1 arrives — not in abstract risk terms, but as concrete changes to the systems and services your team depends on.

The framing matters: end of life does not mean your Node.js v20 application stops running. The runtime does not fail. Your services do not go offline. What changes is the security infrastructure underneath your application — who is responsible for patching it, who is monitoring it for vulnerabilities, and what happens when the next CVE drops.

‍

What changes upstream: the Node.js project

Starting May 1, the Node.js Security Working Group closes the v20 vulnerability intake process. Security researchers who responsibly disclose vulnerabilities in Node.js v20 will receive a standard response: the version is EOL, no patch will be issued. The CVE will be documented as affecting an EOL version with no remediation available from the project.

The Node.js release team closes the v20 branch for any new commits. No patches, hotfixes, backports, or dependency updates will be merged against v20 from this point forward. The branch becomes a static artifact.

To understand what this means in practice, look at the March 2026 Node.js security release. It patched nine CVEs across the active v20, v22, and v24 release lines. Two of those — CVE-2026-21637 and CVE-2026-21710 — were rated high severity with CVSS scores of 7.5, affecting TLS and HTTP request handling respectively. After April 30, a vulnerability of equivalent severity discovered in Node.js v20 will not receive a patch. The security release will note it as affecting an EOL version and will move on.

This is not speculative risk. It is the documented behavior of every Node.js release that has gone EOL before v20. Node.js v16 went EOL in September 2023 and has not received a security patch since. Node.js v18 went EOL in April 2025 and has not received a patch since. v20 follows the same path.

‍

What changes at AWS Lambda

AWS Lambda manages Node.js runtimes as a service component of the Lambda execution environment. For active runtimes, this means AWS applies security patches to the managed Node.js environment — handling OS-level, runtime-level, and Lambda-service-level vulnerabilities that sit below your function code. You benefit from this patching transparently without needing to manage it yourself.

When a Node.js runtime moves to deprecated status, this managed patching stops. Starting April 30, 2026, the Node.js 20 Lambda runtime becomes a static environment — your function code continues running on it, but the runtime underneath is no longer receiving updates from AWS.

The more immediate operational impact is on deployments. AWS moves through a phased blocking schedule after deprecation: new function creation using Node.js 20 is blocked starting June 1, 2026, and updates to existing functions are blocked starting July 1, 2026. If your team deploys a new Lambda function, updates an existing function's configuration, or performs any operation that writes a new function configuration to Lambda after those dates, it will fail. This affects CI/CD pipelines, infrastructure-as-code deployments, and any automation that touches Lambda function configuration.

‍

What changes at Azure App Service

Azure App Service follows community support timelines for the lifecycle of its runtimes. For active runtimes, this means the platform applies security patches to the managed Node.js environment automatically. You benefit from this patching without needing to manage it yourself.

When a Node.js runtime reaches end of life, this managed patching stops. After community support ends, App Service cannot provide security patches or related customer support for that runtime — your applications continue to run, but the runtime underneath is no longer receiving updates from Microsoft.

The support implications are immediate and operational. Microsoft's support policy for Azure App Service 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 the deprecation date, the support team will note that the runtime is deprecated and decline to investigate the runtime-level issue. You can still receive support for Azure platform-level issues, but the runtime itself is outside the support boundary.

For teams that rely on Azure support as part of their incident response process — especially in regulated industries where support SLAs are part of vendor assessments — this is a meaningful change to the support coverage model.

‍

What changes at GCP Cloud Run and Cloud Functions

GCP follows a published runtime lifecycle for managed runtimes in Cloud Run and Cloud Functions. Node.js 20 entered deprecated status on April 30, 2026, which triggers deprecation warnings in the Cloud Console. The decommission date — after which new deployments and revisions on the runtime are hard-blocked and existing workloads may be disabled — is October 30, 2026.

Like AWS, GCP provides managed security patching for active runtimes, updating the Node.js environment within their managed execution model. For deprecated runtimes, that patching continues as per GCP's automatic base image update policy during the deprecation window, but ends entirely at decommission. Customer support for runtime-level issues ends at deprecation, not decommission — meaning runtime support is already gone as of April 30, 2026.

The timeline is specific: teams have until October 30, 2026 to move workloads off Node.js 20 before new deployments are blocked and existing workloads become eligible for disablement. This is not an indefinite window.

‍

The compounding effect

What makes the April 30 / May 1 combination materially different from a standard upstream EOL is the simultaneous loss of multiple security layers. Upstream EOL alone means losing project-level patches. Cloud provider deprecation on top of that means losing runtime-level managed patching from your cloud provider. Losing both simultaneously creates a security gap that no single mitigation — other than upgrading or getting extended support — closes.

For AWS Lambda teams, this happens simultaneously: managed patching stops April 30, the same day as upstream EOL. For GCP Cloud Run teams, deprecation starts April 30 but managed patching continues through the deprecation window until the October 30 decommission date — a six-month buffer that AWS does not provide. Azure App Service follows community support timelines and stops patching at the EOL date as well.

Teams running on AWS or Azure that were relying on their cloud provider's managed patching as a partial compensating control for the upstream EOL lose that compensating control on April 30. GCP teams have a window, but the decommission hard stop on October 30 is a firm deadline regardless.

‍

What to do in the next 48 hours

If the v22 upgrade is within reach before Thursday — meaning your team can complete the upgrade, run it through your validation process, and deploy it to production before April 30 — do it. The v20 to v22 migration is straightforward for most applications. AWS, Azure, and GCP all support Node.js v22 as an active runtime. The upgrade resolves the EOL exposure entirely.

If the upgrade cannot be completed before Thursday — which is the realistic situation for many enterprise teams given the timeline — the alternative is NES for Node.js, which provides continued security support for v20 after the EOL date. NES is not a substitute for upgrading to v22, but it eliminates the security gap during the migration window and removes the urgency pressure that leads to rushed, under-tested upgrades.

What is not a plan: letting May 1 arrive without having made a decision. Running v20 unpatched from May 1 while the cloud provider deprecation progresses is a compounding security position that gets worse over time, not better.

FAQ SECTION

Will Node.js v20 applications stop working after April 30?

No. Node.js v20 applications will continue running after April 30. End of life means the upstream project and cloud providers stop patching and supporting the runtime — it does not cause application failure. The operational risk accumulates over time as unpatched vulnerabilities go unaddressed.

What does AWS Lambda do specifically with Node.js 20 after the EOL?

AWS moves the Node.js 20 Lambda runtime to deprecated status. Managed security patching for the runtime stops. New function deployments and configuration updates specifying the Node.js 20 runtime will begin encountering deprecation warnings and eventually hard blocks, depending on the deprecation timeline AWS publishes.

Will Azure still support my application if it runs on Node.js 20 after deprecation?

Azure App Service will continue running Node.js 20 applications, but Microsoft will not investigate or support issues related to Node.js 20 runtime behavior on deprecated versions. Platform-level Azure support remains available, but Node.js runtime-specific issues fall outside the support boundary for deprecated versions.

What is the difference between upstream EOL and cloud provider deprecation?

Upstream EOL means the Node.js project stops patching v20. Cloud provider deprecation means the cloud provider stops patching their managed Node.js 20 runtime and eventually blocks new deployments on that runtime. Both happen in the April 30 / May 1 window — creating a situation where you lose both project-level and cloud-provider-level security patching simultaneously.

What does NES for Node.js provide after the EOL date?

NES for Node.js provides continued CVE monitoring, security patch backporting, and vulnerability remediations for Node.js v20 after the April 30 EOL date. NES gives teams a secure posture during the migration window while they plan and execute an upgrade to Node.js v22 LTS.

How quickly can a Node.js v20 to v22 migration be completed?

For applications without major incompatibilities, a Node.js v20 to v22 migration can be relatively fast — the API delta between v20 and v22 is manageable. However, enterprise environments require validation cycles, change management approvals, and staged deployments that add time regardless of the code complexity. Teams that cannot complete the migration before April 30 should have NES coverage in place rather than leaving the gap open.