Node.js 20 on Google Cloud: October 30 Decommission and Your Options

Following Node.js 20 End-of-Life (EOL) on April 30, 2026, Google Cloud has initiated the final stages of its runtime deprecation lifecycle. If you rely on Cloud Run or Cloud Run Functions, October 30, 2026 marks the official decommission date for the Node.js 20 runtime. 

Most coverage on EOL software talks about immediate migration to a supported Node.js version. While ideal, immediate migration is not always practical for organizations managing large deployment estates, rigid framework constraints, or unvalidated dependencies. Immediate migration is also not your only option: Google Cloud compute services allow you to bring your own runtime, giving you a viable alternative.

This post explains: 

• Google Cloud deprecation mechanics: how EOL enforcement actually works across Cloud Run, Cloud Run Functions, App Engine, GKE, Compute Engine, and Cloud Run Jobs.
• Commercial extended support: how a supported distribution such as HeroDevs Never-Ending Support (NES) for Node.js delivers SLA-backed CVE fixes for Node.js 20.
• Flexible timelines: how to secure your existing Node.js 20 estate today and migrate to newer runtimes on your own schedule.

‍

Decommission Only for Google Cloud-Managed Runtimes

Google Cloud only enforces runtime lifecycle policy where Google manages the runtime. That single sentence explains the entire policy landscape. The Cloud Run runtime lifecycle states it directly: container images deployed directly to Cloud Run are not subject to the policy, which only applies to workloads that use Google Cloud-managed base images.

When you deploy your own Node.js runtime or your own container image, Google has no mechanism to patch, deprecate, or even see what is running inside it. Responsibility for the runtime shifts entirely to you.

Here is how that plays out service by service, including where a fully supported Node.js 20 fits in each model.

‍

Node.js 20 on Google Cloud Run

Cloud Run supports two deployment models, and they sit on opposite sides of the policy line.

‍

Source deployments use Google-managed base images. These follow the published runtime support schedule: the Node.js 20 runtime entered deprecation on April 30, 2026 (post-EOL) and will be decommissioned on October 30, 2026. During the deprecation period you can still create and redeploy workloads. Google continues base-image OS updates during deprecation, but no new Node.js 20 patches exist to apply since upstream stopped producing them. Runtime customer support ended at deprecation. After October 30, 2026, you can no longer create or update workloads on the managed runtime, and workloads that continue to run on it may be disabled.

‍

Container image deployments are exempt from the lifecycle policy entirely. Under the current policy, Cloud Run will run whatever image you give it, indefinitely, and never patches what is inside. That exemption is exactly what makes the bring-your-own-runtime path work: build your container image with the NES for Node.js 20 runtime instead of the community version. The NES for Node.js runtime comes from the binary installed in the Dockerfile instead of from a Google-managed Node.js runtime image. Cloud Run services will keep running a fully supported Node.js 20 with no decommission deadline. Installation guidance is in the HeroDevs documentation for Google Cloud Run.

‍

Node.js 20 on Google Cloud Run Functions (Formerly Cloud Functions)

Google Cloud Run Functions uses the same managed runtime model and the same runtime support schedule as Cloud Run source deployments: Node.js 20 deprecated April 30, 2026, decommissioned October 30, 2026. Functions on the Node.js 20 runtime can still be updated during the deprecation window, but after decommission you can no longer create or update functions on the runtime, and existing functions may be disabled.

‍

Unlike Cloud Run services, the functions deployment experience does not accept a custom runtime directly. You can run NES for Node.js for Google Cloud Run Functions by packaging your function as a custom container image and deploying it to Cloud Run. This uses the Google Functions Framework to receive function invocations, but the Node.js runtime itself comes from the HeroDevs Node.js NES binary that you download into the container. Your function logic stays the same, the HTTP and event-handling behavior stays the same, and the runtime underneath becomes one you control and one that keeps receiving security patches.

‍

Node.js 20 on Google App Engine (GAE)

For GAE, Node.js 20 reached end of support on April 30, 2026. Per the App Engine runtime lifecycle, that means Google no longer applies security updates or patches, deploying or updating applications on the runtime is blocked, and runtime issues are no longer eligible for technical support. Applications continue to run and receive traffic, but on a frozen, unpatched runtime that you can no longer redeploy. The final deprecation date is April 30, 2027, so Google Cloud is giving an extra year post-EOL before it removes the org-policy exemption that could re-enable runtime deployments.

‍

GAE is a Platform-as-a-Service (PaaS) that lets you deploy web applications. The Standard Environment uses restricted, pre-configured sandboxes that do not allow custom binaries or runtimes. However, the Flexible Environment allows you to set runtime: custom in your app.yaml configuration which tells App Engine to build your environment from a Dockerfile to build your environment as shown in NES documentation.

‍

Node.js 20 on Google Kubernetes Engine (GKE)

GKE operates under a shared responsibility model that isolates cluster infrastructure from workload runtimes. Google manages the Kubernetes control plane and patches node operating system images, but never what runs inside your pods. There is no Node.js deprecation policy on GKE because GKE has no concept of a Node.js runtime: the Node.js version in your container images, along with application dependencies and OS packages inside those images, is exclusively your responsibility, with no Google deprecation, notification, or enforcement mechanism.

‍

