March 12, 2026
Docker Swarm vs. Kubernetes in 2026: The Case for Staying Simple
Docker Swarm vs Kubernetes in 2026, without the slogans: what each costs to run, what Kubernetes has that Swarm does not, what Swarm does without any add-on, and a decision guide by team size and workload. With the numbers, and sources.
By 2026 the argument has stopped being about which orchestrator is more capable. Kubernetes is. It has been for years, and any comparison that pretends otherwise is selling something. The argument is about what capability costs, in money, in people and in the hours between a bug and its fix, and whether the workloads you actually run need what you would be paying for. This post lays that out with numbers where numbers exist, and with a plain list of what each side lacks. If your first question is whether Swarm is still a going concern, it is, with dates.
What each one is
Docker Swarm is orchestration built into Docker Engine. docker swarm init on one machine and docker swarm join on the others gives you a cluster with a Raft-replicated control plane on the managers, an overlay network with DNS and a load-balancing virtual IP per service, rolling updates with rollback, secrets and configs, health-checked tasks, and a routing mesh that publishes a port on every node. You describe workloads in Compose files with a deploy: section and run docker stack deploy. There is nothing else to install.
Kubernetes is a control plane (API server, etcd, scheduler, controllers) that runs pods on nodes through kubelets, and a resource model, Deployments, Services, Ingresses, ConfigMaps and the rest, extended by custom resources and the controllers that reconcile them. Networking, ingress, storage, metrics and policy are interfaces with implementations you choose. The three hyperscalers and many others run the control plane for you as a managed service.
The difference in kind is that Swarm is one thing and Kubernetes is a platform for building your platform. Everything below follows from that.
What it costs
A swarm's bill is its nodes. The cost article prices it on published rates: three 4-vCPU nodes for $25.50 a month at OVHcloud or €107.97 at Hetzner, and that is the whole bill.
Managed Kubernetes adds a control-plane fee before any node runs: $0.10 per cluster-hour on EKS and GKE, about $73 a month, and $0.60 an hour on EKS once the Kubernetes version is in extended support; AKS has a Free tier with no SLA and a Standard tier at $0.10. Then the system components take their share of every node: kubelet, kube-proxy, the CNI agent, the logging and metrics agents a managed offering installs. The providers publish reservation formulas rather than a single figure, and on a small node it is not small.
So on three nodes, the fee alone is the size of the swarm's whole bill. On ten it is 40 percent on top at OVH prices, 13 percent at Hetzner's. On a hundred it is noise. That gradient is the honest version of "Kubernetes makes sense at scale": the fixed cost is the same whether you have three nodes or three hundred, so it is a small share of a large bill and a large share of a small one.
The cost that does not appear on an invoice is people. A swarm is run by whoever already runs Docker. A Kubernetes cluster, managed or not, is run by someone who knows Kubernetes, and upgrades arrive three times a year with deprecations in each. Whether that person exists on your team, or has to be hired, is usually the deciding cost.
What Kubernetes has that Swarm does not
This list is the reason to choose Kubernetes, and it is worth reading before the reasons to choose Swarm.
- Autoscaling. The Horizontal Pod Autoscaler scales on CPU, memory or any metric you expose; the cluster autoscaler adds nodes. Swarm has
docker service scaleand nothing that calls it for you. - Multi-tenancy. Namespaces, resource quotas, network policies and RBAC on the API let many teams share one cluster with real isolation. Swarm has one flat namespace, no quotas and no network policy; a team boundary is a separate overlay network and a separate swarm, or the SwarmCLI proxy, which adds swarm-wide roles and an audit log in front of the daemon.
- Custom resources and operators. If you need your own resource type with a controller that reconciles it, a database operator, a certificate manager, a GitOps controller, that is the Kubernetes model. Swarm has services, and only services.
- Scheduling depth. Taints and tolerations, node and pod affinities, topology spread, priority and preemption. Swarm has placement constraints, placement preferences to spread across a label, and
max_replicas_per_node. Enough for most placement, not for the exotic. - The ecosystem. Service meshes, policy engines, admission controllers, a Helm chart for everything, a managed offering from every cloud. Swarm's ecosystem is Compose, Traefik, and SwarmCLI Charts for packaging.
- A managed control plane. Nobody sells managed Swarm, because there is nothing to manage; the flip side is that if a manager dies at 3 a.m., it is your 3 a.m.
What Swarm does without any add-on
The mirror list, because half of Kubernetes' complexity is choosing and operating things Swarm ships with.
- Networking. An overlay network per stack with service DNS, a virtual IP that load-balances across replicas, IPsec encryption on a flag, and the routing mesh. Kubernetes needs a CNI plugin, a Service type decision, an ingress controller and, for encryption, a mesh.
- Rolling updates and rollback, with
parallelism,delay,order: start-firstandfailure_action: rollback, per service, in the Compose file. - Secrets and configs, encrypted in the Raft log, delivered only to nodes that run a task needing them, mounted from memory. Kubernetes Secrets are base64 in etcd until you add encryption at rest.
- Health checks in the image or the stack file, honoured by the scheduler and the update.
- Jobs, as
replicated-jobandglobal-jobservice modes since Engine 20.10. - Storage plugins, through CSI cluster volumes since Engine 23, though the driver ecosystem is thin next to Kubernetes'.
- A Compose file as the deployment unit. The file a developer runs locally is, with a
deploy:section, the file production runs. The conversion table lists the keys that change.
What Swarm lacked was the tooling around it, and that is the gap SwarmCLI exists to close: a terminal UI that shows the cluster the way k9s shows Kubernetes, Helm-style charts, an RBAC proxy with mTLS and audit, and GPU scheduling through generic resources.
Side by side
| Docker Swarm | Kubernetes | |
|---|---|---|
| Install | Part of Docker Engine; swarm init and join | A distribution or a managed service, plus CNI, ingress, storage and metrics choices |
| Control plane cost | None beyond the manager nodes | About $73 a month per cluster on EKS and GKE; AKS Free or Standard; six times that in extended support |
| Deployment unit | Compose file with deploy: | Deployment, Service, Ingress, ConfigMap, Secret; usually a Helm chart |
| Networking | Overlay, DNS, VIP, routing mesh, encryption, built in | CNI plugin, Service, ingress controller, mesh, chosen and operated |
| Autoscaling | None | HPA, VPA, cluster autoscaler |
| Multi-tenancy | One namespace; the SwarmCLI proxy for roles and audit | Namespaces, quotas, network policies, RBAC |
| Extensibility | Services only | CRDs and operators |
| Upgrades | Engine upgrade, managers first; Swarm entries in the changelog | Three minor versions a year, each with deprecations; extended support is paid |
| Who runs it | Whoever runs Docker | Someone who knows Kubernetes |
| Managed offering | None | Every major cloud |
Where the choice actually falls
Choose Swarm when the workload is a few to a few dozen services described in Compose files, on a handful of nodes, and the team is developers who also operate. That covers a lot: a product with an API, a web front end, a worker and a database; an edge or Raspberry Pi cluster; local AI inference on GPU nodes; a homelab; an internal platform for a mid-size company. The traffic is predictable enough that scaling is a decision rather than a reflex, and the money saved is a person's salary rather than a control-plane fee.
Choose Kubernetes when you need one of the things on its list: autoscaling driven by metrics, strict multi-tenancy in one cluster, operators, or a managed control plane your organisation can hold someone else accountable for. Also when the team already knows it, or when the thing you are deploying ships as a Helm chart and nothing else; porting an operator-shaped application to Swarm is work that never ends.
Run both when the workloads split that way, and many teams do: Kubernetes for the autoscaled public product, Swarm for internal tools, batch, edge and everything that does not need the platform. Planning a move to Kubernetes lists the reasons that hold up and the ones that do not.
The one-line version
Kubernetes is the better orchestrator. Swarm is the better deal for most of the clusters people actually run, because the bill is the nodes, the file is the Compose file, and the person who runs it is already on the team. Which of those matters more is your call; this page's job was to make it a call and not a slogan.
Common concerns, answered
Is Docker Swarm better than Kubernetes? For a team running a few to a few dozen services on a handful of nodes, Swarm does the whole job with no control-plane fee, no add-ons and no platform engineer. Kubernetes is better when you need what Swarm lacks: autoscaling on metrics, namespaces and network policies for multi-tenancy, custom controllers, or a managed control plane from a cloud provider.
What can Kubernetes do that Docker Swarm cannot? Horizontal autoscaling on metrics, namespaces with quotas and network policies, custom resource definitions and operators, taints and affinities beyond constraints, a service-mesh ecosystem, and a managed control plane from every major cloud. Swarm has none of these natively; the SwarmCLI proxy adds RBAC and audit, and SwarmCLI Charts add packaging.
How much cheaper is Docker Swarm than Kubernetes? By the control-plane fee and the per-node overhead. Managed Kubernetes charges about $73 a month per cluster for the control plane on EKS and GKE, six times that on an old version; a swarm has no such line. On a three-node cluster that fee is the size of the whole swarm bill; on a hundred nodes it is noise.
2026 Docker Swarm Mastery Series
- Mar 9: [The Foundation] The Definitive Docker Swarm Guide for 2026.
- Mar 12: [Expert Analysis] Docker Swarm vs Kubernetes in 2026.
- Mar 16: [Edge Frontier] Setting up the ultimate 3-node Swarm on Raspberry Pi 5.
- Mar 19: [Security Specialist] Docker Swarm secrets.
- Mar 23: [Ops Mastery] Docker Swarm Auto-healing: Troubleshooting Pending States.