Cluster Limitations & Gotchas
Docker Swarm clusters provide horizontal scaling and high availability, but they come with trade-offs compared to standalone deployments. Understanding these limitations will help you plan your architecture correctly.
Key Limitations
Persistent Volumes Not Supported
Volumes are not available for applications deployed to clusters. Docker Swarm does not support shared persistent volumes across nodes natively.
Impact: Applications that rely on local file storage (e.g., user uploads saved to disk, SQLite databases) will not work correctly in a cluster.
Workaround: Use object storage (S3, DigitalOcean Spaces, etc.) for file uploads, and a managed database for persistent data.
Databases Must Run on Standalone Servers
Databases provisioned through Appliku (PostgreSQL, Redis, RabbitMQ, etc.) can only be deployed on standalone servers, not inside a cluster.
Impact: You need at least one standalone server in addition to your cluster nodes for database hosting.
Recommended setup:
Standalone Server 1 --> Databases (PostgreSQL, Redis)
Standalone Server 2 --> Build server
Cluster Leader --> Swarm manager + Nginx load balancer
Cluster Worker(s) --> Application containers
While you can use the cluster leader as a build server, this is not recommended for production. Build processes consume significant CPU and RAM, which can affect cluster management operations.
One-Off Commands Run on Leader Only
Release phase commands (e.g., python manage.py migrate) and commands run from the dashboard's "Run Command" feature execute on the leader node only, not on worker nodes.
Impact: If the leader node has limited resources, long-running commands may affect cluster operations.
Container Registry Required
A container registry is mandatory for cluster deployments. There is no way to deploy to a cluster without one.
Architecture Consistency
All servers in a cluster should have the same CPU architecture (either all x86_64 or all arm64). Mixing architectures causes image incompatibility issues.
| Architecture | Supported OS |
|---|---|
| x86_64 (amd64) | Ubuntu 22.04, Ubuntu 24.04, Debian 12 |
| arm64 (aarch64) | Ubuntu 22.04, Ubuntu 24.04, Debian 12 |
Do not mix x86_64 and arm64 servers in the same cluster. Docker images built for one architecture will not run on the other.
Feature Comparison: Standalone vs. Cluster
| Feature | Standalone | Cluster |
|---|---|---|
| Persistent volumes | Yes | No |
| Database hosting | Yes | No (use standalone server) |
| Process scaling | On/Off | N replicas |
| Container registry | Not needed | Required |
| Multi-server | No (single server) | Yes (multiple nodes) |
| Node failure recovery | Manual | Automatic (Swarm rescheduling) |
| One-off commands | Run on same server | Run on leader node only |
| Cron jobs | Yes | Yes |
| Custom domains | Yes | Yes |
| Build location | Same server | Dedicated build server |
When to Use Standalone vs. Cluster
Use standalone when:
- Your application fits on a single server
- You need persistent volumes for file storage
- You want the simplest setup with the fewest moving parts
- You are on the Free or Hobby plan
Use a cluster when:
- You need horizontal scaling across multiple servers
- You want automatic failover and high availability
- Your traffic exceeds what a single server can handle
- You want multi-cloud or multi-region deployments
Next Steps
- Clusters Overview -- How Docker Swarm works in Appliku
- Setting Up a Cluster -- Step-by-step cluster creation
- Scaling in Clusters -- Configure process replicas