Coolify vs Dokploy vs Kamal in 2026: Idle CPU, Multi-Server, and Why a Cluster-API PaaS Is a Different Bet

Every self-hosted PaaS pitch starts with the same promise: stop paying a hosted platform's markup, run the same git-push workflow on your own server. What the pitch skips is that the tool making that promise happens is itself a tenant on your box — and the three most popular options charge wildly different rent for the privilege.

Coolify's own GitHub issue tracker shows a build sitting at 40–45% of a single CPU core with every hosted app stopped. Dokploy's published idle footprint is under 1% CPU and 350MB of RAM in some benchmarks — and 9% CPU with 44% of RAM used in others, from the same category of test. Kamal doesn't have a number at all, because there's no persistent daemon to measure. Here's what that overhead actually costs on real hardware, why the three tools spend it so differently, and where a Cluster-API-based platform stops being "PaaS #4" and becomes a different kind of bet entirely.

The Numbers, Up Front​

That table is the whole comparison in miniature: Coolify spends resources on a persistent dashboard, job queue, and metrics agent running on every managed node; Dokploy spends less because it delegates clustering to Docker Swarm instead of building its own; Kamal spends almost nothing because it refuses to run a control plane at all. None of these numbers should be read as a strict ranking — each is the visible cost of a real architectural choice, and the choice that costs the least CPU also does the least for you.

Coolify: A Full Control Plane, Priced Like One​

Coolify's architecture is the most feature-complete of the three by a wide margin — a persistent web dashboard, a background job queue for deployments, a Sentinel monitoring agent pushing container and system metrics from every managed server, and SSH multiplexing to talk to remote hosts without reopening connections per command. That's also exactly why it's the heaviest: a 2 vCPU / 4GB VPS running nothing but Coolify's own services already has roughly 15–18% of total RAM and half a CPU core spoken for before a single app container starts.

The cost isn't hypothetical or a one-time snapshot. Coolify's own issue tracker has an open report (#7394) of the built-in scheduler/queue driving CPU to ~400% on a multi-core box, and a second one (#9489) from around April 2026 describing a sustained 40–45% single-core baseline on a 2 vCPU/4GB VPS with every hosted app stopped — a regression, not the documented steady state. That's the tradeoff Coolify is making explicitly: it's the richest UI and the most built-in monitoring of the three, on ~3.5 years and 12,000+ commits of development, and roughly 55,700 GitHub stars reflect that maturity. You're paying platform overhead for a genuinely fuller feature set, not for nothing — but on a small box, "half a core gone before you deploy anything" is a real number, not a rounding error.

Dokploy: Lighter, Because Swarm Does the Clustering​

Dokploy's multi-server story looks similar to Coolify's from the dashboard — add a server, pick which resource runs where — but the mechanism underneath is different in a way that matters for overhead. Where Coolify's control plane individually SSHes into each worker to manage containers, Dokploy hands clustering off to Docker Swarm itself: the manager node runs the Dokploy UI, API, an internal Postgres instance, and the Swarm manager process, while worker nodes need nothing but Docker with Swarm mode enabled — no Dokploy agent at all.

That's the architectural reason Dokploy's benchmarks skew lighter in most reports: 0.8% idle CPU and roughly 350MB of RAM is a commonly cited figure. But it isn't the only figure in circulation — at least one benchmark puts Dokploy at 9% idle CPU and 44% of RAM on a comparable box. The spread is wide enough that it's worth taking neither number as gospel; both are plausible depending on Dokploy version, whether Traefik and the internal Postgres are counted as "platform" or "workload," and how the test box was sized. What's consistent across sources is the architecture, not the exact percentage: Dokploy is the only one of the three offering native Swarm-mesh multi-node out of the box, and that mesh is also why its worker nodes carry near-zero platform tax — Swarm, not Dokploy's own code, is doing the coordination.

Kamal: Zero Daemon, Zero Dashboard​

Kamal doesn't have an idle-CPU number because there's nothing running to measure it against. The CLI SSHes into each configured host, drives Docker commands directly, and exits — no control-plane process, no internal database, no background job queue persists between deploys. The only thing left running on the server afterward is kamal-proxy, a small Go reverse proxy handling zero-downtime health checks, traffic draining, and cleanup around each deploy, with a default 512MB Docker memory limit that in practice it doesn't come close to using.

That's 37signals' own production setup for HEY and Basecamp: containerized apps and kamal-proxy, nothing else. The honest caveat is that "zero overhead" is not an apples-to-apples comparison with Coolify or Dokploy — Kamal has no built-in dashboard, no per-app UI, no multi-tenant server pool with a shared control plane. If you want a metrics dashboard, 37signals' own engineering blog walks through wiring up Prometheus yourself, which is its own resource line you'd have to add back in. Kamal isn't winning the overhead comparison by being more efficient at the same job — it's winning by not doing the job (a shared, persistent control plane) at all. That's a legitimate choice for a team running a handful of known apps on hosts they already manage by hand; it's a non-starter for anyone who wants a dashboard, a multi-tenant server pool, or self-service deploys for people who don't want to touch SSH.

Why a Cluster-API PaaS Isn't a Fourth Entry in This List​

It's tempting to slot a Cluster-API-based platform into this same table as "option four," but the comparison breaks down at the premise. Coolify, Dokploy, and Kamal all manage application deployment on top of servers you already provisioned, patched, and keep running by hand. None of them touch the machines themselves — if a Hetzner box dies, you're SSHing in to replace it, then re-adding it to whichever tool you're running.

Cluster API Provider Hetzner (CAPH) operates one layer down: it turns the machines themselves — cloud instances and bare-metal Robot servers alike — into declaratively managed, self-healing Kubernetes nodes. CAPH and the Cluster API controllers reconcile continuously against a declared desired state, the same reconciliation loop that lets SNCF, France's national rail operator, update its entire Kubernetes fleet monthly with no manual patch nights and no drift between clusters. A HetznerBareMetalRemediation policy defines exactly what "unhealthy" means for a bare-metal node and what to do about it automatically — provision a replacement, not page a human.

That buys something none of the three deploy tools above are trying to sell: infrastructure lifecycle as code, not just app deployment as code. The cost is real and shouldn't be waved away — running an actual Kubernetes control plane is more moving parts than a single Rails-derived dashboard or an SSH script, and it's a genuine learning curve if your team has never operated a cluster. Cluster API isn't a strictly-better version of Coolify, Dokploy, or Kamal; it's a different bet, made on the assumption that the fleet itself — not just the app on top of it — needs to be self-healing and declarative, which matters most once you're running more than one or two boxes for more than one tenant.

Picking Between Them​

• A single app on a single VPS, and you already know your way around SSH — Kamal's zero-daemon model has nothing to out-grow, because there's nothing running to out-grow.
• Several apps, a small team, and you want a dashboard without giving up Docker Swarm's native clustering — Dokploy's lighter footprint and Swarm mesh are built for exactly this.
• You want the richest self-service UI and built-in monitoring, and can spare the CPU/RAM for it — Coolify's feature set and community size (55,700+ stars) reflect real maturity; budget for its control-plane tax on a small box.
• You're running a fleet of owned machines, multiple tenants, and want the infrastructure itself — not just the app on top — to self-heal and reconcile against a declared state — that's the Cluster API bet, and it's the one a git-push PaaS built for AI agents to operate needs, since an agent reasoning about "is my fleet healthy" needs a reconciliation loop under it, not just a dashboard.

None of these tools are wrong. They're optimized for different numbers of servers, different numbers of tenants, and different appetites for what should self-heal versus what you're willing to SSH in and fix by hand.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, backed by Cluster API's declarative fleet management instead of a hand-managed server pool. Star the repo on GitHub or deploy your first app today.

Sources​

• Coolify GitHub Issue #9489 — increased baseline CPU usage regression
• Coolify GitHub Issue #7394 — critical CPU overload from scheduler/queue
• MassiveGRID — Dokploy vs Coolify vs CapRover in 2026
• MassiveGRID — Coolify vs Coolify Cloud vs Dokploy vs CapRover
• MassiveGRID — Running Dokploy Multi-Node with Docker Swarm
• MassiveGRID — Multi-Server Coolify Setup
• Dokploy Docs — Cluster
• 37signals Dev — Kamal 2 released
• 37signals Dev — Prometheus metrics with Rails and Kamal
• Kamal Proxy GitHub — basecamp/kamal-proxy
• Kamal Docs — Proxy configuration
• Cluster API Provider Hetzner — GitHub
• Hetzner Community — Managing Kubernetes on Hetzner with Cluster API
• CAPH Docs — Hetzner bare-metal remediation template