Coolify vs Dokploy

Both of these exist because Heroku got expensive and Vercel bills by the request. You point a domain at a VPS, connect a git repository, push, and a few minutes later there is a running container with a valid certificate. That workflow is genuinely good and both products deliver it.

What neither product page tells you is what happens in year two: how much of your server the control plane eats, what breaks when you upgrade, and what you actually need on disk to rebuild after a failure. That is what this page is about.

The table is worth reading for container_count and ram_idle_mb, because those two numbers are the whole cost difference. Five containers and roughly 1.2 GB against three containers and roughly 900 MB, on machines where the documented minimum is 2 GB total. Also check sso: one of these can sit behind your identity provider and the other cannot.

The licences, verified#

Coolify is Apache-2.0, full stop. No source-available directory, no enterprise edition, no feature gating. The commercial offering is the same code hosted for you.

Dokploy is Apache-2.0 with a reservation. LICENSE.MD splits the repository: anything under a /proprietary directory falls under the Dokploy Source Available License, which forbids production use without a commercial agreement, and everything else is Apache-2.0. That directory does not exist at the repository root today, so everything you install right now is Apache-2.0. It is a placeholder for an open core model that has not arrived. Whether that bothers you is a judgement call; Licence drift has the pattern of how often placeholders like that get filled in.

Neither licence gives you a reason to reject the other. Both give you the right to keep running whatever version you have if the project changes direction, which is the property that actually matters.

How young these are, without the marketing#

Coolify's repository dates to 2021 and it spent years being recommended in every "self-hosted Heroku" thread while the software itself was labelled beta. The stable v4.0.0 tag landed 27 April 2026. The line has moved fast since: 4.1 added the Railpack build pack and audit logging, 4.2 added persistent volume backups and cloud server provisioning, 4.3 rebuilt domain handling, and 4.4 is in release candidate with OpenID Connect. A v5 rewrite for multi-server scalability is in progress with no public date, and the maintainer has stated v4 stays supported.

Dokploy's repository was created in April 2024. The current release is v0.30.5, still 0.x, shipping several versions in some weeks. Release v0.29.13 fixed roughly sixteen command-injection and authorization-bypass issues in one go. Read that two ways at once: the project has a functioning security process and people looking at it, and the codebase is young enough that a batch of sixteen was there to find.

The honest probability assessment, which no vendor will give you: assume a breaking release from either within twelve months. For Dokploy that is what a fast-moving 0.x line means by definition. For Coolify it is v5, whenever it lands. Plan for it the way An update strategy that does not lose data describes: pin versions, snapshot before upgrades, and read release notes rather than running coolify update on a Friday.

Practical corollary: do not follow a tutorial written before April 2026 for Coolify. The settings layout changed.

What survives when the platform breaks#

This is the question that decides whether you should use either of these for anything you care about, and it has a reassuring answer and an alarming one.

Reassuring: your applications keep running. Both platforms deploy your workloads as ordinary Docker containers (Coolify) or Swarm services (Dokploy), fronted by a separate proxy container. If the control plane is down, dead or mid-upgrade, the proxy keeps serving traffic and renewing certificates, and your app containers keep restarting under Docker's own restart policy. A broken Coolify is an inability to deploy, not an outage. That is a much better failure mode than a monolith.

Alarming: the configuration is not recoverable from the running system. Both store everything in a Postgres you must dump rather than copy, and both have a file outside that database without which the dump is worthless.

For Coolify:

/data/coolify/source/.env      <- Laravel APP_KEY, encrypts credentials in Postgres
/data/coolify/ssh/             <- keys used to reach every managed server
/data/coolify/{applications,databases,services,backups}
coolify-db volume              <- pg_dump this, do not copy the files

Restore the database without that exact source/.env and every stored secret, SSH key and registry credential decrypts to garbage. It is a bind-mounted file, so anyone backing up Docker volumes only has been backing up an unreadable database.

For Dokploy:

/etc/dokploy/                  <- Traefik config, SSH keys, app volumes, deploy logs
dokploy-postgres volume        <- pg_dump this
docker swarm join-token manager/worker   <- record these

Without the Swarm join tokens a rebuilt manager cannot readopt its workers.

In both cases, the real mitigation is upstream of the backup: keep your Dockerfiles, compose files and environment templates in git. Then the platform is a convenience you can replace in an afternoon rather than a dependency you cannot rebuild. That is the same argument Docker Compose conventions makes and the same one that applies to Portainer vs Komodo.

Pair that with a real off-box backup of the two paths above using restic, and follow Backing up a running database for the Postgres dump so you are not copying a file mid-write.

Where they differ in daily use#

Service catalog. Coolify's is the deepest of any self-hosted PaaS: several hundred prepackaged one-click services alongside your own apps. Dokploy has templates but far fewer. If part of the appeal is deploying Plausible, Umami and a Postgres without writing compose files, that is a Coolify point and a big one.

Managed databases. Both offer Postgres, MySQL, MariaDB, MongoDB and Redis with scheduled backups to S3. Coolify's are more mature; Dokploy's work.

Proxy. Coolify runs Traefik or Caddy as coolify-proxy on 80 and 443. Dokploy runs Traefik with its config in /etc/dokploy. Neither stops you understanding what is happening, but if you want to reason about routing yourself, Reverse proxy and TLS is worth reading alongside either.

Multi-server. Coolify adds servers over SSH with a key it generates; they run only the proxy and your workloads. Dokploy joins them as Swarm workers. Coolify's model is simpler to reason about; Dokploy's gives you actual orchestration if you want it.

Builds on production. Both compile on whichever server you deploy to, by default. A Next.js build during peak hours will visibly degrade everything else on a 2-core box, and 2 cores is the documented minimum for both. Configure a dedicated build server before you notice the problem rather than after. Coolify's concurrent build limits became per-server in the 4.3 line.

The firewall problem, which is the same problem#

Coolify's own documentation states it plainly: Docker uses NAT-based iptables rules that bypass UFW, so ufw deny 8000 does not actually block Coolify's dashboard. The same applies to 6001 and 6002 for the realtime service, and the same mechanism applies to Dokploy's dashboard on port 3000.

People firewall the host, assume the dashboard is private, and are wrong in a way that produces no error message and no log line.

The fixes, in order of preference:

1. Use your provider's firewall, which sits outside the host entirely.
2. Bind the dashboard to a domain behind the proxy and close the direct port. Coolify's docs say you can safely close 8000, 6001 and 6002 once a domain is configured.
3. Reach the dashboard over a VPN or mesh network only.

Do not leave either dashboard open on the internet on the basis that it has a login form. Dokploy's own release history is the argument against that. A security baseline for a home server covers the rest.

Verdict by situation#

What to do next#

Try one on a throwaway VPS for a week before you migrate anything real. The specific test worth running is not "can it deploy my app", because both can. It is: deploy the app, take the backup files listed above, destroy the server, build a new one, and restore. If you cannot get back to a working deploy from those files alone, you have found the gap while it is still free to find.

Then decide honestly whether you need a PaaS at all. If your workload is three containers that change twice a year, a directory of compose files and Reverse proxy and TLS will outlive both of these projects. When not to self-host is the other half of that question, and Stack planner will tell you whether the box has room for a control plane in the first place.