Docker Swarm vs Kubernetes
Docker Swarm vs Kubernetes compared for 2026: setup effort, control-plane HA and quorum, documented scale limits, Compose stacks vs manifests, networking and ingress, secrets, autoscaling, RBAC, extensibility, managed Kubernetes pricing, Mirantis support for Swarm, release cadence and when each is the right orchestrator.
Quick Answer
Docker Swarm mode and Kubernetes both run containers across a cluster, keep a declared number of replicas alive, do rolling updates and give services stable DNS names. Swarm is built into Docker Engine: run docker swarm init, join nodes, and deploy stacks from a Compose file (the legacy version 3 format) with docker stack deploy. Managers use Raft (3 managers tolerate 1 failure, 5 tolerate 2), the routing mesh lets any node accept traffic for any published port, and secrets are encrypted at rest and in transit. It is still maintained: Docker Engine 29.9.3 (3 November 2026) shipped Swarm and SwarmKit security fixes, and Mirantis keeps a dedicated Swarm team inside Mirantis Kubernetes Engine. Kubernetes is the bigger platform: RBAC, custom resources and operators, the HorizontalPodAutoscaler, NetworkPolicies, Gateway API, pluggable CNI and CRI, documented support for 5,000 nodes and 150,000 pods, and managed control planes on every major cloud (EKS and GKE at $0.10 per cluster-hour, DigitalOcean's free). Latest: v1.37.2 (28 October 2026). Pick Swarm for a few nodes, a small team and Compose-based apps. Pick Kubernetes for autoscaling, multi-team clusters, an operator ecosystem or a managed service.
Last updated November 12, 2026. Covers Docker Engine 29.9.3 (3 November 2026) and Kubernetes v1.37.2 (28 October 2026), with Swarm docs from docs.docker.com, Kubernetes docs from kubernetes.io, Mirantis's Swarm page, and EKS, GKE and DigitalOcean Kubernetes pricing, read in November 2026.
| Feature | Docker Swarm | Kubernetes |
|---|---|---|
| License | Apache-2.0 (Moby / Docker Engine and SwarmKit) | Apache-2.0; CNCF project (the first hosted project) |
| Project & Maintenance | Built into Docker Engine; SwarmKit actively developed; Mirantis maintains and supports Swarm inside Mirantis Kubernetes Engine | Community-governed upstream with many distributions and vendors |
| Installation | docker swarm init on one Docker host, docker swarm join on the rest; no extra software | kubeadm, distributions or turnkey managed services; HA needs a load balancer in front of kube-apiserver |
| Node Requirements | Any host running Docker Engine; Docker publishes no separate cluster sizing | kubeadm: compatible Linux host with glibc, 2 GB+ RAM per machine, 2+ CPUs for control-plane machines |
| Control Plane & HA | Manager nodes run Raft; odd number recommended: 3 tolerate 1 failure, 5 tolerate 2, 7 tolerate 3; managers need static IPs | API server, scheduler, controller manager, etcd; HA with stacked etcd or an external etcd cluster |
| Documented Scale Limits | No node or task limits published in Docker's docs; more managers add fault tolerance but slow writes | Up to 5,000 nodes, 110 Pods per node, 150,000 Pods, 300,000 containers (v1.37) |
| App Definition Format | Compose file (legacy version 3) via docker stack deploy; services via docker service create | YAML manifests for API objects (Deployments, Services, Jobs, DaemonSets and more) |
| Networking | Built-in overlay networks with optional encryption; ports 2377/tcp, 7946 tcp/udp, 4789/udp between nodes | Pluggable network plugins; NetworkPolicies when the plugin enforces them |
| Ingress & Load Balancing | Ingress routing mesh on every node for published ports; external load balancer optional | Services, Ingress controllers and Gateway API (custom resources for role-oriented, protocol-aware routing) |
| Service Discovery | Embedded DNS; each service gets a name and a virtual IP (vip) or DNS round robin (dnsrr) | Cluster DNS (CoreDNS) and Services with stable virtual IPs |
| Secrets | Encrypted in transit and at rest in the Raft log; up to 500 KB each; mounted at /run/secrets; swarm services only | Secret objects; stored unencrypted in etcd by default; encryption at rest configurable |
| Autoscaling | None built in; scale manually with docker service scale or replicas; replicated, global and replicated-job modes | HorizontalPodAutoscaler (needs Metrics Server add-on); node autoscaling from providers (DOKS autoscaler free) |
| Rolling Updates & Rollback | Rolling updates with --update-parallelism and --update-delay; update_config and rollback_config in Compose deploy | Deployment RollingUpdate strategy, rollout history and rollback to a previous revision |
| Access Control | Mutual TLS node identity with self-signed or custom root CA; swarm autolock; no user RBAC in Swarm mode itself | RBAC with Roles, ClusterRoles and bindings; namespaces |
| Extensibility | Docker API, volume, network and log-driver plugins; no custom resource API | Custom resources (CRDs), API aggregation, operators, CNI/CRI/CSI interfaces |
| Container Runtime | Docker Engine (containerd underneath) | Any CRI runtime such as containerd or CRI-O; dockershim removed in 1.24 |
| Managed Offerings | No managed Swarm from the clouds whose pricing we read; enterprise route is Mirantis Kubernetes Engine (Swarm, Kubernetes or both) | EKS $0.10/cluster-hour ($0.60 in extended support); GKE $0.10/cluster-hour with $74.40 monthly free credit; DOKS control plane free, HA $40/month |
| Commercial Support | Community for Docker Engine; Mirantis OpsCare 24x7 support for enterprise Swarm (prices by quote) | Cloud providers, distribution vendors and consultancies (e.g. Mirantis Kubernetes Engine) |
| Release & Support Cadence | Ships with Docker Engine releases (29.9.0 8 Oct, 29.9.1 14 Oct, 29.9.2 20 Oct, 29.9.3 3 Nov 2026) | Three most recent minors maintained; about 1 year of patch support; patch releases roughly monthly |
| Latest Release (Nov 2026) | Docker Engine 29.9.3 (3 November 2026); 29.10.0-rc.1 (6 November 2026) | v1.37.2 (28 October 2026); v1.38.0-beta.0 (6 November 2026) |
Docker Swarm
Swarm mode is the cluster orchestrator built into Docker Engine (powered by the open-source SwarmKit). It turns a group of Docker hosts into managers and workers, runs services with a desired replica count, and deploys whole application stacks from Compose files, all with the Docker CLI. Not to be confused with the old standalone Docker Classic Swarm, which is no longer developed.
Pros
- Nothing extra to install: any Docker Engine becomes a cluster with docker swarm init and docker swarm join
- Uses the Docker CLI and Compose files teams already know, so the learning curve is days rather than weeks
- Routing mesh: every node accepts connections on a published port and forwards them to a healthy task, with no ingress controller to choose
- Secure defaults: mutual TLS between nodes, Raft-log encryption, secrets encrypted at rest and in transit, optional encrypted overlay networks
- Still maintained: SwarmKit commits in November 2026, Swarm security fixes in Docker Engine 29.9.3, and a dedicated Swarm team at Mirantis
- Small operational surface: one daemon per node, no etcd, CNI plugin or add-ons to keep in version lockstep
Cons
- docker stack deploy only understands the legacy Compose file version 3 format and ignores options such as build
- No built-in autoscaler, custom resource API or operator pattern; functionality is limited to what the Docker API offers
- No per-user RBAC in open-source Swarm mode; anyone with access to a manager's Docker API controls the cluster (RBAC comes with Mirantis Kubernetes Engine)
- Much smaller ecosystem and no managed Swarm service from the major clouds, so fewer tools, charts and hires
Best For
Small teams and solo developers running a handful of nodes (often on VPSs) who already deploy with Docker Compose and want multi-host failover, rolling updates and secrets without running a Kubernetes control plane.
Kubernetes
Portable, extensible, open-source platform for managing containerized workloads and services, with declarative configuration and automation. The first CNCF-hosted project, it schedules Pods across nodes, heals failed workloads, scales them automatically and exposes an API that can be extended with custom resources. Available as upstream (kubeadm), as distributions, and as managed services on every major cloud.
Pros
- Rich workload API: Deployments with rollout history and kubectl rollout undo, Jobs, DaemonSets and more, all declarative YAML
- HorizontalPodAutoscaler scales workloads on metrics, and cluster autoscaling is offered by managed providers
- Extensible: custom resources and operators let databases, certificates and gateways be managed like built-in objects
- Fine-grained access control with RBAC, plus NetworkPolicies for layer 3/4 traffic rules
- Documented scale: v1.37 supports up to 5,000 nodes, 150,000 Pods and 300,000 containers
- Managed control planes everywhere: EKS and GKE at $0.10 per cluster-hour, DigitalOcean's control plane free
Cons
- More moving parts: etcd, API server, scheduler, a CNI plugin, an ingress or Gateway implementation and add-ons like Metrics Server
- Steeper learning curve and more YAML than Compose; small teams spend real time on cluster care
- Secrets are stored unencrypted in etcd by default until you enable encryption at rest
- Fast-moving: only the three newest minor versions are maintained, each for about a year, so upgrades are a recurring job
Best For
Teams running many services or multiple teams on shared clusters, anyone who needs autoscaling, RBAC, operators or Gateway API, and organizations that want a managed control plane from AWS, Google Cloud, DigitalOcean or another provider.
Day one: what it takes to get a cluster running
Swarm's setup is short because there is nothing new to install. Docker's docs describe cluster management as integrated with Docker Engine: run docker swarm init on one host, run the printed docker swarm join command on the others, open ports 2377/tcp, 7946 tcp/udp and 4789/udp between nodes, and you have a cluster. Managers and workers come from the same engine, so a single disk image can build the whole swarm. Kubernetes asks for more. With kubeadm, every machine needs a compatible Linux host with glibc and at least 2 GB of RAM, control-plane machines need two or more CPUs, you install a container runtime that implements CRI (containerd or CRI-O, since dockershim was removed in 1.24), and then you add a network plugin before Pods can talk. A highly available control plane needs a load balancer in front of kube-apiserver and either stacked or external etcd. Managed services remove most of that work, which is why many small teams that choose Kubernetes never run kubeadm at all. Docker Desktop can also start a local single-node (kubeadm) or multi-node (kind) Kubernetes cluster for development. The honest summary: Swarm is an afternoon, self-managed Kubernetes is a project, managed Kubernetes is somewhere in between.
High availability, quorum and scale
The two keep cluster state differently. In Swarm, the manager nodes themselves run the Raft consensus algorithm. Docker recommends an odd number: three managers tolerate one failure, five tolerate two and seven tolerate three, and there is no hard limit, though every extra manager slows writes because more nodes must acknowledge each change. If quorum is lost, existing tasks keep running but you cannot add nodes or start, stop or move tasks until you recover. Managers should have static IP addresses, because a full restart with new manager IPs leaves the swarm unable to find itself. Kubernetes keeps state in etcd, either stacked on the control-plane nodes or as a separate etcd cluster, with the API server behind a load balancer. The other difference is documented scale. Kubernetes v1.37 states support for clusters of up to 5,000 nodes, 110 Pods per node, 150,000 Pods and 300,000 containers. Docker's Swarm docs publish no equivalent limits, so you would be testing your own ceiling. For the clusters most Swarm users run (three to a few dozen nodes), that gap does not matter. For anyone planning hundreds of nodes, Kubernetes is the only one of the two with published numbers.
Deploying apps: Compose stacks vs Kubernetes manifests
Swarm's appeal for Docker users is that a Compose file is nearly a deployment. docker stack deploy takes a Compose file and creates services, networks, secrets and configs across the cluster, and the deploy section adds replicas, placement, resources, restart policy, update_config and rollback_config. The catch, stated in Docker's own docs, is that docker stack deploy uses the legacy Compose file version 3 format; the current Compose specification is not compatible, and options such as build are ignored, so images must be built and pushed to a registry first. Kubernetes uses YAML manifests for each API object: a Deployment for the Pods and its rollout strategy, a Service for a stable virtual IP and DNS name, an Ingress or Gateway API route for HTTP traffic, Secrets and ConfigMaps for configuration. It is more text, but each object is independently versioned, can be rolled back (kubectl rollout undo), and is understood by a large tooling ecosystem. Migration cost runs one way: moving from Swarm to Kubernetes means rewriting every stack as manifests and replacing the routing mesh with an ingress or gateway; moving from Kubernetes to Swarm means giving up autoscaling, RBAC and custom resources.
Networking, secrets and security defaults
Swarm ships opinionated defaults. Every node enforces mutual TLS with the others, using a self-signed or custom root CA. Overlay networks span hosts and can be encrypted. The ingress routing mesh means any node accepts connections on a service's published port, even with no task running locally, and forwards them to an active container, so a simple DNS round robin or external load balancer in front of all nodes is enough. Services get DNS names from an embedded DNS server, with a virtual IP or DNS round robin endpoint mode. Secrets are encrypted in transit and at rest in the replicated Raft log, are limited to 500 KB, and appear inside containers at /run/secrets. Kubernetes is pluggable instead of opinionated. Pod networking comes from a network plugin you choose, NetworkPolicies only work if that plugin enforces them, and HTTP routing comes from an Ingress controller or a Gateway API implementation. Secrets are stored unencrypted in etcd by default, and the docs tell you to enable encryption at rest. In exchange you get RBAC, namespaces and policy controls that Swarm mode does not have; open-source Swarm has no per-user access model, and Mirantis sells RBAC as part of Mirantis Kubernetes Engine.
Cost and the long-term bet in 2026
Both are free, Apache-2.0 software, so cost is mostly people and servers. Swarm has almost no fixed overhead: managers can also run workloads on a small cluster, and there is no separate control plane to pay for. Kubernetes overhead depends on how you run it. Self-managed, you size and patch control-plane machines and etcd yourself. Managed, Amazon EKS charges $0.10 per cluster per hour during the 14 months of standard version support and $0.60 in extended support; GKE charges the same $0.10 per cluster-hour but gives every billing account $74.40 a month in credits, enough for one zonal or Autopilot cluster; DigitalOcean's control plane is free, with an HA control plane at $40 a month. Worker nodes cost the same either way. On longevity, the 2026 evidence says Swarm is maintained rather than growing. SwarmKit had commits in early November 2026, Docker Engine 29.9.3 (3 November 2026) fixed Swarm and SwarmKit vulnerabilities, and Mirantis says it has a dedicated Swarm development team. Kubernetes keeps shipping a new minor version with about a year of patches each, and 1.38 is in beta. Swarm is a safe choice for small, stable deployments; Kubernetes is the safer bet for a growing platform and for hiring.
Verdict
Pick Docker Swarm if you run a few nodes, a small team and apps you already describe in Compose. It is in every Docker Engine, takes minutes to set up, gives you replicas, failover, rolling updates, encrypted secrets and a routing mesh, and needs nothing else to keep upgraded. Run three managers (they tolerate one failure) on static IPs, and accept the limits: legacy Compose v3 for stacks, no autoscaler, no user RBAC and a small ecosystem. Swarm is not abandoned in 2026: Docker Engine still ships Swarm fixes and Mirantis keeps a dedicated team on it. Pick Kubernetes when you need what Swarm does not have: autoscaling, RBAC for several teams, NetworkPolicies, Gateway API, operators for databases and certificates, documented scale to 5,000 nodes, or a managed control plane. If you go Kubernetes on a small budget, a managed service such as DigitalOcean's (free control plane) or a lightweight distribution cuts the operational cost, while EKS and GKE charge $0.10 per cluster-hour (about $73 a month) before worker nodes. If you are unsure, start with Swarm only if the app is small and the team is new to orchestration; if you expect hiring, growth or compliance reviews, start on Kubernetes and avoid a migration later.