Docker Swarm looked like the natural evolution of Docker Compose when it first shipped. Native clustering, simple setup, familiar YAML syntax. Kubernetes arrived from Google with a steeper learning curve and a reputation for complexity. By 2026 the market has spoken—Kubernetes runs most production container workloads—but Swarm still has a place in smaller shops that want clustering without the operational weight of K8s.
I've deployed both in hosting environments. Kubernetes makes sense when you need advanced scheduling, multi-tenant isolation, or a rich ecosystem of operators and controllers. Swarm makes sense when your team already knows Docker CLI, you're running a handful of services, and you want clustering without hiring a full-time platform engineer.
Setup and operational overhead
Docker Swarm ships with Docker Engine. Initialize a cluster:
docker swarm init --advertise-addr 10.0.1.10
Join worker nodes with the token the init command prints. Deploy a stack with a Compose file:
docker stack deploy -c docker-compose.yml myapp
That's it. No separate control plane, no etcd cluster, no CNI plugins to choose from. Swarm reuses the Docker daemon you already run. Upgrades happen when you upgrade Docker Engine. The simplicity is real.
Kubernetes requires more pieces. A control plane runs the API server, scheduler, controller manager, and etcd. Worker nodes run kubelet and a container runtime. You'll pick a CNI for networking (Calico, Cilium, Flannel), decide on an Ingress controller (nginx, Traefik, Envoy), and likely add a storage provisioner. Managed services like GKE, EKS, and AKS hide the control plane, but you still configure the data plane and the ecosystem tooling.
For a three-node Swarm cluster you're looking at an afternoon. For a production Kubernetes cluster on bare metal or VPS instances, plan a few days to handle certificates, RBAC policies, persistent volume claims, and monitoring integrations. Managed K8s cuts that time but locks you into a cloud provider's API surface and billing.
When Swarm's simplicity wins
Small teams running five to twenty services on a handful of nodes often find Swarm easier to reason about. The mental model is Docker Compose plus scheduling. If your team already writes docker run commands and Compose files, Swarm feels like a natural step up. No new CLI to learn—docker service commands map directly to what you already know.
Swarm mode handles secrets and configs as first-class primitives. Rotate a secret:
docker secret create myapp_db_password_v2 ./new_password.txt
docker service update --secret-rm myapp_db_password --secret-add source=myapp_db_password_v2,target=db_password myapp_web
The service restarts with the new secret. No external vault, no sidecar containers, no custom operators.
When Kubernetes complexity pays off
Kubernetes excels when workloads demand fine-grained control. Pod affinity rules let you co-locate services or spread them across failure domains. Taints and tolerations let you dedicate nodes to specific workloads. Custom resource definitions extend the API to manage databases, message queues, and TLS certificates as native Kubernetes objects.
The ecosystem maturity is unmatched. Helm charts package complex applications. Operators automate lifecycle management for stateful services like PostgreSQL, Redis, and Kafka. Service meshes like Istio and Linkerd add observability and traffic management without changing application code. The Cloud Native Computing Foundation hosts hundreds of projects that integrate with Kubernetes APIs.
In support tickets I handled, teams hitting Swarm's limits usually complained about networking or storage. Swarm's overlay network works for most cases but lacks the policy enforcement and observability that Calico or Cilium provide in Kubernetes. Persistent volumes in Swarm rely on plugins that never reached the maturity of Kubernetes CSI drivers.
Scaling and scheduling
Swarm schedules tasks (container instances) across nodes based on resource availability and placement constraints. Scale a service:
docker service scale myapp_web=10
Swarm spreads replicas across healthy nodes. Built-in constraints let you pin services to nodes with specific labels:
services:
web:
image: myapp:latest
deploy:
replicas: 5
placement:
constraints:
- node.labels.region == us-east
That works for basic scheduling. It breaks down when you need advanced policies—like "schedule two replicas per availability zone" or "prefer nodes with SSD but tolerate HDD if necessary." Swarm's scheduling is binary: a constraint matches or it doesn't.
Kubernetes uses a two-phase scheduler. The filtering phase eliminates nodes that can't run the pod (insufficient CPU, wrong labels, taints). The scoring phase ranks remaining nodes by resource balance, affinity rules, and custom priorities. You can write your own scheduler or extend the default one with scheduler plugins.
Horizontal Pod Autoscaler adjusts replica counts based on CPU, memory, or custom metrics:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Swarm has no equivalent. You can write a script that polls docker stats and calls docker service scale, but that's custom glue code you have to maintain.
Rolling updates and rollbacks
Both orchestrators support rolling updates. Swarm:
docker service update --image myapp:v2 myapp_web
Kubernetes:
kubectl set image deployment/myapp myapp=myapp:v2
Swarm updates two tasks at a time by default (configurable with --update-parallelism). Kubernetes updates based on maxSurge and maxUnavailable in the Deployment spec. Both orchestrators pause updates if new tasks or pods fail health checks.
Rollback in Swarm:
docker service rollback myapp_web
Kubernetes keeps a revision history. Roll back to a specific revision:
kubectl rollout undo deployment/myapp --to-revision=3
The Kubernetes history includes the full PodSpec for each revision, making it easier to audit what changed. Swarm's rollback undoes the last update, period.
Networking
Swarm creates an overlay network that spans all nodes in the cluster. Services discover each other by name via an embedded DNS resolver. External traffic reaches services through a routing mesh—publish a port on any node and Swarm routes requests to a healthy task, even if that task runs on a different node.
This works until you need network policies. Swarm has no built-in way to restrict which services can talk to each other. If an attacker compromises one container, they can reach every service in the overlay network. You can isolate stacks with separate overlay networks, but that's manual work.
Kubernetes networking starts with a flat pod network—every pod gets an IP and can reach every other pod by default. Network policies add segmentation:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
CNI plugins like Calico and Cilium enforce these policies at the kernel level with eBPF or iptables. You get microsegmentation without changing application code.
Service meshes add another layer. Linkerd and Istio inject sidecar proxies that encrypt traffic between pods, collect telemetry, and enforce retry/timeout policies. Swarm has no equivalent.
Storage and state
Swarm volumes rely on Docker volume plugins. The built-in local driver works for single-node state. For shared storage you'll install a plugin for NFS, GlusterFS, or a cloud provider's block storage. The plugin ecosystem is thin and many plugins haven't seen updates in years.
Kubernetes uses the Container Storage Interface. CSI drivers exist for every major storage system—AWS EBS, Azure Disk, Google Persistent Disk, Ceph, Portworx, Longhorn. Persistent Volume Claims abstract storage details:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myapp-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: fast-ssd
The cluster provisions a volume from the fast-ssd storage class and binds it to the pod. Resize the PVC and most CSI drivers expand the volume online. Snapshot a PVC and restore it in another namespace for testing.
Operators automate stateful application management. The PostgreSQL operator provisions clusters, handles failover, and schedules backups—all through Kubernetes CRDs. Swarm has nothing comparable.
Ecosystem and tooling
Docker Swarm integrates with Portainer for a web UI. Prometheus scrapes metrics from the Docker daemon. You'll write custom exporters for application-level metrics. Log aggregation typically means shipping container logs to an external system with Fluentd or a sidecar.
Kubernetes has mature observability stacks. The kube-state-metrics service exposes cluster state (pod counts, node status, resource quotas) in Prometheus format. Application metrics come from in-pod Prometheus exporters or OpenTelemetry sidecars. The Loki-Promtail-Grafana stack handles log aggregation. Jaeger and Tempo provide distributed tracing.
CI/CD pipelines treat Kubernetes as a first-class target. Argo CD and Flux implement GitOps workflows—commit a manifest change and the controller syncs it to the cluster. Jenkins, GitLab CI, and GitHub Actions have built-in Kubernetes executors. Swarm requires custom scripts or plugins that shell out to docker stack deploy.
Helm charts package applications with templating and dependency management. The Artifact Hub hosts thousands of charts for databases, monitoring tools, ingress controllers, and business applications. Swarm has no equivalent package manager—you version your Compose files in Git and deploy them manually.
What makes sense for your team
Pick Docker Swarm if you're running a small cluster (under ten nodes), deploying straightforward stateless services, and your team already knows Docker CLI. Swarm's operational simplicity means you spend less time managing the orchestrator and more time shipping features. Security updates happen when you update Docker Engine—one package, one reboot.
Pick Kubernetes if you're managing more than a dozen nodes, running stateful workloads that need advanced scheduling, or building a platform for multiple teams. The ecosystem tooling and operator pattern let you automate operational tasks that would require custom scripts in Swarm. Managed Kubernetes services reduce the setup burden, though they lock you into a vendor's ecosystem.
A few edge cases: if your workloads fit in a single Compose file and you rarely scale beyond five replicas per service, even Swarm might be overkill—stick with Compose on a single VM. If you're migrating from a legacy monolith, Swarm gives you clustering without the cognitive load of learning Kubernetes primitives. If you're building a multi-tenant SaaS or a platform-as-a-service, Kubernetes' RBAC, namespaces, and resource quotas are table stakes.
Common migration patterns
Teams moving from Swarm to Kubernetes often start by converting Compose files to Kubernetes manifests with Kompose. The generated YAML needs manual cleanup—Kompose doesn't understand StatefulSets or network policies—but it's a starting point. Parallel-run both clusters during migration: deploy new services to Kubernetes, leave stable workloads in Swarm until you've validated K8s handles your traffic patterns.
Going the other direction (K8s to Swarm) is rare but happens when teams find they over-engineered. Strip out the Helm charts, reduce the manifests to a Compose file, and lose the custom operators. You'll give up autoscaling and advanced scheduling, but you'll also drop the operational overhead of maintaining a Kubernetes cluster.
Pick based on operational capacity, not hype
Kubernetes dominates the container orchestration conversation, but that doesn't mean it's right for every workload. Swarm's simplicity is a feature, not a limitation, when your team is small and your deployment patterns are straightforward. Kubernetes' complexity pays off when you need the ecosystem maturity, advanced scheduling, or multi-team isolation.
Check your team's capacity to operate and debug the orchestrator. If you can't dedicate time to learning Kubernetes APIs, RBAC policies, and CNI networking, Swarm keeps your containers clustered without the steep ramp-up. If you're already running managed Kubernetes or you have platform engineers on staff, K8s unlocks automation and tooling that Swarm can't match.
The orchestrator should fade into the background so you can focus on the application. Pick the one that does that for your team in 2026.