Google gives notice about 90 days before a Cloud Run functions runtime is deprecated. During deprecation you can still deploy but patches follow policy only until decommission. After decommission you cannot create or update workloads on that runtime, and existing ones may be disabled. Plan the upgrade during the deprecation window.
The lifecycle, as documented
Google's runtime support page describes three states.
| State | Create and redeploy | Running workloads | Language, package and OS patches |
|---|---|---|---|
| GA support | Yes | Yes | As per policy |
| Deprecated | Yes | Yes | As per policy |
| Decommissioned | No | May be disabled | No updates |
The page says Cloud Run functions begins issuing notifications 90 days before a runtime reaches deprecation, through the Google Cloud console. It also says Google may change a runtime's support schedule in accordance with the terms of your agreement.
Updates during GA are applied according to your workload's security update policy, and when a language version is no longer actively maintained by its community, Google stops maintaining that runtime too.
An example from the schedule
The page lists dates per runtime. As fetched on 19 October 2026, the Node.js 20 row shows a deprecation date of 2026-04-30 and a decommission date of 2026-10-30, and Node.js 22 shows 2027-04-30 and 2027-10-31. Node.js 18 shows 2025-04-30 and 2025-10-30. Dates can shift, so read the live page, not this post.
If you have a Node.js 20 function, the decommission date on that page is days away. After it, you cannot update the function on that runtime, which means you cannot ship a dependency patch either.
Why this is a supply chain issue
Dependency fixes need a deployment. If a runtime is decommissioned, deployment is blocked, so a vulnerable package can no longer be fixed in place. The upgrade then happens under pressure, mixed with an urgent patch. Better to move early.
An upgrade plan
- List functions by runtime. Use your inventory or the Google Cloud console and tools.
- Rank by decommission date and by exposure, internet facing first.
- Check dependency compatibility with the newer runtime. Native modules and older packages often need upgrades.
- Test in a staging project with the new runtime ID.
- Deploy and watch error rates and latency.
- Remove the old function or retarget traffic. Do not leave both.
What the stack names mean for review
The schedule lists runtime base images for each runtime, with a default stack and a full variant. A full variant generally carries more system packages, which means more to patch. Choose the variant on purpose and note it in the inventory. Google's page lists the names, and the contents are documented separately, so check before assuming.
Try it yourself
Open the vulnerability management demo and sort findings by age. Findings on a runtime near decommission should rise to the top.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning give you a list of what you run and what each build contains, which helps you plan runtime upgrades before a deadline. Free scan: gold.safeguard.sh/scan.
Quick check
Can I still deploy during the deprecation period?
Per Google's page, you can generally continue to create and update workloads during the deprecation period, but you should use it to migrate.
What happens after the decommission date?
You can no longer create or update workloads on that runtime, and workloads that keep using it may be disabled.
Sources
Last reviewed: 19 October 2026.
