Docker Swarm in 2023: When It Still Makes Sense

Actualizado: 2026-05-03

The popular narrative says Kubernetes won and Docker Swarm is dead. Reality is more nuanced. Swarm remains maintained as part of Docker Engine, works perfectly in production, and for a specific slice of cases remains the right choice — not a legacy option. This guide covers when Swarm makes sense, what costs less to operate, and what limitations you accept in exchange.

Key takeaways

• Swarm is integrated in Docker Engine and receives regular maintenance; it is not an abandoned project.
• For teams of 5-15 people without dedicated SRE, its operational cost is significantly lower than Kubernetes.
• Migration from Docker Compose is the smoothest possible: the same YAML files with the deploy: field added.
• Kubernetes clearly wins for advanced operators, sophisticated autoscaling, and the CNCF ecosystem.
• Self-hosted with 1-5 VPS, Swarm plus Traefik covers 95% of needs at 20% of the cost.

The Real State

Some facts about Docker Swarm’s current state:

• It is integrated in Docker Engine — not a separate project that can be independently abandoned.
• Receives regular maintenance though without flashy new features.
• Mirantis acquired Docker Enterprise in 2019 and maintains the technology — it is not orphaned.
• Has established adoption in small and medium organisations not needing Kubernetes complexity.

What Swarm is not: not the coolest, not what you’ll see at KubeCon talks, lacks Kubernetes’s operator ecosystem, and isn’t an option for large hyperscale.

When Swarm Is the Best Option

Small Teams Without Dedicated SRE

If your dev team has 5-15 people and there’s no dedicated SRE/ops, Swarm costs significantly less to operate:

• Setup in minutes instead of days.
• Limited concepts: services, stacks, secrets, configs, networks. No CRDs, operators, or Helm.
• docker stack deploy -c stack.yml my-app and done.
• Learning curve compatible with knowing Docker Compose.

For a 30-50-person organisation with 3-10 services, Swarm can deliver 95% of the value at 20% of the operational cost.

Self-hosted on VPS

For services on owned VPS of 1-5 nodes, Swarm is the natural tool. Kubernetes at this size is over-engineering — most of its value appears at scale you don’t have. Typical deployments:

• Own and client websites on a few VPSs.
• Self-hosted stacks: Nextcloud, Mailcow, Gitea, Plausible.
• Small companies with their own infrastructure.

Smooth Migration From Docker Compose

If you already use Compose in production (common in small companies), Swarm is the most natural next step. Your docker-compose.yml files work almost unchanged — you just add the deploy: field with replicas, resources, and placement. Migrating to Kubernetes from Compose requires rewriting manifests and learning new concepts. Swarm is continuity.

Edge Computing in Mini-clusters

For 3-10-node edge clusters (remote offices, factories), Swarm is lightweight, simple, and sufficient. Kubernetes at the edge requires specialised distributions like k3s or microk8s that add their own complexity.

When Kubernetes Is Clearly Better

Swarm doesn’t scale to every case. Kubernetes wins when:

• You need advanced operators: PostgreSQL HA, Cassandra, Kafka clusters — Kubernetes has mature operators.
• Strong multi-tenancy with namespaces: Swarm has no real equivalent.
• Sophisticated autoscaling: HPA/VPA, autoscalers based on custom metrics.
• Service mesh, ingress controllers, and mature GitOps: the entire CNCF ecosystem assumes Kubernetes.
• Hire-ability: many more people know Kubernetes.
• Multi-cluster cross-region: Kubernetes with federation; Swarm is single-cluster.

Typical Swarm Stack in Production

Swarm cluster (1 manager + 2 workers, or 3 managers in HA)
   │
   ├── Traefik as proxy/ingress (with automatic Let's Encrypt)
   ├── PostgreSQL/MariaDB as Swarm service with bind volume
   ├── Apps in separate stacks (each client or domain = stack)
   ├── Portainer as management UI
   ├── Prometheus + Grafana + Loki for observability
   ├── Watchtower for auto-update (in monitor mode)
   └── Backups with restic to external object storage

This stack is operable by one person, reasonable to monitor, and covers the vast majority of self-hosting needs.

Essential Commands

For someone coming from Compose:

# Initialise Swarm
docker swarm init --advertise-addr <ip>

# Add worker (token obtained from manager)
docker swarm join --token <token> <manager-ip>:2377

# Deploy stack from docker-compose.yml
docker stack deploy -c stack.yml my-app

# List services
docker service ls

# View service logs
docker service logs my-app_web -f

# Scale a service
docker service scale my-app_web=3

# Update image with rolling update
docker service update --image nginx:1.25 my-app_web

If you know Compose, you already have 70% of Swarm.

Limitations to Accept

If you choose Swarm, you accept:

• Limited ecosystem: Helm, ArgoCD, Backstage — all Kubernetes-only.
• Simpler networking (VXLAN overlay, not CNI with plugins).
• No granular RBAC comparable to Kubernetes.
• Sparse documentation and forum answers compared to Kubernetes.

For cases where these limitations aren’t a problem, they are acceptable trade-offs.

Related: if you need GitOps on Swarm, options are more limited than on Kubernetes — check whether it makes sense to step up to k3s before implementing a complex pipeline. And to install Docker on Debian before configuring the cluster, read how to install Docker on Debian 12.

Conclusion

Docker Swarm is alive and remains the right choice for cases where Kubernetes is over-engineering. Small teams, self-hosted, edge mini-clusters — all scenarios where Swarm’s simplicity and low operational cost are worth more than Kubernetes’s advanced features. The “Swarm is dead” stigma is overblown. The honest question is: do you really need Kubernetes, or do you need something simple that orchestrates containers?