Docker Swarm

Docker Swarm is Docker's built-in multi-host orchestrator: docker swarm init turns a set of Docker hosts into one cluster you drive with the same CLI you already know. It schedules services across nodes, wires them together over overlay networks — the multi-host extension of the overlay driver from Chapter 7 — and ships secrets to containers, all without installing anything beyond Docker.

It is simpler than Kubernetes and largely superseded by it, and the honest framing matters more than the feature list. Swarm is the lowest-friction step past one host for a team already all-in on Docker — and, for most teams in 2025, also a path the wider ecosystem has stopped walking.

From Single Host to Cluster

docker swarm init on one node and docker swarm join on the others forms a cluster of managers — which keep cluster state via Raft consensus — and workers that run the tasks. The same docker CLI now schedules across all of them. For a team that already lives in the Docker CLI, that is the single shortest move from one machine to several, with no new tool to learn.

$ docker swarm init --advertise-addr 10.0.0.1
# prints a `docker swarm join --token ...` line to run on each worker

$ docker network create -d overlay driftwood-net
$ docker secret create db_password ./db_password.txt

$ docker service create \
    --name driftwood-web \
    --replicas 3 \
    --network driftwood-net \
    --secret db_password \
    registry.driftwood.example/driftwood/web:1.4.0

$ docker service ls

That one service create declares desired state — three replicas of driftwood/web on the overlay network, with a secret mounted at runtime — and Swarm keeps it true, rescheduling tasks onto surviving nodes if one dies. No docker run loop, no manual placement.

Services and Desired State

Instead of docker run, you declare a service with a replica count, and Swarm keeps that many tasks running, rescheduling them if a node fails. This is declarative desired-state scheduling — the same idea Kubernetes is built on — scoped to Swarm's smaller feature set. You state what should be true; the scheduler works to make it so, rather than you issuing imperative start and stop commands per container.

Overlay Networks Across Hosts

Swarm extends the overlay network driver so a service on node A reaches a service on node B by name, with built-in load balancing through a routing mesh. This is the concrete payoff of the overlay concept introduced as single-host plumbing in Chapter 7: the same VXLAN-based encapsulation, now spanning the cluster and resolving service names to a virtual IP that load-balances across the live replicas.

Secrets and Configs, Built In

docker secret and docker config distribute sensitive files and configuration to the tasks that need them, mounted in at runtime — the multi-host version of the Compose and runtime secrets from Chapter 10, with no external system to stand up. The secret is encrypted in the Raft store and delivered only to nodes running a task that requested it, never baked into the service image.

The Honest Take — When (and When Not)

Swarm is genuinely simpler than Kubernetes and reasonable for a small cluster run by a team already on Docker Compose. But the ecosystem, the momentum, and the hiring pool have moved to Kubernetes. The operators, managed offerings, and tooling teams want to adopt increasingly target Kubernetes alone.

Choose Swarm only when its simplicity is the deciding factor and you accept being on a path most tooling no longer targets. For anything that will grow, needs broad integration, or has to be staffed long-term, starting on Kubernetes is the call — which is exactly the boundary the next topic crosses and names.