One deployment control plane for Docker Compose services
At NIRA, replaced logging into each server to rebuild and restart services with a single Dokploy instance that deploys every Compose stack from GitHub to its server over SSH.
Problem
Backends, frontends and supporting services ran as Docker Compose stacks spread across several servers and projects. Every update meant logging into the right server, pulling changes, rebuilding images and restarting the stack by hand, with each service's configuration living on its own machine.
Constraints
- Services were already defined as Docker Compose stacks; the change had to work with them as they were, not require rewriting them.
- Projects ran on separate servers that needed to stay where they were.
- Each service had its own environment and deployment steps, so one generic pipeline would not fit them all.
Decisions
- A single Dokploy instance as the control plane
- One place to see and deploy every system, instead of a separate login and routine per server.
- Register existing servers as Dokploy remote servers over SSH
- Workloads stay on the servers they already ran on; Dokploy reaches them over SSH rather than everything moving onto one host.
- Deploy straight from the existing Compose files in GitHub
- Each Dokploy project points at its repository and the path to its docker-compose file, so the stacks did not need to be rewritten for a new tool.
- Manage each service's environment in Dokploy
- Configuration lives with the deployment definition, in one place, rather than in files on individual servers.
Architecture
Source
Application code and docker-compose files for each system live in GitHub repositories.
- GitHub
- Docker Compose
Control plane
One Dokploy instance holds a project per system, with its repository, compose file path and environment.
- Dokploy
Remote servers
Existing servers are registered in Dokploy and reached over SSH.
- SSH
Build and run
A deploy is started manually in Dokploy; it pulls the source and Docker Compose builds the images and restarts the stack on its target server.
- Docker
- Docker Compose
Services
Backends, frontends and supporting services, each deployed and configured from the same place.
Build notes
Before
Each system was a Docker Compose stack on its own server. Updating one meant opening an SSH session to that server, pulling the latest code, rebuilding the images, and bringing the stack back up, then repeating it for the next system. The steps were known, but they lived in people’s heads and shell history rather than in a shared, visible process.
After
A single Dokploy instance became the control plane. The existing servers were added as remote servers over SSH, so services stayed where they were. For each system, a Dokploy project is connected to its GitHub repository and told where its docker-compose file lives. The environment each service needs is set in that project, along with any other steps that service requires.
Deploying is now the same action for every system: start the deployment in Dokploy, and it pulls from GitHub and has Docker Compose build and restart the stack on the right server. Deploys are triggered manually from Dokploy.
Why this approach
The stacks themselves worked; what was missing was a single, repeatable way to deploy and configure them. Dokploy fits that gap because it uses the existing Compose files and servers as they are, so centralizing deployments did not require rewriting services or moving them.
Outcome
Deployments moved from a manual, per-server routine to one control plane. Every system is deployed the same way from its GitHub repository, and each service's configuration is visible and editable in one place instead of being scattered across servers.