Docker Engine 25.0 end of life: December 4, 2026 and what to do

TL;DR

• Docker Engine 25.0 reaches end of life on December 4, 2026, according to endoflife.date, about three weeks from today.
• The line was released on January 19, 2024, and the latest release in it is 25.0.18.
• Update every host to 25.0.18 now, then plan the move to a Docker Engine release line that is still supported.
• After the end of life date, new vulnerabilities will be fixed only in newer release lines, so any host left on 25.0 keeps its flaws.
• Stackurity matches end-of-life data against your inventory every day, including Docker Engine found in installed packages.

What reaches end of life, in plain English

Docker Engine is the service that builds and runs containers on a host. Every machine that starts a container, from a developer laptop to a build server to a production node, runs a copy of it. Each release line is supported for a limited time. While it is supported, Docker ships patch releases that fix bugs and security flaws. When it reaches end of life, that stops, even if a serious flaw is reported the following week.

The endoflife.date record for Docker Engine shows that Docker Engine 25.0 was released on January 19, 2024 and reaches end of life on December 4, 2026. The record does not mark it as a long term support release and lists no separate extended support date, so December 4, 2026 is the date to plan around.

Why it matters now

Nothing stops working on the day. Your containers keep running and your images keep building. What changes is the next time a flaw is found in the engine: a supported line gets a patch and you update, while an unsupported line gets nothing, and you must jump to a newer release under pressure.

The container engine is a sensitive piece of software. It usually runs with high privileges, it can mount host directories and it controls the network between containers, so a flaw in it can matter more than a flaw in one application. That is a good reason not to leave it on a line that no longer receives fixes.

It is also easy to lose track of. Hosts get built once from an image or a script, the engine version is pinned in a provisioning file nobody reads, and a few machines are never rebuilt. Our guide to an end of life Kubernetes release on Amazon EKS describes the same pattern for the orchestration layer, and teams that run both face two deadlines within weeks.

There is an audit cost too. Customers and auditors ask which components are still supported, and an engine on an unsupported release needs an exception, a compensating control or a dated upgrade plan. It is far easier to have the plan before the date than to explain the gap afterwards.

Upgrades take time because hosts may depend on storage drivers, plugins, orchestration tools or CI runners tied to one engine line. Three weeks is not enough to finish a careful upgrade of every host, but it is enough to find them all, patch to the latest release and put a date on each remaining move.

Am I affected?

You are affected if any server, build machine, CI runner or developer workstation you manage runs Docker Engine 25.0. Any release whose version starts with the line number 25.0 belongs to it, up to the latest, 25.0.18.

To check one Linux machine by hand, run:

docker version

The output lists the client and the server separately, because the client on a workstation can be a different version from the engine it talks to. Read the version under Server. To see how the engine was installed, run one of these:

dpkg -l 'docker*'
rpm -qa 'docker*'

On managed container platforms the engine is the provider's concern, so read the provider's notice instead. Also search your provisioning scripts, machine images and CI configuration for a pinned engine version, since the next rebuilt host will take that version rather than the one you just updated.

One caveat applies to distribution packages. Linux distributions backport fixes, so a package version can look older than the upstream release while still containing a fix. The end of life date, however, is the upstream line's date: when the line ends, your distribution and Docker decide separately what they will keep supporting, so read your distribution's notice rather than relying on the upstream date alone.

How to upgrade away from Docker Engine 25.0

1. Find every host on Docker Engine 25.0. List servers, build machines, CI runners and workstations, and note the owner, environment and role of each.
2. Update each one to 25.0.18, the latest release in the line, using the package manager you installed it with. Restart the engine in a maintenance window, because a restart stops containers that are not set to survive it.
3. Choose the supported Docker Engine line you will move to. Check Docker's release notes and the endoflife.date page for Docker Engine for the current list, because it is not part of the data we cite here, and pick one your tooling supports.
4. Rehearse the move on one non-critical host. Upgrade it, run your usual images and compose files against it and compare behaviour, networking and storage before you touch production.
5. Roll the change out in batches, keeping a way back, and update the machine images and provisioning scripts so rebuilt hosts do not return to Docker Engine 25.0.
6. Check again after deploying. Confirm that no host still reports Docker Engine 25.0, and record the hosts you could not move before the date, each with an owner and a deadline.

How to check with Stackurity

Stackurity keeps one live inventory of your servers, applications, repositories, container images, Kubernetes workloads and cloud services, and matches it against end-of-life dates every day. A read-only agent reads installed packages on supported Linux distributions, and a runtime installed by hand is checked for end of life only. Hosts on Docker Engine 25.0 appear in a short list, most urgent first, so you do not need to log in to each machine.

Be aware of the limits. Network appliance firmware, statically linked libraries and libraries copied into an application outside a package manager are not covered, so check those by hand. After you upgrade, check again asks the agent for a fresh report and records whether the issue is really gone. See how Stackurity handles fixes in the docs. The core is open source, and Stackurity Cloud has a 14-day free trial without a card: start a free trial.

FAQ

When does Docker Engine 25.0 reach end of life?

According to endoflife.date, Docker Engine 25.0 reaches end of life on December 4, 2026. After that date the release line gets no further fixes.

Is Docker Engine 25.0 still getting security updates?

Until its end of life date the line is still listed, and the latest release in it is 25.0.18. After December 4, 2026 new flaws will be fixed only in newer release lines, so a host left on 25.0 keeps every flaw found later.

What should I upgrade Docker Engine 25.0 to?

Move to a Docker Engine release line that Docker still supports. Read Docker's own release notes and the endoflife.date page for Docker Engine for the current list, then pick the line with the longest remaining support that your hosts and tooling accept.

Does Stackurity find Docker Engine 25.0 on my servers?

Stackurity reads installed packages on supported Linux distributions and matches end-of-life data against that inventory every day. Docker Engine installed by hand outside a package manager is checked for end of life only, and network appliance firmware is not covered.

Sources: endoflife.date, Docker Engine; Stackurity product facts.