Docker Swarm Cluster Requirements: Managers, Quorum, Workers and the Monthly Cost

Docker Swarm's requirements are not about gigabytes; they are about counting. The swarm administration guide, checked on 1 November 2026, is specific about how many manager nodes to run, how many failures a given count survives and where to place them, and that arithmetic decides the shape of a production swarm more than any hardware figure. This guide reads it and prices three layouts of the Docker Swarm package on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic).

What Docker says about managers

Managers hold the swarm's state in a Raft log, and Raft needs a majority, the quorum, to agree on any change. The admin guide puts it as a formula: a swarm with N managers tolerates up to (N-1)/2 permanent failures, so three managers tolerate one, five tolerate two, seven tolerate three and nine tolerate four. It recommends an odd number "because the next even number does not make the quorum easier to keep": four managers still tolerate only one failure, like three. There is no hard limit on manager count, but more managers slow writes, since more nodes must acknowledge each change, and the guide's advice for multi-manager swarms is always more than two.

Placement matters as much as count: the guide advises distributing managers across a minimum of three availability zones so the loss of a zone does not cost the quorum, with splits such as 1-1-1 for three managers and 3-3-3 for nine. And while managers act as workers by default, the guide calls that acceptable only for small non-critical swarms with resource constraints on services, and recommends draining managers (docker node update --availability drain) on larger swarms so nothing starves Raft.

Workers are the capacity

Everything else is workers, and they are sized exactly like a Docker host: the memory and CPU the containers reserve and limit, plus the engine's own overhead, which is small. Docker Swarm places tasks by the reservations you declare in the stack file; a service with no reservation can land anywhere and a service with no limit can take a node down, so declare both. The Compose-to-Swarm post shows a twelve-service stack file with reservations set, and the Swarm or Kubernetes post is the decision guide for teams who are not sure which orchestrator they need.

The three configurations on PaaS and their cost

The Docker Swarm package installs manager and worker nodes with auto-clustering, overlay networking and the routing mesh. Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour, $2.46 per cloudlet-month, with no orchestration fee.

The Starter row is a single manager, which the guide's arithmetic says tolerates no failure: fine for development, not for production. Standard and Production follow the three-manager rule and keep the managers small and drained, because a manager's job is Raft, not containers. The figures are ceilings for always-on swarms before volume discounts; the PaaS pricing calculator prices five managers or more workers.

Three zones on a platform with four regions

The guide's three-availability-zone advice is a strong recommendation for anything the business depends on. On the platform, nodes of one environment live in one region on separate physical hosts under anti-affinity rules, which protects the quorum from a single host failure; a swarm whose managers must survive a regional loss is spread across environments in two or three of New York, London, Frankfurt and Singapore, with the overlay network over the platform's internal links. The Raft write latency between continents is real, which is the trade the guide describes when it says more managers slow writes; most teams keep managers in one region and put the disaster-recovery copy elsewhere.

Scaling and the day-two work

Workers are the layer that scales. A trigger on worker CPU or memory adds a node that joins the swarm with the stored join token, and the routing mesh starts sending it traffic without any configuration; a cooldown removes it later, billed only for its hours. Managers should not autoscale, because quorum arithmetic does not like a changing N; add managers deliberately and in odd steps. Backups are the Raft state on the managers, which docker swarm keeps in /var/lib/docker/swarm, plus whatever volumes your services write; the Backup Storage package holds both. The three-manager SaaS post runs through a year of operating one.

Frequently Asked Questions

How many manager nodes does a Docker Swarm need?

Docker's admin guide, checked on 1 November 2026, recommends an odd number: a swarm with N managers tolerates (N-1)/2 failures, so three tolerate one and five tolerate two, and the next even number gains nothing. Production swarms should run at least three, spread over three zones where possible; the Standard and Production configurations on MassiveGRID PaaS do.

Should managers run containers?

Docker's guide says managers act as workers by default and that this is acceptable only for small, non-critical swarms with resource limits on services; larger swarms should drain managers so nothing competes with Raft. The package's Standard and Production layouts keep managers small for that reason.

What does a Docker Swarm cost per month?

About $59.04 for a single-manager development swarm, $177.12 for three managers and three 2 GiB workers, and $373.92 for three managers and four 4 GiB workers on MassiveGRID PaaS, at $0.003372 per cloudlet-hour before volume discounts. There is no orchestration fee; worker nodes added by a trigger are billed for their hours.