Dora NodaByteiota's "PaaS First: Why 2026 Marks the End of Defaulting to Kubernetes" has a number in it that's hard to argue with: a minimum viable Kubernetes platform team is three senior engineers at roughly $200,000 each, $600,000 a year, and you need a cloud bill "approaching $2 million annually" before that math pencils out. Its verdict: if your team is under 50 engineers and your cloud spend is under $2M, defaulting to Kubernetes is burning money, and single-box tools like Coolify and Dokku are proof that simpler already wins.
The number is real. The conclusion doesn't follow from it — because the $600,000 isn't the cost of Kubernetes. It's the cost of building Kubernetes' lifecycle automation by hand, which is a different thing, and a 2026 Kubernetes release makes that gap concrete enough to price.
The Case Against Kubernetes-by-Default Is Real
Start by conceding what's true, because most of it is.
The FinOps Foundation's 2026 State of Cloud Cost report found Kubernetes beats standalone Docker hosts on compute cost per transaction — but only after a fleet crosses roughly 20 services. Below that line, the report found self-managed Kubernetes adds 15-30% to total cost of ownership versus just running Docker, because the orchestration overhead has nothing to amortize against yet. That's not a rounding error — it's the same shape as real teams' downsizing stories, like the one documented in 2026 of a team cutting a Docker-Compose-based deploy from roughly $1,500-2,000/month on Kubernetes to $340/month, saving close to $20,000/year alongside 60 hours/week of engineering time that had been going into cluster care and feeding.
CNCF's 2026 numbers back the "if you must run it, don't run it yourself" half of the argument too: 68% of new projects now start on managed Kubernetes rather than a self-hosted control plane, and separately, 58% of organizations report that Kubernetes maintenance eats more than 30% of their platform team's time. The single biggest line item inside that 30%: version upgrades. Teams have reported spending two full months carrying a cluster from v1.28 to v1.29 — testing admission webhooks, staging a canary node pool, rolling workloads over in waves, watching for the API deprecations that always turn out to matter more than the changelog implied.
That's where byteiota's $600,000 actually comes from. It isn't a Kubernetes tax. It's a hand-rolled-lifecycle tax — three senior engineers who exist mostly to do, manually and on a schedule, the exact things a "cluster" implies should already be automatic: patch nodes, rotate certificates, back up etcd, and survive a minor-version bump without an outage. Below 50 engineers, paying three senior salaries to run that by hand is a bad trade, full stop. Coolify and Dokku's whole pitch — one box, one daemon, SSH in and go — is a completely rational response to that specific cost.
What the Critique Is Actually Aimed At
Here's the piece byteiota's framing skips: "Kubernetes" and "a team that hand-builds Kubernetes' lifecycle tooling" are not the same target, and the 2026 upgrade cycle is exactly where they diverge.
On January 27, 2026, Cluster API shipped v1.12, and its headline feature is aimed squarely at the biggest item in that 30% maintenance number. Cluster API had always rolled out machine changes by the "immutable infrastructure" playbook: create a new Machine, delete the old one. Simple, predictable, and exactly what makes a two-month v1.28-to-v1.29 migration painful, because every node in the cluster gets torn down and rebuilt to get there. v1.12 adds in-place updates: for changes that don't require touching the underlying OS or infrastructure, Cluster API now patches the existing Machine directly instead of replacing it, and chained upgrades sequence multi-step version jumps automatically instead of a human staging each hop by hand. The reconciliation loop decides which mechanism a given change needs — no runbook, no canary node pool a team built themselves.
Put a number on what that actually removes. If version upgrades are the single largest item inside the 30%-plus of platform-team time CNCF measured, and that 30% is what's costing byteiota's hypothetical team roughly $180,000 of its $600,000 annual budget, then automating the mechanism that makes upgrades expensive — the two-month delete-and-rebuild cycle — is automating away the specific line item the $600,000 number was priced to cover. A Cluster API-managed fleet doesn't need a person budgeted to survive the next minor version. The reconciliation loop is the person.
Version upgrades aren't the only manual-toil item CNCF's 30% figure covers, either — certificate rotation is another perennial entry on every "why Kubernetes needs a babysitter" list. It's already inside the job description of Cluster API's KubeadmControlPlane provider, which renews control-plane certificates as a normal part of the same reconciliation loop that now handles in-place updates — one fewer runbook a platform team has to maintain, test, and eventually forget to update.
What a Single Docker Host Structurally Can't Match
This is where "Kubernetes-native" earns its keep against Coolify, Dokku, and CapRover specifically, not against Docker in the abstract.
| Coolify / Dokku / CapRover | Cluster API-backed PaaS (e.g. bex) | |
|---|---|---|
| Node lifecycle | Manual — SSH in, patch, restart; multi-server bolted on later and mostly hand-managed | Declarative — a Machine/MachineSet object; a dead node is detected and replaced automatically |
| Version upgrades | Whatever the underlying Docker host requires, done by hand | In-place updates (CAPI v1.12) — patched, not torn down and rebuilt |
| Failure mode at scale | Lost box = full downtime until a human rebuilds it | Reconciliation replaces the failed Machine without a human involved |
| Path past one VPS | Re-platform to a different tool entirely | Add nodes to the same declarative fleet — no migration |
That last row is the one byteiota's framing has no answer for, because it isn't a cost question, it's an architecture question. A team that starts on Coolify or Dokku because it's genuinely the right call at their size doesn't get a smooth on-ramp when they outgrow it — they get a re-platforming project, onto a different tool, with a different deploy model, usually while customers are already live. A team on a Cluster API-backed PaaS never hits that wall, because "add capacity" and "start a second box" were never different operations to begin with.
And the infrastructure cost of running that CAPI-managed alternative is nowhere near $600,000. A minimally viable fleet is a handful of small machines — an HA control plane plus workload nodes, the kind of footprint that runs on Hetzner boxes costing tens of euros a month combined, not three senior salaries. The $600,000 was never the price of the orchestration. It was the price of a team hand-building what Cluster API's reconciliation loop now does as its actual job.
PaaS UX First, Kubernetes Underneath — Not Either/Or
None of this means Coolify, Dokku, or CapRover are wrong tools. A solo developer running one SaaS product on one VPS, with no near-term second machine on the roadmap, gets nothing from declarative multi-node lifecycle — it's machinery solving a problem they don't have. Byteiota's under-50-engineers, under-$2M-cloud-bill line is a perfectly reasonable place for that team to sit, for a year or three, without apology.
The question that actually sorts teams isn't "PaaS or Kubernetes" — it's whether a team can already answer three things without flinching: is a second machine on the roadmap in the next year; does losing the current box mean real downtime or a five-minute failover; and is the person who'd run the next version upgrade by hand still at the company by the time it's due. Answer no to all three, stay on a single box — Coolify or Dokku will serve fine. Answer yes to any one of them, and the byteiota math starts working against a hand-rolled cluster too, just not in the direction it argues: the fix isn't "stay simple forever," it's "get the growth path without hiring the $600,000 team to build it."
The honest framing isn't "PaaS beats Kubernetes" or its mirror image "just use Kubernetes." It's that the byteiota critique is really an argument against a specific bad decision — standing up a bare EKS or GKE cluster and staffing three senior engineers to keep it alive by hand — and that decision was already a bad one before any of this. The decision the piece never considers is a third option: git-push deploys with PaaS-simple UX, backed by a Cluster API fleet that treats node lifecycle, healing, and now in-place upgrades as its actual product, not as a runbook three people execute at 2 a.m.
That's the gap bex is built to sit in — git-push deploys on a real Cluster API Provider Hetzner fleet you own outright, so the upgrade cycle that costs other teams two months and $180,000 a year is just something the reconciliation loop does. The source is on GitHub if you'd rather stop choosing between "one fragile box" and "a platform team you can't afford yet."
Sources:
- PaaS First: Why 2026 Marks the End of Defaulting to Kubernetes — byteiota
- Kubernetes Is Overkill: 90% Don't Need It — byteiota
- Cluster API v1.12: Introducing In-place Updates and Chained Upgrades — Kubernetes Blog
- Cluster API v1.12: Introducing in-place updates and chained upgrades — CNCF Blog
- Upgrading management and workload clusters — The Cluster API Book
- Docker vs Kubernetes in 2026: When to Use Each — tech-insider.org
- Kubernetes Gets Smarter Upgrades As Cluster API v1.12 Automates Lifecycle Operations — Open Source For You