On 8 October 2026, Docker Engine 29.9.0 closed CVE-2026-92542: an unprivileged user on a Swarm node could inject forged Ethernet frames into the encrypted overlay networks of neighbouring nodes. That is last week's changelog for the orchestrator half the industry writes off as dead.
"Swarm is dead" always comes out the same way, in the tone of someone repeating the obvious, and almost always from someone who has not opened the changelog. What interests us about it is not that it is unfair to Swarm. It is that the rumour running the other way — "Kubernetes is the standard, put Kubernetes in" — costs you just as much, and gets repeated more often.
Cards on the table before we go on: we run both. We have Docker Swarm and Kubernetes in production, for ourselves and for customers, and we offer managed Kubernetes. Which means we come out ahead of this post whatever we say. So we are also going to say when you should not be buying it from us.
What the changelog says, which is the only thing that has no opinion
Swarm is not a product you buy separately: swarm mode ships inside the Docker engine itself, and has done since version 1.12, in 2016. If you have Docker, you have Swarm. That explains much of the confusion: nobody announces "Swarm 4.0" because Swarm has no version numbers of its own, it moves with the engine. And the engine moves.
The 29.9.0 release notes carry nine entries that touch swarm mode. Besides the CVE, one worth reading slowly if you run encrypted overlay networks: an error while programming the data-plane encryption could cause traffic on an encrypted overlay network to go out in cleartext towards some nodes. The note itself bounds the damage — the receiving node drops those packets as spoofed, so the loss of confidentiality is limited to one-way flows, a UDP DNS query or a SYN that goes nowhere — but there it was. The rest are the boring ones: releasing IPsec security associations when the last container leaves the encrypted network, instead of letting them pile up until the daemon restarts; tasks rejected when the daemon cannot write to /var/lib/docker; published ports reachable over IPv6 with the userland proxy enabled.
The previous version, 29.8.0 of 3 September, carried eight more: service names that stopped resolving on a node indefinitely after it missed a network membership announcement, a node gossiping a superseded service-discovery value after concurrent updates, the spreading out of periodic synchronisation work so it stops arriving in bursts. Anyone who has debugged intermittent name resolution in a cluster knows how much each of those three lines hurts. And 29.9.1 landed six days after 29.9.0, on 14 October.
There is a second data point, contractual and with small print. Mirantis, which bought Docker's enterprise business in November 2019, published on 1 July 2025 that "Swarm will be fully supported through at least 2030", and the whole sentence matters: that commitment is as part of Mirantis Kubernetes Engine 3, its paid platform that orchestrates Kubernetes and Swarm side by side. It is not a promise about the Swarm you run for free inside the Docker engine; that one is maintained by Moby, which is where the fixes above come from. Two different hands, and worth not conflating them when you quote the date.
Maintained does not mean alive in the sense that matters to you, either. Across those seventeen entries there is not one new feature: they are fixes. Mirantis's recent investment in CSI, which lets a stateful service have real persistent storage, is the exception that proves the pace. What Swarm does not do today, it probably never will. That is a good argument for not building on it. Better than "it is dead", which was also false.
The calendar on the other side
Kubernetes has the opposite problem, and it is also measured in dates. The project maintains release branches only for the three most recent minor versions — right now 1.37, 1.36 and 1.35, going end of life on 28 October 2027, 28 June 2027 and 28 February 2027 — and ships roughly three releases a year. As you read this there is a fourth branch finishing its window: 1.34 runs out of patches on 27 October 2026, nine days from now. If that is what your cluster runs, the calendar has stopped being an architecture debate.
We did the full arithmetic in Kubernetes expires every fourteen months, and you cannot skip versions, so we will not repeat it here. The operational summary is what counts for this decision: adopting Kubernetes means committing to a control-plane maintenance window every few months, forever, and doing them in order because you cannot skip versions. It is not a flaw in the project — that cadence is what keeps the ecosystem moving — it is the price of entry. Paying it is fine: signing up for it without knowing you have is not.
The question that decides is not a technical one
In whichever thread is running that week, the argument always circles scale and the feature catalogue: autoscaling, operators, service meshes, maximum node counts. Fine for a talk. But almost none of the companies we work with are anywhere near those limits: their problem has never been the number of nodes.
What decides is far more prosaic, and it is two questions: who is going to do the next orchestrator version upgrade? and who answers at three in the morning when a node stops responding? If both answers are "the same person who also builds the product", the size of the feature catalogue is irrelevant. You have picked a tool you will not be able to operate, and that is not an architecture problem, it is an outage with a delivery date.
When Swarm is still the right answer
- Nobody on the team has "platform" in their job title. You can learn Swarm in an afternoon because the mental model is the Compose they already use every day; Kubernetes is not, and pretending otherwise gets expensive on the first on-call night.
- The service catalogue is stable. Ten, twenty, forty services that change version, not shape. Swarm spreads replicas and does rolling updates with whatever parallelism you set, no new language required.
- You have never needed the platform to add replicas on its own at two in the afternoon.
What you lose by choosing it is the ecosystem. There are no operators that install a database with its own recovery logic, there is no extension catalogue, and a good share of the new tooling that appears every month assumes a Kubernetes cluster on the other end. If your two-year roadmap runs through that, building on Swarm today does not avoid the migration: it postpones it, and charges you more for it, because you will do it with production on your back.
When Kubernetes, and what you are signing
Kubernetes clearly wins when the product calls for it: when you need autoscaling driven by real metrics, when you want to isolate teams or customers in namespaces with their own quotas and permissions, when your platform will host things you do not write yourself and you need the operator catalogue, or when the end customer demands a specific piece of the ecosystem. In those cases there is no debate and we do not start one.
What we do open is the operating bill, because it is the part nobody puts on the slide: three maintenance windows a year as a floor, an inventory of add-ons that expire on their own schedule, and dependence on third-party pieces whose health almost nobody audits. Of the ingress controller that published much of the industry to the internet, we found out that half of Kubernetes was maintained by two people; its repository is archived read-only today. It came out when someone had to look, not before.
So when people ask, we end up at one of two answers: either Kubernetes with somebody actually operating it — in-house or us — or Swarm, and spend the time you save on what actually moves your business. The combination that ends in an emergency call is always the same one: Kubernetes stood up by the product team during a quiet quarter and, after that, nobody.
What does not change either way
This is where most of the debate goes quiet, and it is where the incidents actually come from. The orchestrator gives you none of these four things for free:
| What stays yours | What happens if you skip it |
|---|---|
| Pinning your image versions | Any restart deploys something nobody has tested |
| Knowing who maintains each component | You find out on the day of the security advisory |
| Backups with a tested restore | You have a lucky charm, not a backup |
| Telemetry that alerts on symptoms | The service has been broken for hours and the monitoring screen is still green, because it watches the front page and not the process. The alert arrives by phone, from a customer. |
The first row is the one that broke the deployment of our own website, and we gave it a whole post: "latest" is not a version. The other three are the usual work, the kind that appears in no orchestrator table because it does not tell them apart. We deploy both with the same method — the deployment comes out of a repository, with the version pinned and the way back rehearsed — precisely because the orchestrator is the interchangeable part.
And the axis we measure any design against does not change either: failure is inevitable, an outage is a design decision. A machine is going to die, whichever orchestrator you pick. Whether that is maintenance paperwork or an afternoon when nobody can invoice depends on decisions somebody made months earlier, and none of them is called Swarm or Kubernetes.
Sources: CVE-2026-92542, the overlay data-plane encryption bug and the other entries quoted are in the Docker Engine release notes for 29.9.0 (8 October 2026), 29.9.1 (14 October) and 29.8.0 (3 September) — docs.docker.com. The count of entries touching swarm mode (nine in 29.9.0, eight in 29.8.0) is ours: it includes those naming Swarm and those affecting only overlay networking, service discovery or gossip, which are swarm-mode-only machinery; the reader can redo the count on that same page. The "through at least 2030" commitment inside Mirantis Kubernetes Engine 3 and the CSI work come from the Mirantis announcement of 1 July 2025 — mirantis.com; a vendor promise about its own paid product. The three-maintained-branches policy, the cadence of roughly three minor releases a year and the end-of-life dates for 1.37, 1.36, 1.35 and 1.34 come from the official Kubernetes releases page — kubernetes.io, consulted on 18 October 2026. Built-in orchestration reached the engine in Docker 1.12, announced by Docker in 2016 — docker.com; Mirantis announced the Docker Enterprise acquisition on 13 November 2019. The judgements about when each orchestrator fits are ours, they come from running both in production, and they are not data: check them against your own case.
Who will do the next version upgrade on your cluster?
If you are running 1.34, you have nine days of patches left. We run managed Kubernetes and Docker Swarm with reproducible, reversible deployments, backed by 24/7 support. And if yours is one of the cases that does not need Kubernetes, we will tell you.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN