Every time container orchestration comes up, the conversation almost immediately turns into Kubernetes.
And I understand why.
Kubernetes is powerful. It has a huge ecosystem, strong abstractions, custom resources, operators, service meshes, admission controllers, and almost unlimited extensibility. For large organizations running complex multi-tenant platforms, Kubernetes often makes sense.
But after years of working with Linux infrastructure, backend systems, private and public cloud environments, CI/CD pipelines, monitoring stacks, and production deployments, I learned something that is easy to forget:
The best infrastructure is not always the most powerful one. It is the one your team can operate safely under pressure.
This is where Docker Swarm still deserves respect.
I do not see Docker Swarm as a toy, a legacy fallback, or something only suitable for small demos. I see it as a pragmatic orchestration layer for teams that want production-grade container deployment without turning the orchestrator itself into the main project.
In this article, I want to share how I think about Docker Swarm from a senior engineering perspective: not as a beginner tutorial, but as a practical playbook for architecture, security, deployment, monitoring, and real production trade-offs.
No hello-world examples.
No hype.
Just the things that matter when systems are running at 3 AM and someone has to debug them.
Why I Still Take Docker Swarm Seriously
The biggest advantage of Docker Swarm is not that it has more features than Kubernetes.
It does not.
The advantage is that it gives you enough orchestration with much less operational complexity.
If your team already understands Docker and docker-compose, Swarm feels natural. You can move from a single-machine Compose setup to a multi-node cluster without completely changing the mental model.
That matters.
In production, cognitive load is a real cost. Every abstraction you introduce must be learned, documented, monitored, upgraded, secured, and debugged. A more powerful platform can easily become a liability if the team cannot operate it confidently.
For many real-world backend systems, the requirements are very clear:
- run multiple replicas of an API
- deploy without downtime
- rollback automatically when something fails
- isolate internal services from public traffic
- keep secrets out of images and environment files
- monitor node and container health
- scale horizontally when needed
- keep the architecture understandable
Docker Swarm can handle these requirements well.
The important point is this: Swarm is not a replacement for Kubernetes in every scenario. But it can be the better engineering choice when simplicity, speed, and operational clarity matter more than infinite extensibility.
Docker Swarm vs Kubernetes: My Practical Comparison
I do not like religious technology debates. Most tools are good or bad depending on the context.
So instead of asking, “Which one is better?”, I prefer to ask:
What operational cost am I accepting, and what business or technical capability am I getting in return?
Here is how I usually compare Docker Swarm and Kubernetes.
| Area |
Docker Swarm |
Kubernetes |
| Operational complexity |
Low |
High |
| Learning curve |
Friendly if you know Docker Compose |
Steep, with many new abstractions |
| Control plane |
Built into Docker Engine |
Multiple components and etcd |
| Service discovery |
Built-in DNS and VIP |
Built-in, but with more moving parts |
| Networking |
Overlay networks and routing mesh |
CNI-based networking |
| Extensibility |
Limited |
Very high |
| Ecosystem |
Smaller |
Massive |
| Best fit |
Simple to medium production systems |
Large platforms and complex orchestration needs |
For example, if you need custom operators, advanced autoscaling, complex RBAC policies, admission controllers, multi-tenant platform engineering, or service mesh integration, Kubernetes is usually the stronger choice.
But if your goal is to run backend services, workers, reverse proxies, queues, internal APIs, and scheduled workloads across a small or medium cluster, Swarm may give you a cleaner path with fewer operational surprises.
In my experience, many teams do not fail because their orchestrator lacks features. They fail because their infrastructure becomes too complex for the team operating it.
The Mental Model: Managers, Workers, Services, and Tasks
Before talking about production architecture, it is important to understand the Swarm model.
A Swarm cluster has two main node roles:
-
Manager nodes maintain cluster state and make scheduling decisions.
-
Worker nodes run the actual containers.
In Swarm, you do not usually think in terms of individual containers. You think in terms of services.
A service defines the desired state:
- which image to run
- how many replicas should exist
- which networks it should join
- which secrets it needs
- which constraints control placement
- how updates and rollbacks should happen
Swarm then creates tasks to satisfy that desired state. A task is basically one running instance of a service.
This desired-state model is one of the most important ideas in orchestration. You are no longer manually saying, “Run this container here.” You are saying, “I want five replicas of this service, and I want them to follow these rules.”
The orchestrator continuously tries to make reality match that desired state.
That sounds simple, but it changes how you design deployments.
Raft, Quorum, and Why Manager Count Matters
Manager nodes in Docker Swarm use the Raft consensus algorithm to maintain cluster state.
This is one of the most important production details.
Raft needs quorum. In simple terms, the cluster must have a majority of managers available to make decisions.
The formula is:
quorum = (number_of_managers / 2) + 1
This leads to one very practical rule:
Do not run an even number of manager nodes.
If you run two managers and lose one, the cluster cannot maintain quorum. If a network partition happens, you can end up with an unavailable control plane.
For most production Swarm clusters, I prefer:
-
1 manager for small non-critical environments
-
3 managers for serious production
-
5 managers for larger or more resilient setups
I rarely see a good reason to go beyond five managers. More managers increase coordination overhead and do not automatically make your system better.
Also, managers should be treated carefully. They are not just “normal servers.” They hold the cluster state. If they are overloaded, unstable, or poorly secured, the whole cluster becomes fragile.
My Rule: Managers Manage, Workers Work
One of the first production mistakes I try to avoid is running application workloads on manager nodes.
Yes, Docker Swarm technically allows it.
But in a serious environment, I prefer to drain manager nodes:
docker node update --availability drain <manager-node-name>
This prevents normal application tasks from being scheduled on that manager.
Why?
Because manager nodes are responsible for orchestration, scheduling, cluster state, and Raft communication. If your application has a traffic spike, a memory leak, noisy logs, or heavy CPU usage, you do not want that to compete with the control plane.
A clean separation is easier to reason about:
- managers handle cluster decisions
- workers run application workloads
- edge nodes handle public traffic when needed
- monitoring nodes handle metrics and dashboards when possible
This separation may look boring, but boring infrastructure is usually what you want in production.
Networking: The Part You Must Understand Before Production
Docker Swarm networking is powerful, but you need to understand what it is doing.
Swarm gives you overlay networks. Services attached to the same overlay network can communicate with each other by service name.
For example, your API can connect to Redis using:
instead of hardcoding an IP address.
That is useful because tasks can move between nodes, containers can restart, and IP addresses can change. Service discovery hides that complexity.
But there are two important networking concepts you must understand: VIP mode and DNSRR mode.
VIP Mode and the Routing Mesh
By default, Swarm gives a service a Virtual IP, or VIP.
When another service connects to that VIP, Docker uses internal load balancing to route traffic to one of the active tasks.
This is convenient. It gives you service-level load balancing without installing an external load balancer for internal traffic.
Swarm also has the routing mesh. When you publish a port, traffic can arrive on any node in the cluster and still be routed to a container running somewhere else.
For example:
ports:
- target: 8080
published: 8080
protocol: tcp
With the routing mesh, a request to port 8080 on any node can reach the service.
This is useful, but it also has trade-offs.
The biggest one: preserving the real client IP can become difficult. If you need accurate client IPs for rate limiting, security logs, fraud checks, or WAF rules, you need to be careful.
In those cases, I often prefer publishing ports in host mode at the edge:
ports:
- target: 443
published: 443
protocol: tcp
mode: host
This bypasses the routing mesh for that published port and gives you more predictable network behavior at the cost of less automatic distribution.
In production, I usually prefer a clear edge layer using Nginx, Traefik, or HAProxy instead of exposing many services directly through the routing mesh.
DNSRR Mode: When You Want More Control
VIP mode is simple, but sometimes you want the client or an upstream proxy to see all task IPs directly.
That is where DNS round-robin mode can help.
You can configure endpoint mode like this:
deploy:
endpoint_mode: dnsrr
In this mode, DNS returns multiple task IPs instead of a single VIP.
This can be useful when you have an external load balancer, a custom proxy layer, or a system that needs direct awareness of backend instances.
But I would not use DNSRR everywhere by default. VIP mode is usually simpler. DNSRR is useful when you have a specific reason for it.
That is a general production rule I follow:
Do not choose a more advanced mode just because it exists. Choose it when it solves a real operational problem.
Security: Swarm Gives You Good Primitives, But You Must Use Them Correctly
Security in container orchestration is not one feature. It is a posture.
Docker Swarm gives you useful security primitives:
- mutual TLS between nodes
- encrypted manager communication
- overlay networks
- secrets
- service constraints
- least-exposure networking
But these primitives only help if the architecture uses them properly.
A weak Swarm setup usually has the same problems I see in many weak Docker setups:
- public services attached to internal networks unnecessarily
- secrets stored in
.env files
- manager nodes running random workloads
- no resource limits
- no clear firewall rules
- too many published ports
- no monitoring for abnormal behavior
- no separation between frontend and backend networks
The goal is not to make containers magically secure. The goal is to reduce blast radius.
Use Docker Secrets Instead of Environment Variables
One of the easiest security improvements is to stop passing sensitive values through environment variables.
Environment variables are convenient, but they are not ideal for secrets. They can appear in process inspection, debugging output, crash reports, or accidental logs. They can also be exposed through careless use of docker inspect or application error reporting.
Docker Secrets are a better default.
A secret is mounted inside the container as a file, usually under:
/run/secrets/<secret_name>
For example:
services:
api:
image: my-registry.example.com/backend-api:1.0.0
secrets:
- db_password
environment:
- DB_PASSWORD_FILE=/run/secrets/db_password
secrets:
db_password:
external: true
Then your application reads the password from the file path instead of directly from an environment variable.
This pattern works especially well for Go, Node.js, Python, and PHP services because it is easy to implement a small helper that reads from *_FILE variables.
A simple Node.js example:
import fs from "fs";
function readSecret(path) {
return fs.readFileSync(path, "utf8").trim();
}
const dbPassword = readSecret(process.env.DB_PASSWORD_FILE);
This is not perfect security, but it is a much cleaner baseline.
Encrypt Overlay Networks When Needed
By default, Docker Swarm encrypts control-plane communication between nodes.
But application traffic on overlay networks is not automatically encrypted in every case. If your services communicate across untrusted networks, multiple data centers, or environments where internal traffic should be treated as sensitive, you should consider encrypted overlay networks.
Example:
networks:
backend_net:
driver: overlay
driver_opts:
encrypted: "true"
This enables IPsec encryption for traffic on that overlay network.
There is a performance cost, so I do not enable it blindly for every network in every environment. But for sensitive backend communication, I prefer the overhead over silently passing internal traffic in plain form.
The senior-level decision is not “encrypt everything always.”
The decision is:
Which network paths carry sensitive data, and what is the cost of exposure compared to the cost of encryption?
Network Segmentation: Do Not Put Everything on One Overlay Network
A common mistake is creating one large overlay network and attaching every service to it.
That is easy, but it creates unnecessary reachability.
I prefer separating networks by trust boundary.
Example:
networks:
edge_net:
driver: overlay
app_net:
driver: overlay
data_net:
driver: overlay
driver_opts:
encrypted: "true"
Then services are attached only where needed:
- reverse proxy joins
edge_net and app_net
- API joins
app_net and data_net
- database joins only
data_net
- monitoring joins only monitoring-related networks
This is simple, but it makes lateral movement harder and reduces accidental exposure.
In production, “can this service reach that service?” should have a deliberate answer.
Resource Limits Are Not Optional
Containers without resource limits are a production risk.
A memory leak, CPU-heavy request, bad loop, or unexpected traffic pattern can damage the entire node.
In Swarm stacks, I like to define both reservations and limits:
deploy:
resources:
reservations:
cpus: "0.25"
memory: 256M
limits:
cpus: "1.0"
memory: 768M
Reservations help the scheduler make better placement decisions.
Limits protect the node from a noisy container.
You need to tune these numbers based on real metrics, not guesses. But having no limits at all is usually worse than starting with conservative values and adjusting later.
Placement Constraints: Treat Nodes as Different Classes
Not every node should run every workload.
In real infrastructure, nodes often have different purposes:
- public edge nodes
- backend worker nodes
- storage-heavy nodes
- GPU nodes
- monitoring nodes
- nodes in different availability zones
Docker Swarm supports node labels and placement constraints.
Example:
docker node update --label-add zone=dmz worker-01
docker node update --label-add workload=backend worker-02
docker node update --label-add storage=fast worker-03
Then in your stack:
deploy:
placement:
constraints:
- node.role == worker
- node.labels.workload == backend
This gives you a clean way to express infrastructure intent.
For example, I may want:
- Nginx or Traefik only on edge nodes
- APIs only on backend workers
- databases only on storage nodes
- internal tools never on public-facing nodes
This is one of those features that looks small but becomes very important as the cluster grows.
Zero-Downtime Deployment Strategy
A production deployment should not be “stop old containers, start new containers, hope everything works.”
Swarm gives you rolling update controls.
A good baseline looks like this:
deploy:
update_config:
parallelism: 1
delay: 10s
order: start-first
failure_action: rollback
rollback_config:
parallelism: 1
delay: 5s
order: stop-first
The most important setting here is often:
This tells Swarm to start the new task before stopping the old one. For APIs and web services, this helps reduce downtime during deployments.
But this only works well if your application is ready for it.
That means:
- the app must start reliably
- health checks must be meaningful
- migrations must be backward-compatible
- old and new versions may run at the same time briefly
- the service must handle graceful shutdown
The orchestrator can help with deployment, but it cannot fix bad application lifecycle design.
Health Checks: Do Not Fake Them
A weak health check is worse than no health check because it creates false confidence.
I do not like health checks that only confirm the process is alive.
For example, this is weak:
returning 200 OK no matter what.
A better health check should answer:
Can this instance actually serve traffic?
Depending on the service, that may include checking:
- HTTP server readiness
- database connection
- Redis connection
- required config loaded
- dependency availability
- migration state
But be careful: a health check should not become too expensive. If every health check runs a heavy database query every few seconds, the health check becomes part of the problem.
A practical pattern is separating liveness and readiness:
-
liveness: is the process alive?
-
readiness: is the service ready to receive traffic?
In many Swarm setups, you implement this at the application and reverse-proxy layer, even if Swarm’s health check support is simpler than Kubernetes.
Example:
healthcheck:
test: ["CMD", "wget", "-qO-", "http://localhost:8080/health"]
interval: 10s
timeout: 3s
retries: 3
start_period: 20s
The real work is not adding this YAML. The real work is making /health meaningful.
A Production-Ready Stack Example
Here is a practical Swarm stack example with edge routing, backend isolation, secrets, placement constraints, update strategy, and resource controls.
version: "3.8"
services:
reverse_proxy:
image: nginx:1.25-alpine
ports:
- target: 443
published: 443
protocol: tcp
mode: host
networks:
- edge_net
- app_net
configs:
- source: nginx_conf
target: /etc/nginx/nginx.conf
deploy:
mode: global
placement:
constraints:
- node.role == worker
- node.labels.zone == dmz
resources:
reservations:
cpus: "0.10"
memory: 128M
limits:
cpus: "0.50"
memory: 256M
update_config:
parallelism: 1
delay: 5s
order: start-first
failure_action: rollback
api:
image: registry.example.com/company/api:v2.4.1
networks:
- app_net
- data_net
secrets:
- db_password
- jwt_private_key
environment:
- NODE_ENV=production
- PORT=8080
- DB_HOST=postgres
- DB_PASSWORD_FILE=/run/secrets/db_password
- JWT_PRIVATE_KEY_FILE=/run/secrets/jwt_private_key
healthcheck:
test: ["CMD", "wget", "-qO-", "http://localhost:8080/health"]
interval: 10s
timeout: 3s
retries: 3
start_period: 20s
deploy:
replicas: 6
placement:
constraints:
- node.role == worker
- node.labels.workload == backend
resources:
reservations:
cpus: "0.25"
memory: 256M
limits:
cpus: "1.00"
memory: 768M
update_config:
parallelism: 2
delay: 10s
order: start-first
failure_action: rollback
rollback_config:
parallelism: 1
delay: 5s
worker:
image: registry.example.com/company/worker:v2.4.1
networks:
- data_net
secrets:
- db_password
environment:
- QUEUE_NAME=default
- DB_PASSWORD_FILE=/run/secrets/db_password
deploy:
replicas: 3
placement:
constraints:
- node.role == worker
- node.labels.workload == backend
resources:
reservations:
cpus: "0.25"
memory: 256M
limits:
cpus: "1.50"
memory: 1024M
update_config:
parallelism: 1
delay: 15s
order: stop-first
failure_action: rollback
networks:
edge_net:
driver: overlay
app_net:
driver: overlay
data_net:
driver: overlay
driver_opts:
encrypted: "true"
secrets:
db_password:
external: true
jwt_private_key:
external: true
configs:
nginx_conf:
external: true
This is not a copy-paste solution for every company. But it shows the mindset:
- edge traffic is separated
- backend traffic is internal
- sensitive network traffic is encrypted
- secrets are mounted as files
- managers are avoided for workloads
- resources are controlled
- deployments have rollback behavior
- public ports are minimized
That is the difference between “it runs” and “I can operate this under stress.”
Observability: What I Monitor in Swarm
You cannot run production infrastructure with hope as your monitoring strategy.
For Docker Swarm, I usually think about observability at four levels:
- Node-level metrics
- Container-level metrics
- Service-level behavior
- Application-level signals
A common stack is:
- Prometheus
- Grafana
- Node Exporter
- cAdvisor
- Loki or another log aggregation system
- Alertmanager
Node Exporter gives host metrics:
- CPU
- memory
- disk usage
- disk I/O
- filesystem pressure
- network traffic
cAdvisor gives container metrics:
- container CPU usage
- memory usage
- restart patterns
- throttling
- network traffic per container
Prometheus scrapes metrics, Grafana visualizes them, and Alertmanager handles notifications.
A minimal global cAdvisor service can look like this:
services:
cadvisor:
image: gcr.io/cadvisor/cadvisor:v0.49.1
volumes:
- /:/rootfs:ro
- /var/run:/var/run:rw
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
networks:
- monitoring
deploy:
mode: global
resources:
reservations:
memory: 64M
limits:
memory: 256M
And Node Exporter:
services:
node_exporter:
image: prom/node-exporter:v1.7.0
command:
- "--path.rootfs=/host"
volumes:
- "/:/host:ro,rslave"
networks:
- monitoring
deploy:
mode: global
For service discovery inside Swarm, I like using the tasks.<service_name> DNS pattern.
For example, Prometheus can resolve:
and discover all running cAdvisor tasks.
This is simple and works well without introducing another service discovery system.
The Alerts I Actually Care About
Dashboards are useful, but alerts are what wake people up.
I try to avoid noisy alerts. A noisy alerting system becomes background noise and people stop trusting it.
For Swarm, I care about alerts like:
- manager node down
- quorum risk
- worker node down
- high memory pressure
- disk usage above threshold
- container restart loop
- service replica count below desired state
- high 5xx rate from the reverse proxy
- high latency on critical APIs
- certificate expiration approaching
- unusual increase in blocked or suspicious requests
The important thing is to connect infrastructure signals with application signals.
For example, high CPU alone may not be urgent. But high CPU plus increased latency plus replica restarts is a real incident.
This is where senior engineering judgment matters. Monitoring is not about collecting everything. It is about knowing which signals explain user impact.
Logging: Centralize It Early
On a single server, docker logs is fine.
In a cluster, it is not enough.
Once a service has replicas across several nodes, manual log inspection becomes painful. You need centralized logs.
I prefer to standardize logs as structured JSON where possible.
A good application log should include:
- timestamp
- request ID or correlation ID
- service name
- environment
- log level
- route or operation name
- latency
- user or tenant ID when appropriate
- error code
- upstream dependency name
For the infrastructure side, reverse proxy logs are extremely valuable. They show:
- real client IP
- request path
- status code
- upstream response time
- user agent
- TLS details
- blocked paths
- suspicious probing attempts
This is especially important for public APIs because a lot of malicious traffic starts with boring-looking HTTP requests.
Backup and Disaster Recovery: Do Not Ignore the Managers
People often think about database backups but forget about orchestrator state.
In Docker Swarm, manager state matters.
You should have a recovery plan for:
- losing a worker node
- losing a manager node
- losing quorum
- rotating join tokens
- restoring service definitions
- restoring secrets/configs
- rebuilding the cluster from infrastructure code
I do not like relying only on manual server state. I prefer keeping stack files, Nginx configs, Prometheus configs, deployment scripts, and infrastructure notes in Git.
That way, if the cluster has to be rebuilt, the knowledge is not trapped inside one engineer’s terminal history.
For manager backups, you need to understand your Docker version and operational procedure carefully. The key point is not to improvise disaster recovery during the disaster.
Test the recovery path before you need it.
CI/CD: Keep Deployments Predictable
A simple Swarm deployment pipeline can be very effective.
A common flow:
- Build the Docker image.
- Tag it with a commit SHA or version.
- Push it to a registry.
- SSH into a manager or use a controlled deployment runner.
- Run
docker stack deploy with the updated image.
- Verify service state.
- Check health and logs.
- Roll back if needed.
Example:
docker stack deploy
--with-registry-auth
-c docker-compose.prod.yml
my_app
I strongly prefer immutable image tags for production deployments.
Avoid this:
Prefer this:
my-api:2026-05-23-a1b2c3d
or:
When something breaks, you need to know exactly what is running.
latest is convenient until you are debugging an incident and cannot prove which code is actually deployed.
Database Migrations: The Dangerous Part of Zero-Downtime Deployments
Orchestrators make it easy to roll out new containers.
They do not automatically make database changes safe.
This is where many “zero-downtime” strategies fail.
The safe pattern is usually expand-and-contract:
- Add new schema changes in a backward-compatible way.
- Deploy application code that can work with both old and new schema.
- Backfill data if needed.
- Switch reads/writes to the new structure.
- Remove old columns or tables later.
Avoid deployments where the new application requires a schema change that immediately breaks the old version.
During rolling updates, old and new containers may run at the same time. Your database design must tolerate that.
This is not a Docker Swarm problem. This is a distributed systems deployment problem.
When I Would Not Use Docker Swarm
I like Docker Swarm, but I would not use it everywhere.
I would probably choose Kubernetes if I needed:
- custom operators
- advanced autoscaling patterns
- strong multi-tenancy
- complex RBAC and policy enforcement
- service mesh as a core requirement
- a large platform team
- advanced ecosystem integrations
- cloud-native managed control plane support
I would also avoid Swarm if the organization already has a mature Kubernetes platform and the team knows how to operate it well.
Technology choice should respect organizational reality.
A simple tool in the wrong organization can still fail. A complex tool in a mature organization can work beautifully.
When I Would Choose Docker Swarm
I would choose Docker Swarm when the system needs:
- simple multi-node orchestration
- predictable deployments
- low operational overhead
- easy onboarding for Docker-experienced engineers
- internal APIs and workers
- small to medium clusters
- strong enough orchestration without platform engineering complexity
- fast recovery and simple mental models
For many backend teams, this is enough.
And “enough” is underrated.
In engineering, the goal is not to maximize architecture complexity. The goal is to deliver reliable systems that the team can understand, secure, monitor, and improve.
My Final Production Checklist
If I were reviewing a Docker Swarm setup before production, I would ask these questions:
- Do we have 3 or 5 managers for production?
- Are manager nodes drained from application workloads?
- Are public ports minimized?
- Are edge, app, data, and monitoring networks separated?
- Are sensitive overlay networks encrypted where needed?
- Are secrets stored with Docker Secrets instead of
.env files?
- Do services have CPU and memory limits?
- Do critical services have health checks?
- Do deployments use rolling updates and rollback behavior?
- Are image tags immutable?
- Are logs centralized?
- Are metrics collected from nodes and containers?
- Are alerts meaningful and not noisy?
- Is there a documented recovery plan?
- Can a new engineer understand the architecture without reading 50 pages of hidden tribal knowledge?
That last question matters more than people think.
If the infrastructure only works because one person remembers every command, it is not production-ready. It is a personal project running on production servers.
Final Thoughts
Docker Swarm is not the loudest technology in the room anymore.
But that does not make it useless.
For the right team and the right workload, it is still a clean, stable, and practical way to run containers in production. It gives you orchestration, service discovery, rolling updates, secrets, overlay networks, and scheduling without forcing you to adopt the full complexity of Kubernetes.
My general philosophy is simple:
Keep infrastructure as simple as possible, but never simpler than production requires.
Docker Swarm fits that philosophy well.
It is not about avoiding Kubernetes because Kubernetes is bad. It is about choosing the smallest reliable system that can do the job.
And in many real production environments, that is exactly the kind of decision that keeps systems stable, teams productive, and pagers quiet.
