# SwarmKit keeps cluster state in Raft managers with no external database, and its README build note is out of date > moby/swarmkit is an Apache-2.0 Go toolkit for orchestrating distributed systems, built from Raft consensus, mutual TLS, a task scheduler and a swappable executor. It documents its cluster model well and its Go requirement badly. **moby/swarmkit** — A toolkit for orchestrating distributed systems at any scale. It includes primitives for node discovery, raft-based consensus, task scheduling and more. - Repository: https://github.com/moby/swarmkit - Stars: 3,653 · Forks: 678 - Language: Go - License: Apache-2.0 - Published: 2026-10-08 · Updated: 2026-10-30 · Language: en - Canonical page: https://hysenlabs.com/projects/moby-swarmkit ## Managers reconcile desired state, and workers only run tasks Machines running SwarmKit form a Swarm, and each machine that joins becomes a Swarm Node with one of two roles. Worker nodes run tasks through an Executor. A default Docker Container Executor ships in the box and can be swapped out for another. Manager nodes accept specifications from the user and reconcile the desired state with the actual cluster state. An operator can promote a worker to manager or demote a manager to worker while the cluster runs. Tasks are grouped into services, the unit the user actually declares. A service says what type of task to create, how to run it (for example, this many replicas at all times) and how to update it (for example, rolling updates). Two service types ship: replicated services, scaled to the desired replica count, and global services, which run one task on every available node. If a node fails, SwarmKit reschedules its tasks onto a different node, which is the reconciliation loop doing its job. ## Raft keeps the manager state, and no external database is needed Coordination uses the Raft consensus algorithm, and the project states there is no single point of failure for decisions. Manager nodes hold a strongly consistent, replicated view of the cluster with in-memory reads, which is what lets them schedule quickly while tolerating failures. The pitch for operators is simplicity: SwarmKit does not need an external database to operate and minimizes infrastructure dependencies. The go.mod file shows what sits underneath. It requires go.etcd.io/raft/v3 v3.6.0 plus the etcd server and pkg modules at v3.6.5, go.etcd.io/bbolt v1.4.3 for on-disk storage, and github.com/hashicorp/go-memdb v1.3.2. The consensus code is therefore etcd's raft library. The README states the in-memory read speed but gives no cluster size guidance, so check the design/ folder and the docs it links to before choosing a manager count. ## Node identity comes from manager-run CA, join tokens and rotating certificates All nodes talk over mutual TLS, which covers authentication, role authorization and transport encryption. Swarm managers act as the root certificate authority and issue certificates to new nodes, and the dependency list includes github.com/cloudflare/cfssl v1.6.4 for certificate work. A cryptographic token is required to join, and the token decides the new node's role. Tokens can be rotated as often as desired without affecting nodes that already joined. Certificate rotation is automatic and transparent on every node. The user sets how often it happens: the current default is 3 months and the minimum is 30 minutes. There is a fragile spot recorded in go.mod. A comment explains that error handling in the SessionClosed method of firstSessionErrorTracker in node/node.go matches x509 error strings, and gRPC changed the error string between 1.3.0 and 1.7.5, stopped surfacing those errors in 1.10.x, and brought them back with a different string in 1.11 and later. After any gRPC update, that comment tells you to check the string matching when integration tests fail. The module is currently on google.golang.org/grpc v1.79.3. ## Scheduling filters by constraint expressions and then spreads tasks The scheduler knows what resources nodes have and places tasks accordingly. Operators narrow the candidate nodes with constraint expressions. Several constraints combine as an AND, so a node must satisfy every expression. The matchable attributes are node.id, node.hostname, node.ip, node.role, node.platform.os, node.platform.arch, node.labels and engine.labels. Examples from the README are node.role == manager, node.platform.os == linux and node.labels.security == high. The two label families differ in who writes them. engine.labels are collected from Docker Engine, with information such as operating system and drivers. node.labels are added by cluster administrators for operational purposes, for instance to mark nodes that satisfy compliance requirements for certain tasks. Only one placement strategy ships: the spread strategy, which attempts to put tasks on the least loaded nodes that meet the constraints and resource requirements. If you need bin-packing or another policy, the README lists none, so you would write that yourself in the scheduler code. ## Rolling updates start lockstep unless parallelism and delay are set When you change fields on a service, SwarmKit reconciles every task to the new settings. By default it performs a lockstep update, meaning all tasks update at the same time. Two knobs change that. Parallelism defines how many updates can run at once. Delay sets the minimum pause between updates. The order inside one task is spelled out: SwarmKit shuts down the previous task, brings up a new one, waits for the new task to reach the RUNNING state, and only then waits the configured delay before moving on. The previous task is stopped before its replacement starts. Restart policies work alongside. The operator defines restart conditions, delays and a maximum number of attempts in a time window, and SwarmKit can restart a task on a different machine. The README concludes that faulty nodes gradually drain of their tasks. Node availability can also be set to Paused, which stops new tasks from landing, or Drained, which does the same and also moves existing tasks elsewhere, mostly for maintenance. ## The README asks for Go 1.6 while go.mod and the Dockerfile require Go 1.25 The build requirements in the README read: Go 1.6 or higher, a working golang environment, and Protobuf 3.x or higher to regenerate protocol buffer files, for example with make generate. The module file says go 1.25.0, and the Dockerfile sets ARG GO_VERSION=1.25 on a bookworm Debian base, with PROTOC_VERSION=3.14.0 and a pinned golangci-lint of v2.12.2. The two sources disagree, and go.mod is the one the build uses. The module path is github.com/moby/swarmkit/v2, so imports carry the v2 suffix. The Makefile chooses between direct.mk and containerized.mk: setting any non-empty DOCKER_SWARMKIT_USE_CONTAINER runs everything inside a container, and the default avoids containers so it does not break anyone's workflow. The Dockerfile has stages for vendoring and for a protoc-gen-gogoswarm generator, and a vendor-validate stage fails with an error telling you to run make go-mod-vendor when the vendored result differs. The repository also checks in a vendor directory, along with BUILDING.md and CONTRIBUTING.md. ## One release in 2026, and the README links out for everything operational The release list shows v2.1.2 on 2026-04-23 as the recent release. The repository is not archived, and its last push was on 2026-10-16. Code continues to land on master between tags, so pinning to the tag and tracking master give different results. The layout names the subsystems: agent/, ca/, manager/, node/, remotes/, connectionbroker/, volumequeue/, swarmd/ for the daemon, cli/ and cmd/ for commands, api/ and protobuf/ for the gRPC definitions, and integration/ for tests. What is missing is operator documentation. The README has no install or quickstart commands and no section on upgrades or backup of manager state. A pkg.go.dev badge points Go programmers to the API reference for the v2 module. ## Conclusion SwarmKit suits Go developers who want to read or embed a Raft-backed scheduler with mutual TLS, services and a spread strategy, and who accept a single published release in 2026. It is the wrong starting point for anyone after an operator-facing install guide, since the repository points elsewhere for that. Before building, ignore the README's Go 1.6 line and use the Go 1.25 that go.mod and the Dockerfile require. ## FAQ ### Is Docker Swarm still a thing, going by the SwarmKit repository? The moby/swarmkit repository is not archived and was last pushed on 2026-10-16. Its most recent release is v2.1.2, dated 2026-04-23. ### Is SwarmKit the same as Kubernetes? The SwarmKit repository does not compare itself with Kubernetes. It describes itself as a toolkit for orchestrating distributed systems with node discovery, raft-based consensus and task scheduling. ### What is the purpose of SwarmKit and Docker Swarm style clusters? SwarmKit groups machines into a Swarm of manager and worker nodes. Managers reconcile the desired state of services with the actual cluster state, and workers run the tasks. ### Is SwarmKit free to use? SwarmKit is released under the Apache-2.0 license. Its README lists no paid tier. ## Sources - [Issues](https://github.com/moby/swarmkit/issues) - [License: Apache-2.0](https://github.com/moby/swarmkit/blob/master/LICENSE) - [moby/swarmkit on GitHub](https://github.com/moby/swarmkit) - [README](https://github.com/moby/swarmkit/blob/master/README.md) - [Releases](https://github.com/moby/swarmkit/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moby-swarmkit