Docker SWARM cheatsheet

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Docker SWARM cheatsheet

Docker Swarm Cheatsheet summarizes common commands for working with a Swarm cluster, its nodes, services, and tasks. A service describes desired state, while tasks represent individual scheduled container instances. Manager and worker roles affect which operations are available, and the cluster may act to restore desired state after an individual task changes. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Identify whether the task concerns a node, service, stack, or task, then use the relevant inspection example.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

docker service ls

A listing of Swarm services in the selected cluster context

The service view describes desired workloads at cluster level rather than only containers on one host.

Desired state differs from an individual task

A Swarm service describes how many replicas and what configuration should exist. Tasks are scheduled instances used to satisfy that desired state. If one task exits, the orchestrator may replace it, so manually manipulating a container is not the same as changing the service definition. Inspect the service and task history together to understand repeated failures. A running task count alone does not establish application readiness or successful traffic routing.

Cluster operations affect more than one host

Manager operations can change scheduling, availability, and deployment state across nodes. Verify the cluster context, node roles, and service targets before changing replicas or node availability. A command's syntax may be short while its operational effect is broad. Keep the application's data placement and network requirements in mind when interpreting scheduling behavior. Use the reference to locate an inspection command, then read the actual cluster's status and events before deciding on a change.

When this tool is useful

• Review Swarm service status commands
• Understand tasks versus services
• Locate cluster inspection syntax

Tips for a better result

• Check the Docker context, node roles, desired replicas, and task status together when diagnosing a service issue.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions