Dokploy vs Coolify: Choosing a Self-Hosting Platform

Dokploy and Coolify solve the same problem — a git-push-to-deploy dashboard on hardware you rent — and they disagree about how to run containers underneath.

That disagreement is the whole comparison. Dokploy schedules applications as Docker Swarm services. Coolify runs plain Docker containers. Everything else follows from that choice.

Where they actually differ

The runtime row drives the rest. Swarm gives Dokploy a scheduler that already knows how to replace tasks one at a time, drain a node and reschedule work elsewhere. Coolify’s plain-Docker model gives you a system where docker ps output matches your mental model exactly, and where nothing extra sits between you and the container.

Licensing, precisely

“Open source” is doing too much work in most comparisons of these two, so here is what the licence files actually say. Checked 22 July 2026 against the repositories themselves, not the marketing pages.

Coolify is licensed under the Apache License 2.0. One licence, whole repository, no carve-outs. A paid Coolify Cloud exists, but it is hosting — it does not change the licence on the code you self-host.

Dokploy splits the repository:

• Everything outside a /proprietary directory is Apache License 2.0.
• Anything inside one is under the Dokploy Source Available License (DSAL) 1.0, which permits modification and testing but requires “a valid commercial agreement from Dokploy” for production use.

The detail that matters, and that the licence text itself hedges on: LICENSE.MD scopes the proprietary terms to /proprietary “if that directory exists” — and on the canary branch today, it does not. The repository root holds apps/ and packages/ and no /proprietary. So the code you install today is Apache 2.0 in practice, with the dual-licence structure sitting ready for components that have not landed yet.

That is a meaningful difference in kind, not degree. Coolify’s licence cannot later reclassify part of the codebase without a relicensing event. Dokploy’s already reserves the right, which is worth knowing before you build a business on either — but it is not the same as saying parts of Dokploy are proprietary today.

Installation and day one

Both install from a single script on a fresh Ubuntu 24.04 host. Neither is usable on a 1 GB instance — 2 GB is the floor and 4 GB is comfortable once you add a database and a build.

Both projects document a one-line piped install. Download the script and read it instead:

# Dokploy
curl -sSL https://dokploy.com/install.sh -o dokploy-install.sh
less dokploy-install.sh
sudo sh dokploy-install.sh

# Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o coolify-install.sh
less coolify-install.sh
sudo bash coolify-install.sh

Dokploy’s installer initialises Swarm mode on the host. You can see it afterwards:

$ docker info --format '{{.Swarm.LocalNodeState}}'
active

On Coolify the same command returns inactive, because it never needs Swarm.

Day one goes about the same on both: create an account on first visit, add a git source, point at a repository, pick a build method, add a domain. Budget an hour to get a first application live on either.

Build systems and application support

Both accept a Dockerfile, a compose.yaml, or automatic detection through Nixpacks. Coolify additionally supports Cloud Native Buildpacks and static-site builds as first-class options.

For anything with a Dockerfile, this is a non-difference. For a framework you have not containerised — a Laravel app, a Rails app, a Next.js repo with no Docker config — automatic detection is where you will spend your evaluation time, and it is worth testing with your actual repository rather than a demo.

Where Coolify pulls ahead is the template catalogue: self-hosted services you deploy without writing any config. If your plan involves standing up a dozen open-source tools, that catalogue is a real time saving.

Where Dokploy pulls ahead is Compose support feeling native rather than adapted. A multi-service compose.yaml deploys with its own domains and environment per service, which matches how most non-trivial applications are already structured.

Zero-downtime deploys and multiple servers

This is the strongest reason to pick one over the other.

A Swarm service with a health check performs a rolling update by default: start the new task, wait for it to report healthy, then stop the old one. Dokploy exposes that through the UI, and you can inspect what actually happened:

docker service ps my-app --no-trunc

Coolify’s default deployment stops the old container and starts the new one. There is a brief window — usually seconds — where requests fail. For an internal tool that is fine. For a public API it is not, and you will be configuring your way around it.

For multi-server, the models differ more than the feature lists suggest. Swarm joins additional nodes into one cluster with one scheduler; Dokploy can then place services anywhere in it. Coolify manages several independent servers from one dashboard — simpler to reason about, and no cluster to lose quorum on, but you place applications on specific hosts yourself.

Neither gives you a Kubernetes-grade scheduler, and neither is trying to.

Databases, backups and secrets

Both provision managed-feeling PostgreSQL, MySQL, MariaDB, MongoDB and Redis containers with generated credentials, and both offer scheduled backups to S3- compatible storage.

Two things to check yourself, on either platform, before you trust that:

Secrets are environment variables in both, stored in the control plane’s own database and injected at deploy time. Neither integrates with an external secrets manager without extra work. If your compliance position requires Vault or a cloud KMS, factor that in now.

What breaks, and how you recover

Assume the control plane will break — a bad upgrade, a full disk, a database corruption. On both platforms your applications keep serving traffic, because the proxy and the app containers are independent of the dashboard.

Recovery differs:

On Coolify, the containers are ordinary Docker containers. docker ps, docker logs, docker inspect all work the way you expect, and you can keep a service alive by hand indefinitely while you fix the dashboard.

On Dokploy, you are debugging Swarm. docker service ls, docker service ps <name>, docker node ls. Swarm’s failure modes — a task stuck in Pending because of a placement constraint, a service that rolls back on its own — are learnable but they are a second system to learn.

Back up the control plane’s own state in both cases. That is the piece neither platform will reconstruct for you.

Which to pick

Choose Dokploy if uptime during deploys matters, if you expect to add a second and third node to one cluster, or if your applications are already described by Compose files.

Choose Coolify if you are standing up many self-hosted services, if you want the larger community and template library when you get stuck, or if you value being able to drop to plain docker commands during an incident.

If neither of those describes you, the honest answer is that a compose.yaml in a git repo plus a five-line deploy script will serve a single application perfectly well, and it has no control plane to maintain at all. Reach for a platform when you have enough applications that the dashboard saves you more time than it costs.