The Self-Hosted PaaS Category Gets Crowded in 2026: What Coolify, Dokku, CapRover, and Dokploy Actually Don't Do

Coolify alone crossed 59,000 GitHub stars this year. Dokploy passed CapRover's star count without existing four years ago. Dokku still ships a decade-old CLI-only design and somehow keeps 30,000+ people watching its repo anyway. The self-hosted "push a git repo, get a running app" category isn't emerging anymore — it's crowded, mature, and arguably over-served for the thing it does best: running a handful of apps on one box you own.

That maturity raises a sharper question than "which one has the nicer dashboard." All four of these tools — Coolify, Dokku, CapRover, Dokploy — share the same architectural starting point: single-server-first, with multi-node support (where it exists at all) bolted on top of Docker Swarm. None of them do three specific things that a Cluster-API/Kubernetes-native platform does by default: real multi-node scheduling, declarative machine provisioning across bare-metal providers, and a documented API surface built for AI agents to operate against. Here's what each gap actually costs you to live without — and, just as important, what closing it actually costs to get.

The Shared Architecture DNA​

Line the four up side by side and the family resemblance is obvious once you look past the UI skin:

Dokku is worth calling out on its own here, because it isn't a weaker version of the Swarm story — it doesn't tell a multi-node story at all. That's a deliberate simplicity trade a decade of production use has validated, not an oversight. The other three all reach for Docker Swarm the moment "multi-node" comes up, which matters because Swarm itself has been in Docker's maintenance mode for years: it still ships production workloads today, but every one of these tools inherits Swarm's ceiling along with its convenience.

Gap #1: Multi-Node Scheduling That Actually Schedules​

"Multi-node support" sounds like one capability. In practice it's three: distributing load across machines, surviving a machine failing, and placing workloads intelligently based on what each node actually has free. Here's where each tool stops.

Dokku doesn't attempt any of the three. Teams that outgrow one box run multiple independent Dokku instances and stitch them together with an external load balancer they build and own themselves — which works, but it's infrastructure you're now maintaining outside the tool, not a feature the tool gave you.

Coolify's Swarm mode is still labeled experimental in its own documentation as of 2026, which is a candid admission worth taking at face value rather than working around.

CapRover has run Swarm the longest of the three and it shows in the polish, but the documented constraints are specific and load-bearing: apps with persistent data can only run pinned to a single node (no real horizontal scaling for anything stateful), the captain node stays a single point of failure even inside a cluster, and every node in the Swarm has to sit in the same datacenter because the gossip protocol's latency tolerance doesn't survive a real network hop between regions.

Dokploy gets the closest to production-grade — reviewers note it can match or beat what many small teams achieve running Kubernetes themselves once you dedicate a properly-failed-over manager node — but that "once you" is doing real work. HA isn't the default; it's a configuration you build.

A Kubernetes scheduler solves the specific problems above, not a generic "it's more powerful" wave: node affinity/anti-affinity places workloads by actual topology instead of "whichever node Swarm picked," pod disruption budgets and multiple control-plane replicas remove the single-manager SPOF outright, and (as of Kubernetes v1.36) in-place pod resizing lets a scheduler right-size a running workload without the delete-and-recreate dance Swarm-based tools still require. None of that is exotic — it's the baseline scheduling story Swarm never grew into.

Gap #2: Declarative Machine Provisioning, Not Just App Deployment​

Every one of these four tools starts from the same assumption: you already have a server. SSH in, run the install script, and the tool takes over from there. None of them has an opinion about how that server came to exist — provisioning the actual machine, whether a cloud VM or a bare-metal box, is a step you do yourself, outside the tool, before it becomes relevant.

Cluster API inverts that assumption. A Machine and MachineDeployment are themselves declarative Kubernetes custom resources, reconciled by controllers the same way a Deployment reconciles pods — the machine's lifecycle (provision, join, health-check, replace-on-failure) is managed infrastructure-as-code, not a runbook. Paired with a bare-metal provider like Metal3 or Canonical MAAS, that means adding capacity is "declare a new Machine object" rather than "SSH into a fresh box and run an install script by hand." It's the difference between a PaaS that manages apps on servers you provisioned, and a platform that manages the servers too.

For a single-VPS deployment this distinction barely matters — you provision one box once and move on. It starts mattering the moment "add capacity" becomes a recurring operational task rather than a one-time setup step.

Gap #3: An API Surface an Agent Can Actually Operate​

All four tools were designed for a human clicking through a dashboard or typing CLI commands — which was the right design target as recently as 2023. It's a narrower target in 2026, when AI agents are increasingly the ones triggering deploys, checking build status, and rolling back a bad release. None of Coolify, Dokku, CapRover, or Dokploy ships a documented, stable, versioned API built for that kind of unattended, multi-resource orchestration; what API surface exists is largely a byproduct of the dashboard's own internal calls, not a first-class product surface.

The gap isn't cosmetic. Agent-driven ops needs deterministic, machine-readable state — "what's the current status of this service, and what are my valid next actions" — without a human parsing a dashboard screenshot or a CLI's human-formatted output. A Render-compatible API surface gives an agent a stable contract to operate against directly: create a service, check its deploy status, roll it back, all through the same documented calls a human's dashboard action would trigger internally. That's the specific capability none of these four tools was built to offer, because none of them needed to be — until agents became a routine caller instead of an edge case.

The Real Cost of Closing These Gaps​

None of this is a case for "just run Kubernetes." The three gaps above are real, but so is the price of closing them, and it doesn't go away just because a platform is Kubernetes-native rather than vanilla DIY. Take the counterweight seriously before deciding it applies to you.

One widely-cited 2026 industry estimate puts realistic self-hosted Kubernetes operating costs for a small team at roughly $3,500–$11,000 a month once you price in the labor — not the cluster itself, but the 20–40% of a platform engineer's time it typically absorbs, on top of whatever the nodes cost. A separate 2025 survey is blunter still: it found that a large majority of organizations that start out running Kubernetes themselves hit a significant stability, security, or operational incident within the first 18 months. One account making the rounds this year describes exactly that kind of incident concretely — a traffic spike that sent a cluster autoscaler from 18 to 67 nodes, taking etcd and the network policy layer down with it, with a five-figure cost in downtime and emergency recovery. None of that is a Docker Swarm problem. It's a "you now operate a distributed system" problem, and a Kubernetes-native platform doesn't make the distributed system simpler — it just gives you better primitives for operating it.

That's why Coolify on a single $6-a-month VPS remains the correct answer for a solo developer with one app and zero dedicated ops time: understandable end-to-end in an afternoon is a real feature, not a limitation to apologize for, and none of the three gaps above cost that developer anything they were going to use.

When the Gaps Actually Matter​

Three concrete signals say the trade is worth making, rather than "Kubernetes is more powerful" in the abstract:

• You've crossed one physical box. The moment "add capacity" isn't a one-time setup step but a recurring operational task, Gap #1 and Gap #2 stop being theoretical.
• You need machine lifecycle, not just app lifecycle. If provisioning new bare-metal or cloud nodes is happening often enough that a runbook has turned into a bottleneck, that's exactly what Cluster API replaces with a reconciled resource.
• Agents, not just people, need to operate your infrastructure. If deploys, rollbacks, or scaling decisions are increasingly agent-triggered rather than human-triggered, a documented API surface isn't a nice-to-have — it's the thing the agent needs to function at all.

If none of those three apply, the honest recommendation is to stay exactly where you are — Coolify, Dokku, CapRover, or Dokploy on however many boxes you already run. A Cluster-API-native platform like bex closes these three specific gaps without asking a solo developer to hand-roll Metal3 or write their own reconciliation controllers first, but it doesn't zero out the underlying complexity the counterweight above describes — it just moves who's holding it, and gives an agent a real API to hold it through.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned and scheduled through the same Cluster API primitives described above. Star the repo on GitHub or deploy your first app today.

Sources​

• Coolify vs CapRover vs Dokku (2026): Which One Should You Actually Use? — selfhostable.dev
• Coolify vs Dokku vs CapRover Self-Hosted PaaS 2026 — buildmvpfast.com
• Dokploy vs Coolify vs CapRover in 2026 — MassiveGRID Blog
• EP1: They Said Kubernetes Isn't Coming to Coolify — DEV Community
• Scalability — Coolify Docs
• App Scaling & Cluster — CapRover Docs
• Running multi-server Dokku: problems and options — michielsikkes.com
• Running Dokploy Multi-Node with Docker Swarm on Dedicated Infrastructure — MassiveGRID Blog
• Docker Swarm vs Kubernetes for Small Teams: When Dokploy Is Enough — MassiveGRID Blog
• Provision Bare-Metal Kubernetes with the Cluster API — The New Stack
• Metal³ — Metal Kubed
• Cluster API Provider Metal3 — GitHub
• Provision Bare Metal K8s with Cluster API & Canonical MaaS — Spectro Cloud
• Github-Ranking Top100 stars — EvanLi/Github-Ranking
• Platform as a Service (PaaS) Market Growth Report — SkyQuest
• The Real Cost of Kubernetes: Total Cost of Ownership Breakdown — Encore
• Kubernetes in Production 2026: I Ran It for 3 Years and Deleted Half of It — Stackademic
• You Don't Need Kubernetes (It Almost Killed Our Startup and Cost Us $50K) — AWS in Plain English
• Deploy AI agent on Render with auto-scaling and monitoring — Render