Docker Swarm setup: container orchestration without Kubernetes

Docker Swarm: what breaks with manual container management

When services are brought up manually, each launch is docker run over SSH or docker compose up on a specific machine.

Restart policies are not set everywhere, so a crashed process simply stays down: the container is in the list, the port is being listened on by someone else or by no one, and you learn about it from user reports rather than from monitoring.

At the same time, inventory is lost — which service lives on which node and which image revision is running is remembered only by the engineer who launched it.

An update in such a scheme always brings down the entire service: the old container is stopped, the new one is brought up, and between these two steps the service is unavailable.

Rollback is also manual — restore the previous image tag and repeat the same sequence, with the same downtime window. The more replicas, the longer the pause, and the higher the chance that the new version will not come up at all.

A node failure hits the entire service at once if replicas are not spread out and there is no mechanism that moves tasks to live machines. Recovery comes down to someone logging into the surviving servers and starting the containers again, manually and from memory.

No one sees node state in this case: there is no single picture of what is placed where, how many resources are free, and which tasks failed to start.

Docker Swarm provides exactly the primitives that are missing with manual container management — a declarative service description, a specified number of replicas, restart of failed tasks, and moving them from a failed node.

Below we look at how this is addressed in practice: what is configured before the first docker stack deploy, where the bottlenecks are, and how an update proceeds without a downtime window.

What container orchestration provides: the operational effect

A service is described declaratively: how many replicas to keep, what CPU and memory limits are, and how to check liveness. Then the orchestrator maintains this state itself — a crashed container is restarted, and a task from a failed node moves to a free one.

The failure class “the service is down until the on-call engineer notices” disappears from operations entirely.

Recovery time drops from tens of minutes to seconds.

Previously, an alert woke an engineer, who logged into the server and brought the process up by hand; now restart and rescheduling happen automatically, and a liveness check does not let traffic into a container that is not ready yet.

Downtime during scheduled maintenance also goes away: the update rolls out one replica at a time, while the rest continue serving requests.

Cluster fault tolerance rests on a quorum of manager nodes: as long as a majority of them are reachable, service state is preserved and redistributed.

Loss of a worker node does not bring the service down — the load flows to the remaining machines, and a node that comes back joins the cluster without manual actions.

Load on servers becomes predictable: limits and reservations prevent one service from consuming its neighbors’ resources, and placement by labels spreads heavy tasks across different machines.

We build this on Docker Swarm — orchestration does not drag along a separate abstraction layer and is maintained by the same team as the services themselves.

Cluster deployment options: comparison of approaches

The choice between a single server and a cluster is a choice of failure class, not of load size. In Docker Swarm, one node means that a machine shutdown takes down all services until manual intervention, and a kernel update or daemon restart turns into a downtime window.

As soon as continuity requirements appear, the conversation moves to multi-node options — and here it is important to understand in advance who operates the platform.

A self-hosted cluster on your own servers pays off where placement predictability and full access to nodes matter: three manager machines keep quorum if one fails, worker nodes are added under load, and the network between services is built on top of hosts without external intermediaries.

A managed option removes updates and monitoring from the team, but in exchange limits low-level settings — some tasks simply cannot be solved within its framework.

Therefore, we first calculate the load profile and downtime requirements, and then choose the path: moving a single server to a cluster later is cheaper than fixing an architecture chosen for someone else’s operating model.

Implementation procedure: from audit to handover to operations

Implementation is divided into stages, and each has an artifact as its output. This makes the result reproducible and independent of who exactly performed the work: from infrastructure audit to handover to operations.

1. Infrastructure audit — we inventory services, dependencies, data and secret storage points, available nodes, and communication channels. We record bottlenecks: a single node under peak load, manual configuration edits, absence of cluster state backups.
2. Cluster design — we determine the number of manager and worker nodes, quorum, zone distribution, internal networks, and access rules between services. We agree on what exactly must survive a node failure and what must survive a zone failure.
3. Service configuration — we describe services: number of replicas, resource limits, health checks, the order of rolling updates and rollback to the previous version. We keep configurations and secrets outside images so that the environment comes up identically on any node.
4. Fault tolerance testing — we deliberately take nodes out of service, shut down a manager node, break connectivity between zones, and apply peak load. We watch whether replicas recover on their own and how long it takes to return to normal.
5. Team training — we show your engineers routine operations: version rollout, rollback, scaling, reading cluster state, and incident analysis. We hand over runbooks so that typical tasks can be handled without us.
6. Handover to operations — we hand over configurations, the diagram, backup and monitoring policies, and recovery instructions. We go through the first scheduled rollout together with your team and close the work according to a checklist.

What remains with your team: configurations and runbooks

All changes in the cluster remain as files and documents in your repository, not in chat messages or in an engineer’s head.

After handover, you deploy the stack, update services, and roll back without us: each runbook has a command, an expected result, and a sign by which it is clear that something went wrong.

