Coolify vs Dokploy vs Kubero vs bex: The Single-Box-vs-Fleet Decision

Four tools now credibly answer "I want Heroku, but I own the machines": Coolify, Dokploy, Kubero, and bex. Every comparison piece written about them in 2026 asks the wrong first question — which one has more one-click app templates, which one's UI looks nicer, whose Discord is friendlier. None of that is the axis that actually decides which one you should run.

The axis that matters is this: does the tool assume your infrastructure is one box, or does it assume your infrastructure is a fleet? Coolify and Dokploy were built for a single Docker daemon and grew multi-node support later, as an option you opt into and mostly manage by hand. Kubero and bex were built Kubernetes-native from line one — but even between those two, "Kubernetes-native" means two structurally different things. Get this axis wrong and you either pay fleet-management complexity you'll never use, or you hit a one-box ceiling mid-migration with customers already live on it.

Four Architectures, Concretely​

Skip the marketing copy and look at what each tool actually is, mechanically, underneath its dashboard.

Coolify and Dokploy are Docker tools that learned to spread across more than one box. Kubero and bex are Kubernetes tools from the start — but that single label is hiding a real difference, which is the whole second half of what "Kubernetes-native" is supposed to mean in this comparison.

"Kubernetes-Native" Means Two Different Things​

Kubero and bex both get called "Kubernetes-native" in every roundup, as if that settles the comparison. It doesn't — they solve different halves of the problem.

Kubero assumes the cluster already exists. Install Kubero's operator and UI onto a Kubernetes cluster you've already stood up — EKS, GKE, a hand-rolled kubeadm cluster, a single-node k3s box, whatever — and it gives you git-push deploys, review apps, and add-ons for Postgres/Redis/Mongo, storing all of its own state in that cluster's etcd instead of a bolted-on database. What Kubero does not do is provision, upgrade, or heal the cluster underneath it. If a node dies, if you need to add capacity, if you're rotating Kubernetes versions — that's still entirely on you, with kubectl, exactly the ops burden a self-hosted PaaS is supposed to remove.

bex provisions and lifecycles the cluster itself. Cluster API turns "add a node," "replace a failed node," and "roll a Kubernetes version" into declarative reconciliation instead of runbooks. Point CAPH at a Hetzner project and a Machine object becomes an actual server, joined to the cluster, health-checked, and replaced automatically if it goes unhealthy — the same self-healing, declarative model that made EKS/GKE node groups convenient, running on hardware bex (or you) actually owns instead of a hyperscaler's managed control plane.

So the honest framing isn't "both are Kubernetes-native, pick your favorite UI." It's: Kubero is an app-layer operator that still leaves cluster lifecycle as your job; bex's Cluster API layer owns cluster lifecycle as the product. If you already run Kubernetes and have someone who enjoys keeping it healthy, Kubero is a lighter, more focused tool. If part of what you're buying is "stop hand-rolling node lifecycle," Kubero doesn't get you there — that's specifically what CAPI-based platforms exist to remove.

The Single-Box Ceiling: Where It Actually Cracks​

"Just run it on one box" works for a real, concrete stretch of a project's life. Here's where it stops working, in numbers rather than vibes.

Resource contention shows up long before the box runs out of RAM. Coolify and Dokploy both happily stack a dozen services on one VPS — the ceiling isn't a hard service count, it's the point where a build for one app starves CPU from another app's live traffic, because there's no scheduler making placement decisions, just whatever Docker was told to run where. Teams report hitting this somewhere around 8-15 concurrently-running services on a mid-size box (4-8 vCPU), well before disk or RAM would say no.

A dead box is full downtime, not a rescheduled pod. On a single Coolify or Dokploy primary, losing the server means every app on it is down until a human rebuilds or restores it — there's no other node to fail over to. Multi-node Dokploy via Swarm helps here, but Swarm quorum has its own trap: managers must be an odd number (1, 3, 5, 7) specifically so the cluster can still agree on state after a failure, and losing quorum itself becomes a manual recovery, not an automatic one. Coolify's own multi-node story, per 2026 reviews of the May v4.0 release, is functional but "rough" — production HA needs more manual glue than the pitch implies, and scaling still means SSHing into boxes and managing placement rules by hand.

