containerd 1.7 ends September 1 —
the runtime under your nodes that nobody inventories.
containerd 1.7 reaches end of life on September 1, 2026. If that name draws a blank, that is rather the point: containerd is the container runtime that actually runs the containers — under most Kubernetes nodes, under Docker Engine, under the managed node images of every major cloud. It is arguably the most widely deployed piece of infrastructure software that almost no asset inventory lists, because it arrived as an implementation detail of something else.
1.7 is not just another release: it is the last of the 1.x line, the series that carried the industry’s move from Docker-as-runtime to CRI-native Kubernetes. Released March 10, 2023, it served roughly three and a half years — the project’s longest-serving LTS, stretched well past the written policy of “at least two years” partly to cover Kubernetes versions still pinned to it. That extension is over.
Where 1.7 is actually running
Three places, in descending order of how likely anyone is watching. Managed Kubernetes node pools — the providers roll the runtime with node-image updates, so clusters that take those updates migrate without noticing. Self-managed clusters and kubeadm installs — here the runtime version is whatever was installed when the node was built, and nodes built in 2023–2024 are overwhelmingly 1.7. Docker hosts — Docker Engine bundles containerd, so standalone Docker servers pinned to older Engine packages carry it too. The common thread: 25 is 1.7’s risk score today, and the population least likely to know it is the population that will still be running it in 2027.
The support map after September 1
| Line | Released | Support ends | Status | Risk score |
|---|---|---|---|---|
| 2.3 (LTS) | 2026-04-30 | 2028-04-30 | supported | 10 |
| 2.2 | 2025-11-05 | 2026-11-06 | Warning | 25 |
| 2.0 (LTS) | 2024-11-05 | 2027-03-01 | supported | 10 |
| 1.7 (LTS) | 2023-03-10 | 2026-09-01 | ends Sep 1 | 25 |
| 1.6 (LTS) | 2022-02-15 | 2025-08-23 | EOL | 40 |
Note the 2.0 wrinkle: it is an LTS, but its window closes March 1, 2027 — barely six months after 1.7’s. A 1.7 → 2.0 migration done this autumn schedules its own sequel almost immediately. 2.3 LTS, supported to April 30, 2028, is the landing zone for a migration you intend to do once.
The 1.x → 2.x reality
The project is direct about it: “there are no compatibility guarantees with upgrades to major versions” — 2.0 removed features deprecated across the 1.x years and moved to a new configuration format, with migration tooling shipped to ease the jump. In practice the work is node-scoped and rollable: check the deprecation warnings 1.7 already logs, convert the config, and roll node pools the way you would a Kubernetes minor. The failure mode is not a hard cutover — it is the fleet where nobody owns the runtime, so nobody schedules the roll at all.
If you run managed Kubernetes: confirm your node pools are on current images — that is the whole job. If you run your own nodes or Docker hosts: containerd --version across the fleet this week decides whether September 1 is a non-event or a finding. Our Stack Scanner and the containerd lifecycle page — updated at every build from upstream data — cover the rest.
Frequently Asked Questions
When does containerd 1.7 reach end of life?
September 1, 2026. containerd's policy gives active releases 8 months and LTS releases at least two years; 1.7, released March 10, 2023, ran roughly three and a half years as the project's longest-serving LTS — and it is the final 1.x line.
What replaces containerd 1.7?
The 2.x series. containerd 2.0 LTS is supported to March 1, 2027 and 2.3 LTS to April 30, 2028, with non-LTS lines (2.1, 2.2) supported for about a year each. For a migration you do once, 2.3 LTS is the landing zone with the most runway.
Does containerd 1.7 end of life affect Kubernetes clusters?
Yes, quietly. containerd is the runtime under most Kubernetes nodes — including managed node images on the major clouds — and under Docker Engine. Managed Kubernetes providers handle the runtime in their node image updates, so the exposure concentrates in self-managed clusters, kubeadm installs, and hosts where containerd was installed once and never revisited.
Is upgrading containerd 1.x to 2.x a breaking change?
The project states there are no compatibility guarantees across major versions, and 2.0 removed long-deprecated features and moved to a new configuration format — though migration tooling ships with it. Treat it as a planned node-by-node rollout with the deprecation warnings checked first, not a package bump.