A client asked me to stop deploying her staging environment by SSHing in and running git pull && docker compose up -d --build like it's 2019. Fair complaint. I'd been meaning to try a self-hosted PaaS instead of hand-rolled Caddy and compose files for a while, so I spun up two identical Hetzner CPX21 boxes and installed Coolify on one, Dokploy on the other, then deployed the same small Laravel app plus a Postgres database to both.
Getting either one running takes about the same four minutes
Both install with a single curl-to-bash command, which I'll admit made me nervous the first time and doesn't anymore, mostly because I've read both scripts now:
# Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
# Dokploy
curl -sSL https://dokploy.com/install.sh | sh
Both scripts do roughly the same thing: check Docker is installed, pull a handful of containers, wire up Traefik or their own proxy, and hand you a dashboard URL. Coolify's install finished in about three and a half minutes on my box. Dokploy's took closer to five, mostly because it also stands up Docker Swarm mode even for a single-node install, which Coolify only does once you add a second server.
Where the two actually diverge: build strategy
This is the part that matters if you deploy anything that isn't a plain Dockerfile. Coolify defaults to Railpack, its newer buildpack successor to Nixpacks, though Nixpacks is still there as a fallback. Dokploy sticks with Nixpacks and Heroku Buildpacks side by side, and lets you pick per application. For my Laravel app, both auto-detected PHP correctly and produced a working image without a Dockerfile, but Coolify's Railpack build was noticeably faster, about 40 seconds against Dokploy's Nixpacks build at just over a minute, largely because Railpack caches Composer layers more aggressively by default.
Neither win matters if you already have a Dockerfile you trust, which is what I ended up using for the client's app anyway once I needed a custom PHP extension neither buildpack shipped.
Database management is where Coolify pulls ahead for me
Coolify ships managed databases (Postgres, MySQL, MariaDB, Redis, and a handful of others) with one-click provisioning, automatic backups to S3-compatible storage, and a UI for restoring a specific backup without touching a shell. Dokploy supports the same list of engines, and its backup story is solid too, but the restore flow currently routes through the CLI rather than a full point-and-click restore in the dashboard. For a client who isn't going to SSH into anything, that's the difference between "she can restore last night's backup herself" and "she has to text me."
# the compose service definition both platforms happily imported as-is
services:
app:
build: .
environment:
APP_ENV: production
DB_HOST: postgres
depends_on:
- postgres
postgres:
image: postgres:17
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
Networking and multi-server access work differently too
Custom domains and automatic HTTPS worked the same way on both within a couple of minutes of pointing DNS at the box, so that's a wash. The gap shows up once you add a second server. Coolify treats additional servers as first-class from the start, meaning any app can target any connected server from the same dashboard, and it layers team roles and permissions on top so I can give a client's other contractor deploy access without handing over root. Dokploy's multi-server story leans harder on Docker Swarm itself once you're past a single node, which is more powerful if you already think in Swarm terms and more friction if you don't. Coolify also ships an MCP server alongside its API and CLI, which is a strange thing to care about until you realize it means an AI coding agent can query deployment status or trigger a redeploy directly, something I've started leaning on for routine restarts instead of opening the dashboard at all.
Both projects ship faster than you can keep up with
Coolify is at v4.3.23 as I write this, four patch releases in the last two weeks alone, and it carries 62,000 GitHub stars. Dokploy is close behind on velocity at v0.30.7 with a similar two-week cadence, and sits at about 37,500 stars, roughly a year and a half younger as a project. Neither release cadence is a red flag; if anything it means real bugs get fixed in days rather than sitting in a backlog. It does mean you should read the changelog before you click update on a client's production box, the same rule I'd apply to n8n or anything else that ships this often. I got burned once treating a Coolify minor version bump as routine and losing a custom Traefik label override that a new default had quietly replaced.
What I'd actually recommend
For a single Hetzner box running two or three client apps, either tool removes real pain over hand-rolled compose and Caddy files, and I wouldn't talk anyone out of either one. I moved this specific client to Coolify, mainly for the one-click backup restore and because Railpack's build speed adds up when I'm redeploying a dozen times a day during active work. If she ever needs true multi-node Docker Swarm scaling from day one rather than as an add-on, Dokploy's Swarm-first design would be the better starting point. I wrote about the box underneath both of these in what this blog actually runs on, and if you want help picking or migrating between any of this, that's the kind of work I take on, described at abrarqasim.com/work.
If you're running either tool right now, the one thing worth doing this week regardless of which you picked: manually trigger a database restore into a throwaway app once, before you need it for real. I found Dokploy's CLI restore step only after I needed it under pressure, and that's a bad time to be reading docs for the first time.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
Top comments (0)