This page documents the initialization and configuration of Docker Swarm in single-node production mode.

Snapshot date: 2026-02
Node role: Manager (Leader)
Mode: Single-node swarm

---

1. Initialize Swarm

Initialize the swarm cluster:

sudo docker swarm init

Expected output:

• Node becomes a manager
• Swarm mode: active
• Join token generated

---

2. Verify Swarm Status

Check swarm state:

sudo docker info | grep -i swarm

Expected:

Swarm: active

Check node status:

sudo docker node ls

Expected:

• One node
• Status: Ready
• Availability: Active
• Manager Status: Leader

---

3. Overlay Networks

Swarm requires overlay networks for inter-service communication.

Create public network:

sudo docker network create --driver overlay --attachable web

Create internal network:

sudo docker network create --driver overlay --attachable internal

Network Design

Network	Purpose
web	Public-facing services (Nginx, etc.)
internal	Private service communication (PostgreSQL, MinIO, etc.)

Overlay networks allow:

• Service-to-service DNS resolution
• Isolation between public and private services
• Multi-node scalability (future-ready)

---

4. Verify Networks

sudo docker network ls

Expected to see:

• ingress
• web
• internal

Inspect a network:

sudo docker network inspect web

---

5. Swarm Security Notes

• Only manager nodes can modify cluster state.
• Secrets are encrypted at rest in Swarm.
• Overlay traffic is encrypted by default between nodes.

Single-node considerations:

• No high availability
• Manager and worker run on same host
• Backups are critical

---

6. Swarm Tokens

Retrieve manager join token:

sudo docker swarm join-token manager

Retrieve worker join token:

sudo docker swarm join-token worker

These tokens allow additional nodes to join the cluster.

Store them securely.

---

7. Current Production State

Current node:

sudo docker node ls

Expected state:

• 1 Manager (Leader)
• Status: Ready
• Availability: Active

---

8. Swarm Best Practices

• Never run application containers outside of Swarm
• Always deploy via stack files
• Use Docker secrets for sensitive data
• Separate public and internal networks
• Avoid direct container port exposure unless required