• Configuration files: stack manifests with all services, networks, volumes, and placement labels — deployment with a single command.
• Diagrams: cluster topology, manager and worker roles, traffic entry points, and connections to external state storage.
• Image registry access policies: who publishes tags, which images are considered verified, and how read access from worker nodes is restricted.
• Update and rollback runbook: service rollout order, readiness checks, stop conditions, and return to the previous version without downtime.
• On-call shift instructions: what to look at when a service is unavailable, how to take a node out of rotation, and how to hand over a shift.
• Backup documentation: what exactly is saved and how cluster recovery on a clean site is tested.
• Monitoring map: which metrics and alerts are configured for services, who receives them, and what to react to first.
• Acceptance checklists: a set of checks after a configuration change so that the change does not reach production untested.

Case study: how we reduced downtime of a delivery service after a node failure

The client is a regional delivery service with its own dispatch system: order intake, courier assignment, and tracking. The application lived on two servers, and deployment was done manually according to instructions: stop the service, update files, bring it back up, check logs. Until the engineer finished the checks, some orders were not accepted.

What measurements showed before the transition

A single node failure stopped order intake for 40-50 minutes: the on-call engineer brought the service up by hand, checking the configuration against notes in the repository.

A release took about half an hour of routine steps, and minor discrepancies between servers led to 8-10 manual interventions per week — from editing environment variables to restarting hung processes.

What we changed

We built a cluster on Docker Swarm from three nodes and moved the application into containers with an identical environment description. Roles were distributed so that manager nodes remained in quorum if one of them was lost, while workers carried the load.

Services received a health check and a restart rule: a failed task is rescheduled to a live node without human involvement. We release updates via rolling update — several replicas at a time, with readiness waiting and automatic rollback to the previous image if checks fail. We clean the image registry according to a retention rule for the latest builds.

After the transition, downtime during a node failure decreased to 20-40 seconds — replicas on live nodes take over traffic.

A release takes 3-4 minutes and does not require stopping order intake, and the number of manual interventions dropped to one or two per week: mostly scheduled maintenance.

The time from commit to a working version in the cluster decreased from several hours of waiting for a window to a single release pass.

How Docker Swarm differs from Kubernetes and when it is appropriate

The difference is not which orchestrator is “more powerful,” but the cost of maintenance.

Docker Swarm is part of the containerization engine: a cluster is assembled from several nodes with one command, services are described declaratively (image, number of replicas, placement rules), and manager node state is replicated between them.

Kubernetes is a separate platform with an extensible API model, its own scheduler, and a large set of extensions; it must be installed, updated, and maintained as an independent system.

In practice, this is a difference in roles and operating mode. Swarm handles networking between nodes, zero-downtime service updates, and restart of failed tasks out of the box — one engineer can maintain it, and backup comes down to a snapshot of manager node state.

Kubernetes provides fine-grained placement policies, metric-based autoscaling, and cluster sharing between teams, but in exchange requires component addressing, manifest migration when API versions change, and a permanent platform owner.

Hence the selection criterion. With 3-10 nodes, homogeneous services without local state, and no dedicated platform team, Swarm provides orchestration with built-in tools.

If there is only one service, an orchestrator is not needed at all — a Compose file and a system unit for autostart are enough. Kubernetes is justified where a cluster is shared by several product teams, database operators are needed, and autoscaling for peak load is required.

We start with a service map and load profile: where state lives, how often releases happen, and what downtime is acceptable. Based on this data, it is clear where an orchestrator is excessive and where saving on it will turn into manual on-call duty.

Technical concerns: fault tolerance, updates, rollback

Fault tolerance in Docker Swarm rests on a quorum of manager nodes: as long as a majority of them are present, the cluster preserves state and continues scheduling tasks. Below are answers to the concerns most often raised before launch.

How does an update proceed without downtime?

We roll out by replacing tasks one after another with limited parallelism and a pause between batches: some replicas always remain running and accept traffic.

A health check filters out instances that did not come up — the update pauses on them instead of taking down the whole service.

How to roll back a failed release?

Images are versioned, so rollback is launching the previous version of the service, not rebuilding from source. We configure automatic rollback when checks fail and rehearse the scenario in a staging environment so that rollback takes minutes.

What is included in cluster support after launch?

Monitoring of nodes and services, updating the engine itself, credential rotation, cluster state backups, and incident analysis. Plus scheduled checks: we shut down a node and see how the cluster handles the loss.

Let's discuss the task: what we clarify before starting work

Before estimating the work, we fix the initial data — otherwise the implementation plan is built on assumptions and gets revised halfway through. Below is what we go through in the first conversation so that we can discuss the task concretely and not return to basic questions.

• Where services are hosted: own servers, private cloud, or several sites, and how resilient the connection between them is.
• What downtime requirements exist: whether a short interruption during an update is acceptable or the load must be moved without stopping.
• How data storage is arranged: where databases and state reside, whether replication and backups between nodes are needed.
• How updates are released: how many environments, who triggers the rollout, whether automation of image builds and rollback to the previous version is needed.
• How access is distributed: who manages the cluster, whether an action log and role separation are needed.
• Who maintains the system further: an in-house team or a contractor, and what volume of documentation is needed for handover.
• What already works: the current configuration, past attempts, and windows during which changes can be made.

If there are few services and nodes, we will say directly: complex orchestration does not pay for itself, and a simpler scheme is enough.

The answers remove uncertainty before the start — after the conversation, we return with a work estimate and a stage-by-stage implementation plan that separately states what we do and what is required from your side.