Docker Swarm is Docker's native clustering and orchestration mode. It turns a group of Docker hosts into a single virtual cluster and schedules containers (called services) across them, with built-in load balancing, scaling, and rolling updates. Its appeal is simplicity - if you already know Docker and Docker Compose, Swarm is a small step up - but Kubernetes has become the industry standard, and Swarm's momentum has faded.

How it works

You initialize a swarm, join nodes as managers (which run the Raft-based control plane) or workers (which run containers), and deploy services defined much like a Compose file. Swarm keeps the declared number of replicas running, spreads them across nodes, provides an internal DNS and routing mesh so any node can receive traffic for a service, and performs rolling updates with rollback.

docker swarm init
docker service create --name web --replicas 5 -p 80:80 nginx
docker service scale web=8
docker stack deploy -c docker-compose.yml myapp   # deploy a multi-service stack

Swarm vs Kubernetes

Swarm is far simpler to set up and operate and reuses Compose-style definitions, which makes it attractive for small teams and modest clusters. Kubernetes is more complex but vastly more capable - richer scheduling, autoscaling, a huge ecosystem of operators and tooling, and near-universal cloud support. The industry consolidated on Kubernetes, so community activity, hiring, managed services, and third-party integrations all favor it. Swarm still works and ships with Docker, but new projects rarely choose it, and many that did have migrated.

Where it fits

• Small deployments where Kubernetes' complexity isn't justified and the team wants to stay close to Docker/Compose.
• Existing Swarm clusters under maintenance.

For anything expected to grow, or that needs the broader cloud-native ecosystem, Kubernetes is the safer long-term choice - or a managed Kubernetes service to avoid operating the control plane.