Category: PaaS and containers
Managed Dokploy: Docker Swarm deployments on your servers
Deployments from Git or with Docker Compose spread across several servers, with someone looking after the Swarm cluster, the backups and the dashboard updates.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Apache 2.0, except its proprietary folder
In short
Dokploy is an open source deployment dashboard that builds on Docker, Docker Swarm and Traefik to publish applications, databases and Docker Compose projects on your servers. We install it in your account, organise the cluster nodes, schedule backups of databases and volumes that we restore in tests, protect the dashboard and keep it up to date.
What do we look after?
Dokploy installs with a single command and in an afternoon you have applications live. What comes afterwards is what gets forgotten: nodes nobody updates, volumes with no backup, a lone Swarm manager and the dashboard open with a shared password. This is what we keep under control:
Dashboard
Dokploy on its own server, with restricted access, two-factor authentication and per-project permissions.
Swarm cluster
Managers and workers with quorum, node labels and constraints so that each service lands where it should.
Deployments
Applications from Git, images and Compose projects with tidy variables and rollback.
Backups
Databases and volumes backed up to S3 in another location, with rehearsed restores.
Traefik
Certificates that renew themselves, domains and security headers.
Alerts
Failed deployments, services without healthy replicas, node disk space and certificates about to expire.
How do we set it up across several servers?
The default installation leaves the dashboard, Traefik and the applications on the same machine. For production with more than one server, we split it like this:
Dashboard server
Runs Dokploy and its internal database. Small and with no public traffic other than access to the dashboard, via VPN or by IP.
Swarm managers
Three manager nodes so that the cluster keeps quorum if one goes down; with only one, losing it leaves the cluster ungoverned.
Workers
The nodes that run the applications, with labels to separate what needs fast disk or more memory.
Data off the nodes
Databases on a pinned node or on the provider’s managed service, and backups to S3 in another account.
Swarm spreads replicas of stateless services very easily. Databases are another story: a local volume does not travel with the container to another node, so we pin them to a specific machine or take them out of the cluster.
Which problems do we come across most often?
- A single manager: if that machine goes down, services keep running, but nothing can be deployed or rescheduled.
- Databases that jump between nodes: Swarm moves the container and it starts with an empty volume on another machine.
- Compose with published ports: databases reachable from the internet because the original file exposed them.
- Backups switched on with no external destination or without a single test restore.
- Disks full of images and container logs on the workers.
- Dashboard on the same machine as the applications and with one user for the whole team.
How do we handle backups and updates?
In Dokploy we configure an S3-compatible destination in another account or with another provider and schedule backups of each database and of the volumes that hold data. Periodically we restore one into a separate service and check that the data is there; the time it takes goes into the report. The dashboard has its own backup, which we keep off the server so that it can be rebuilt on another machine without touching what is already live.
We read dashboard releases before applying them and, when the change is large, we test them first in a staging environment. Docker and the nodes’ operating system are updated node by node: drain, patch, reboot and return to the cluster, so that the replicas keep serving in the meantime.
Who is it for?
- A product team with several applications and APIs that wants to deploy with a push without setting up Kubernetes.
- A company that already works with Docker Compose and needs to go from one server to several without redoing its files.
- Anyone leaving a paid PaaS who wants servers in their own name, with someone accountable for the backups and the cluster.
If you are comparing it with Coolify or planning to move off Heroku or Vercel, we cover that in managed Coolify and Dokploy. If the number of services grows a lot or you need autoscaling, Kubernetes on Hetzner may suit you better.
How do we protect the dashboard and the cluster?
Whoever gets into Dokploy can deploy, read environment variables and delete databases, so the dashboard sits behind a VPN or has IP-restricted access, with two-factor authentication and one user per person. The Swarm management ports only listen on the private network, the nodes accept SSH with a key only and the firewall closes everything except Traefik to the outside. Secrets go in the dashboard variables or in a secrets manager, never in the repository.
- GitPush, webhook or image
- DokployDashboard on its own server
- Docker SwarmManager and worker nodes
- TraefikHTTPS and domains
- BackupsDatabases and volumes to S3
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | A small cloud server for the dashboard and several for the Swarm cluster, joined by a private network. Backups in Hetzner Object Storage, which is S3-compatible. | Traffic between Swarm nodes goes over the private network; only Traefik is exposed. |
| AWS | EC2 instances in a VPC for the dashboard and the nodes, with backups in an S3 bucket. | If you already use RDS, the applications can connect to it instead of containerised databases. |
| Google Cloud | Compute Engine machines and backups in Cloud Storage through its S3-compatible access. | |
| DigitalOcean | Droplets in a VPC for the dashboard and the nodes, with backups in Spaces. | |
| OVH | Public Cloud instances with a private network and backups in OVHcloud Object Storage. | |
| Own server | Dokploy and the Swarm nodes on your physical servers or virtual machines. | To publish to the internet we use a proxy or a tunnel in front; we do not open the Swarm management ports. |
What is included
- A Dokploy dashboard on its own server, separate from the workloads, in your account and in your name.
- Remote servers or Docker Swarm nodes added to the dashboard, with labels to decide what runs where.
- Applications deployed from Git, from an image or from a docker-compose.yml, with environment variables organised per environment.
- Traefik with automatic HTTPS certificates and your own domains for each service.
- Scheduled backups of databases and volumes to an S3-compatible destination, restored in tests.
- A backup of the dashboard itself and its internal database, kept off the server.
- Restricted access to the dashboard, two-factor authentication and one user per person with per-project permissions.
- Dashboard updates read and rehearsed, and servers with patches, Docker up to date and disk monitoring.
Frequently asked questions
Do we need Docker Swarm to use Dokploy?
No. Dokploy works with a single server or with several remote servers driven over SSH, each on its own. Swarm comes in when you want to spread replicas of the same service across several nodes and have them reschedule themselves if one goes down. We propose it when losing a machine already costs you money.
Can we deploy our docker-compose.yml files as they are?
Almost always. Dokploy accepts Compose projects and publishes them behind Traefik. We review the volumes, networks and published ports first, because what works on a laptop sometimes exposes a database or stores data where it is not backed up.
What does Dokploy back up on its own, and what not?
It schedules backups of the databases it creates from the dashboard and of volumes to an S3-compatible destination. What it does not guarantee is that those backups can be restored or that they cover data living outside those volumes. That is why we restore one every now and then in a separate environment and note the result.
Dokploy or Coolify?
Both solve the same problem with different approaches. The detailed comparison, and how to move off Heroku or Vercel, is on the Coolify and Dokploy page. If you already use Dokploy, the usual choice is to stick with it and tidy it up.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on