Dora NodaTwo blog posts went semi-viral in developer circles this year with nearly the same headline: "PaaS-First: Why 2026 Marks the End of Defaulting to Kubernetes" and "PaaS-First in 2026: Why Kubernetes Is Now the Exception." Neither is wrong about the trend. After a decade of "everyone needs Kubernetes" as the default answer, the pendulum has swung — teams are choosing tools that ship fast over tools that maximize flexibility, and the implicit heroes of that story are single-server tools like Dokku, CapRover, and Coolify.
Here's the part that framing quietly skips: a platform can give users the exact PaaS experience those posts are describing — git push, a running HTTPS service, no YAML — while running Kubernetes underneath, via Cluster API, for the operator. That platform isn't the thing the 2026 consensus rejected. It's the thing the consensus was implicitly asking for, once you separate "who touches Kubernetes" from "what's built on Kubernetes." The rest of this post makes that distinction concrete, with a table you can check against any tool on your shortlist.
What the "PaaS-First" Numbers Are Actually Measuring
Start with what's actually driving the consensus flip, because the case is real. A useful illustrative scenario: running Kubernetes with 24/7 operational coverage takes on the order of four dedicated engineers, which at a roughly $141,000 average U.S. DevOps salary works out to about $564,000 a year in headcount alone — before the cluster has scheduled a single tenant workload. That's one scenario, not a universal constant; the number moves with team seniority, region, and how much of the stack is managed versus self-hosted. But the direction is consistent across every 2026 write-up on the topic: CNCF survey data puts the maintenance tax at 58% of platform-engineering teams' time going to Kubernetes upkeep rather than product work, and an average 2026 cluster now carries on the order of 47 control-plane components, a dozen CNI plugin choices, and four CSI driver options — each with its own upgrade path and failure mode.
Read those numbers carefully and notice what they're actually about: they describe the cost of operating a Kubernetes control plane — patching an API server, backing up etcd, tracking CNI compatibility matrices, staffing an on-call rotation for cluster upgrades. They say nothing about what a tenant deploying an app onto that cluster experiences, and nothing about what runs underneath the tool the tenant uses. "PaaS-first" articles conflate the two because, for the tools they're comparing, the two happen to be the same team. That's an artifact of which tools got compared, not a law of infrastructure.
The Single-Server Ceiling: How Dokku, CapRover, and Coolify Actually Avoid Kubernetes
The single-server tools these articles hold up as the correct reaction avoid Kubernetes's complexity by a specific mechanism worth naming: they remove the capability that complexity exists to provide, rather than hiding it behind a better interface.
Dokku is single-server, full stop — no multi-node clustering, no load balancing across machines. If the box it runs on goes down, every app on it goes down with it. That's not a missing feature; it's the entire design, and it's honest about the trade.
CapRover clusters via Docker Swarm, and Swarm has been in maintenance mode for years. Multi-node CapRover setups work, but practitioners consistently describe the failure modes as quiet: a node silently drops out of rotation, and nothing surfaces it until a deploy mysteriously fails to schedule.
Coolify supports multiple servers, but coordinates them over SSH rather than through a real orchestration layer — there's no scheduler making bin-packing or failover decisions on your behalf, no horizontal pod autoscaler responding to load. For a B2B app with traffic that spikes during business hours, or any workload with a genuinely non-linear load pattern, that's a real operational gap, not a style preference.
None of this is a knock on these tools — for a solo developer or small team running a handful of low-stakes apps, that ceiling is a reasonable trade for the operational simplicity they buy. The point is narrower: these tools "solve" Kubernetes's complexity problem by opting out of what Kubernetes provides (declarative multi-node scheduling, self-healing, horizontal autoscaling), not by proving that complexity was optional for any workload that eventually needs those things.
Three Layers, One Table: Who Actually Holds the Complexity
This is the comparison the "PaaS-first" framing collapses into one axis. It isn't one axis — it's two: does the tenant touch Kubernetes, and does anyone, anywhere in the stack touch Kubernetes.
| Tenant touches K8s? | Operator touches K8s? | Multi-node failover / autoscale? | |
|---|---|---|---|
| Raw Kubernetes (tenant writes their own manifests) | Yes | Yes | Yes |
| Single-server PaaS (Dokku, CapRover, Coolify) | No | No | No — capped at Swarm-level or single-host |
| Cluster API-backed PaaS | No | Yes | Yes |
The "PaaS-first" consensus is entirely correct about column one: tenants shouldn't write Kubernetes manifests to deploy an app, and 2026 is right to treat that as settled. But it's silently equating column one with column two, and those are different claims with different owners. A single-server PaaS answers "no" to both by giving up column three. A Cluster API-backed PaaS answers "no" to column one and "yes" to column two — the tenant still never sees a YAML file, but the fleet still gets real multi-node scheduling, self-healing, and failover, because someone with the specialization to run it well is doing so on the tenant's behalf.
That's the row the "PaaS-first, Kubernetes-is-the-exception" articles never put on the table, because none of the tools they compared occupy it.
What Cluster API Concretely Buys the Operator (So the Tenant Doesn't Have To)
It's fair to ask whether a Cluster API-backed operator is just quietly rebuilding the operational burden the single-server tools escaped. The honest answer is: not from scratch, and not the whole burden — Cluster API is specifically the part of the stack that turns "manage N machines across a cloud provider's bespoke API" into "manage N machines through the same declarative, Kubernetes-style CRDs you already use for everything else." Cluster API Provider Hetzner (CAPH) is the concrete example: instead of hand-scripting Hetzner Cloud API calls to provision a server, wait for it to boot, join it to a cluster, and watch for it going unhealthy, an operator declares a HetznerCluster and a set of Machine resources, and CAPH's controllers reconcile reality to match — provisioning bare metal or cloud servers, wiring them into the cluster, and replacing them automatically when a Machine Health Check flags one as unresponsive.
That's the specific thing a bespoke single-server tool would otherwise have to hand-build if it ever grew multi-node ambitions: its own provisioning logic, its own health-check loop, its own node-replacement code — one more bespoke system to maintain per platform, rather than one well-tested reconciler shared across the entire Cluster API ecosystem (CAPH is one of dozens of infrastructure providers built against the same core API). Kubernetes managing Kubernetes sounds like recursion for its own sake until you notice what it's actually hiding: the messy, provider-specific parts of the stack — cloud APIs, machine lifecycles, health semantics — collapse into one thing behind a boundary the operator controls, and the tenant never has to know it exists.
Why "PaaS-First" and "Built on Kubernetes" Were Never in Tension
Here's the honest version of the counterargument, because it deserves a direct answer rather than a dodge: doesn't running Kubernetes underneath just relocate the operational burden onto the platform vendor instead of eliminating it?
Yes. Completely correct — and that's not a flaw in the argument, it's the argument. Infrastructure complexity capable of delivering multi-node failover and real autoscaling doesn't have an option where it simply vanishes; someone has to own it. The only question worth asking is who, and how many times does it get paid for. In the single-server model, every team that outgrows a single box either hits the ceiling or re-derives its own answer to "how do I run this reliably across multiple machines" — paying the complexity tax once per team, forever. In a Cluster API-backed PaaS, one operator pays that tax once, gets good at it, and amortizes it across every tenant on the fleet. The tenant experience — git push, a running HTTPS service — looks identical to what a single-server tool offers. What's different is invisible by design: underneath, the platform is doing the multi-node, self-healing, provider-abstracted work a single-server tool structurally can't.
"PaaS-first" was always a claim about the interface a tenant should have to deal with. "Built on Kubernetes" is a claim about what implements that interface for the operator. Once you hold those as separate claims instead of collapsing them into one, there was never a contradiction to resolve — just two different tools that made two different trades, wearing the same "PaaS" label.
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 doing the multi-node work underneath so you never have to write a manifest. Star the repo on GitHub or deploy your first app today.
