Dokploy and Coolify are two self-hosted PaaS platforms that solve the same problem: take a Git repository or a Docker image and deploy it on a VDS without manually writing Compose files. The choice between them comes up once a server already runs Docker and the question is which deployment panel to put on top of it.
How Dokploy and Coolify are alike, and how they differ
Both panels solve the same task the same way: a web interface, a Git repository connection, an automatic image build, and an SSL certificate issued through a built-in reverse proxy. The difference mostly comes down to the maturity of the ecosystem, the set of ready-made database templates, and how heavy the panel itself is.
Dokploy is younger and lighter on resource requirements, while Coolify has been around longer and has built up more ready integrations — queues, storage, monitoring. For a one-off task of running a single site the difference is barely noticeable; for a dozen services on one VDS it becomes significant. When choosing, it is also worth checking the ready database and service templates for the stack in question — anything missing from the built-in set still has to be described by hand in a custom docker-compose.yml.
What the server needs for each panel
Both panels are installed on a VDS with Docker already set up — setting up Docker on the server is covered in the article on setting up Docker on a VPS, and that part is the same no matter which deployment panel comes next.
Dokploy is lighter on memory: a panel plus one or two applications fit in 1 to 2 GB. Coolify is more demanding — running several applications comfortably needs 2 to 4 GB, because its own database and Redis start up alongside the panel.
Comparing Dokploy and Coolify
The basic capabilities of the two panels are almost identical; the differences show up in the details.
| Parameter | Dokploy | Coolify |
|---|---|---|
| Minimum memory | 1 to 2 GB | 2 to 4 GB |
| Ready database templates | a basic set | a wider set |
| Built-in reverse proxy | Traefik | Traefik |
| Interface | English, translation in progress | translated into several languages |
Installing the chosen panel
The installer for both panels is a single command that deploys the panel's containers on a server that already runs Docker.
# Installing Dokploy on a VDS with Docker
curl -sSL https://dokploy.com/install.sh | sh
# The panel becomes available on port 3000 right after installation
If a ready-made installer leaves too little control over individual containers, both panels can also be deployed through a custom docker-compose.yml — how to write one is covered in the article on setting up Docker Compose.
What to do when the panel will not start
First-run problems tend to repeat regardless of which panel is chosen.
- Check that the panel's port (3000 for Dokploy, 8000 for Coolify) is not already taken by another process on the server.
- Look at the logs of the panel's own container — the install script usually prints the container name at the end of the run.
- Make sure the server has at least 2 GB of memory free — when memory runs short, the panel's containers crash and restart in a loop.
- Check the firewall rule for the required port if the server sits behind the provider's external firewall.
- Set up ongoing monitoring of server resources — how to do that is covered in the article on monitoring VDS resources.
Frequently asked questions
Which is simpler for a beginner — Dokploy or Coolify?
Dokploy has a more compact interface and fewer steps during the first setup, but Coolify has more ready templates and community write-ups — that matters too for a first encounter with self-hosted PaaS.
Can projects be moved from Coolify to Dokploy?
There is no direct migration tool between the two panels: the move is done by exporting the environment variables and reconnecting the same Git repository in the new panel. Files and data volumes are moved separately, by plain copying to the new server.
Does only one panel have to run per server?
Technically both panels can be installed on one VDS, but ports and resources then have to be split by hand, which adds maintenance effort without a clear benefit — one server usually runs one panel.