Kubero and bex don't have this ceiling at all, because they never depend on one box surviving. A pod on a properly-sized Kubernetes cluster gets rescheduled onto healthy capacity automatically; a CAPI-managed node that fails gets replaced without a human involved. That's the entire trade you're making by taking on cluster complexity up front — you buy out of the single-box failure mode before you ever hit it, instead of discovering it live.

What Each Tool Actually Costs on Real Hardware​

This is where "single Hetzner box" earns its place in the title — and where the four tools split cleanly into two groups that can't be compared on the same line.

Coolify and Dokploy are genuinely single-box tools, so their idle cost is a fair, direct number: on a Hetzner CPX31 (4 vCPU / 8 GB, ~$25/month), Coolify's own management daemon idles around 5-7% CPU and 500 MB-1.2 GB of RAM before a single app is deployed — spiking toward 25% CPU when its built-in metrics collector runs. Dokploy idles leaner, around 0.8-1.5% CPU and 350-800 MB RAM. On an 8 GB box, that's the difference between roughly 6.8-7.5 GB left for actual applications (Dokploy) versus 6.8 GB at best, 6.5 GB more typically (Coolify) — a real but not dramatic gap, and one that shrinks in relative terms as you size the box up.

Kubero and bex don't have a comparable "idle daemon tax" number, because neither one is designed to be the only thing running on a single box — and pretending otherwise would understate what each actually requires to exist. Kubero needs a Kubernetes cluster underneath it before its own operator and UI containers even start; the lightest realistic version of that is a single-node k3s install, whose control plane alone typically settles around 700 MB-1 GB of RAM idle (K3s' own docs put a production-viable single-node minimum at 2 GB RAM / 2 vCPU for the control plane, before workloads) — meaningfully heavier than Coolify's or Dokploy's plain-Docker footprint, for a cluster of exactly one. bex is more categorical still: it has no single-box deployment mode at all. Its minimum viable footprint is a CAPI management layer plus at least one CAPH-provisioned workload node — two machines, not one — because the product is fleet lifecycle, and a fleet of one isn't the case it's optimized for.

Community size is the other real signal, and it maps cleanly onto how long each project has been fighting for this exact space: Coolify sits around 55,700 GitHub stars, the largest of the four and the deepest one-click-service catalog (280+ integrations); Dokploy trails at roughly 24,000-26,000 stars but with a steeper growth curve through 2026; Kubero, the smallest and most narrowly-scoped of the four, sits around 4,100-4,300 stars.

Where Multi-Node-From-Day-One Is Overkill​

None of this is an argument that Kubero or bex is strictly "better." A solo developer shipping one SaaS product on one VPS, who has no near-term plan to run a second machine, gets nothing from Cluster API's declarative node lifecycle — it's machinery solving a problem they don't have yet. For that team, Dokploy's lean footprint or Coolify's larger ecosystem and template catalog are the correct answer, full stop, and staying there for a year or three is a perfectly good decision, not a mistake to be corrected later.

The pattern worth watching for isn't "avoid Kubernetes tools out of principle" — it's noticing when you're already paying manual-Swarm-quorum or manual-SSH-placement tax on a single-daemon tool for a problem those tools were never built to solve declaratively.

Picking One​

Boiled down to the actual decision:

• You'll never run more than one or two boxes, and want the deepest ecosystem: Coolify.
• You'll never run more than one or two boxes, and want the leanest footprint: Dokploy.
• You already run Kubernetes and just want an app-deploy layer on top of it: Kubero.
• You want the cluster's own lifecycle — node provisioning, healing, upgrades — handled declaratively instead of by hand, on hardware you own outright: a Cluster-API-based platform.

That last option is what bex is built to be: git-push deploys backed by a real Cluster API fleet on owned Hetzner machines, not a single Docker daemon wearing a dashboard. If you're already past the point where "just SSH into the box" is a real answer, the source is on GitHub — deploy your first app on infrastructure you actually own.

Sources:

• Coolify vs CapRover vs Dokploy — Server Compass, 2026
• Coolify GitHub repository
• Dokploy Cluster documentation
• Dokploy Docker Swarm architecture — MassiveGRID
• Kubero GitHub repository
• Cluster API Provider Hetzner (CAPH) — Syself docs
• Managing Kubernetes on Hetzner with Cluster API — Hetzner Community
• Coolify vs Dokploy 8-month idle resource benchmark — NextGrowth
• K3s Resource Profiling — official docs
• K3s Requirements — official docs
• Hetzner Cloud Pricing after 2026 increases — Bitdoze