That also means nothing on GKE will ever warn you that your pods are running an unpatched EOL runtime. Bringing NES for Node.js into a GKE cluster is straightforward: build it into your container image and deploy as usual, so every pod runs a supported Node.js 20.

‍

Node.js 20 on Google Compute Engine (GCE)

Compute Engine has no runtime deprecation policy because Google does not manage anything above the virtual machine. Whether you install Node.js from a binary, bake it into a virtual machine, or run it in a container on the instance, every runtime on it is yours to patch. A GCE instance running Node.js 20 will run forever. Nothing stops it, and nothing patches the runtime.

‍

This creates a forever-day vulnerability: a known CVE in EOL software that will never receive an official patch, so exposure is permanent rather than time-boxed. Every vulnerability disclosed affecting Node.js 20 remains exploitable on that instance permanently unless you act.

‍

For a secured and supported Node.js 20, you can run NES for Node.js on Compute Engine by downloading the NES binary onto a Linux instance and running your application with that runtime. If you are using containers, build NES for Node.js into your image and deploy as usual.

‍

Node.js 20 on Google Cloud Run Jobs

Cloud Run Jobs, the batch and task execution side of Cloud Run, follows the same split as Cloud Run services. Jobs built from source on Google-managed base images fall under the Cloud Run runtime lifecycle and share the Node.js 20 dates: deprecated April 30, 2026, decommissioned October 30, 2026. Jobs deployed from container images you build yourself are outside the policy, and the runtime inside them is your responsibility.

‍

‍

Bring Your Own Supported Runtime: NES for Node.js on Google Cloud

HeroDevs NES for Node.js is a drop-in replacement distribution of Node.js that continues to receive security patches after the community version reaches EOL. NES maintains compatibility with the corresponding upstream version, so application code and dependencies do not change. The only change is the source of the Node.js runtime for your workloads on Cloud Run, Cloud Run Functions, App Engine, GKE, Compute Engine, and Cloud Run Jobs.

‍

This approach converts an unbounded forever-day exposure with EOL Node.js into a supported runtime. New CVEs affecting Node.js 20.x, 18.x, 16.x, 14.x, and 12.x receive patches through NES. Your compliance posture holds, because supported software with active security patching satisfies auditors in a way an unmaintained upstream community version cannot. And your engineering team migrates to Node.js 22, 24, or 26 on a timeline driven by testing and business priorities rather than by an October 30 decommission date.

‍

NES closes the runtime patching gap. HeroDevs has already patched more than 10 CVEs disclosed after EOL, including CVE-2026-56848 and CVE-2026-58043. As more vulnerabilities are discovered, HeroDevs will continue to patch EOL versions.

‍

Over time, npm packages will drop Node.js 20 from their engine support ranges, which is why NES is a bridge for migrating on your own timeline rather than a permanent destination.

‍

Your Node.js 20 Action Plan on Google Cloud

Google Cloud’s decommission date marks when community patching for Node.js 20 ended, not when your app is ready to move. Conflating the two leads to rushed migrations, skipped regression testing, or unpatched runtimes in production.

Recommended Action Plan:

1. Audit Runtimes: Inventory all Node.js 20 instances across Cloud Run, Cloud Run Functions, App Engine, GKE, and Compute Engine, including dependencies embedded within custom container images.
2. Classify Workloads: Decide whether to migrate immediately or secure first and migrate later. Prioritize App Engine Standard (where deploys are already blocked) and Cloud Run/Cloud Run Functions (where the October 30, 2026 decommission date hard-blocks new deploys and risks disabling active workloads).
3. Secure Remaining Apps: For workloads that need more time, deploy HeroDevs NES for Node.js to maintain security patches while migrating at a safe, controlled pace.

Explore NES for Node.js or talk to the HeroDevs team about your Google Cloud deployment. 

‍

Frequently Asked Questions

What happens to Node.js 20 Cloud Run services and functions after October 30, 2026?

After the decommission date, you can no longer create new workloads or update existing ones on the Node.js 20 managed runtime, and Google states that workloads continuing to run on a decommissioned runtime may be disabled. On Google Cloud, decommission is a real operational deadline, not just a patching cutoff.

Does Google Cloud deprecation apply to Node.js 20 in container images?

No. Container images deployed directly to Cloud Run, Cloud Run Jobs, GKE, Compute Engine, and App Engine Flexible custom runtimes are outside any runtime lifecycle policy. Google has no visibility into or enforcement over the runtime inside your image. That also means Google is not patching it. The runtime is entirely your responsibility.

Will my application code need changes for NES for Node.js?

NES for Node.js is a drop-in replacement distribution that maintains compatibility with the corresponding upstream version. Application code and dependencies remain unchanged. You change the source of the runtime, not your application.

Does staying on Node.js 20 with NES satisfy compliance requirements?

Frameworks such as PCI DSS, FedRAMP, HIPAA, DORA, and NIS2 expect software that is supported and receiving security patches. NES provides both, something an abandoned community version cannot. Confirm specifics with your auditor, but a commercially supported runtime with active CVE patching is a fundamentally different compliance posture than an EOL one.

Which Node.js versions does NES cover?

NES currently provides security patches for Node.js 20.x, 18.x, 16.x, 14.x, and 12.x, so estates spanning multiple EOL versions can be covered under one support model.