Dora NodaHN has been asking "do I need Kubernetes?" for the better part of a decade, and in 2026 the skeptics sound like they are winning. "I Didn't Need Kubernetes, and You Probably Don't Either" drew a crowd. "Kubernetes is a red flag signalling premature optimisation" drew a bigger one. The current consensus in the threads goes roughly like this: a PaaS is the default, Kubernetes is the exception, and for 95% of workloads Docker Swarm, Nomad, or systemd on a VPS is all the orchestration anyone needs.
Here is the answer up front, because the threads rarely state it plainly: no, you almost certainly do not need to run Kubernetes. But that was never the actual choice. The argument conflates two completely different things — operating a Kubernetes cluster yourself versus owning an opinionated PaaS that happens to run on Kubernetes you never touch. The backlash is aimed at the first. The second is what removes the burden the backlash is complaining about, without handing your infrastructure back to a vendor.
| Question the threads ask | Question you should answer instead |
|---|---|
| Should I learn YAML, run etcd, and babysit upgrades? | Do I want a git push surface I own, on machines I own? |
| Is Kubernetes overkill for my app? | Does my platform survive the second machine? |
| Swarm vs Nomad vs systemd? | Who reconciles the fleet when a box dies at 2 a.m. — me, or a control loop? |
The rest of this post is the evidence: what the backlash is actually reacting to, the taxonomy of self-hosted platforms the debate keeps ignoring, the concrete second-machine test, and what changes when the Kubernetes under your PaaS is declaratively owned instead of manually operated.
What the backlash is actually about
Strip the rhetoric from the 2026 threads and the grievances are specific, legitimate, and — this is the key point — all felt by exactly one role: the person operating the cluster.
YAML sprawl. A simple web app becomes a Deployment, a Service, an Ingress or Gateway, a certificate object, a secret store, and a pipeline to keep them in sync. Fair. Nobody asking for a PaaS should be writing any of that by hand.
Upgrade breakage. Kubernetes keeps a firm deprecation calendar, and it bites operators who drift. The v1.37 cycle is a live example: kubelet flags whose removal was deferred from v1.36 are gone for real, and a node still passing a removed flag does not degrade gracefully — it fails to start. On a managed cloud this is the provider's problem. On a hand-rolled cluster it is yours, discovered at the worst possible moment.
Control-plane care and feeding. etcd snapshots, compaction, quorum, certificate rotation. The datastore underneath every cluster needs backups that somebody actually tested, and "somebody" defaults to you.
Now notice who does not feel any of this: the tenant of a good PaaS. Nobody pushing to Heroku, Railway, or Render has ever compacted etcd or audited a kubelet flag. The backlash takes pain that belongs to cluster operators, points it at everyone, and concludes the substrate itself is the problem. That is like concluding relational databases are overkill because running your own replication topology is hard — while your app happily queries a managed Postgres.
So the honest version of the 2026 consensus is narrower than its slogans: operating Kubernetes by hand is overkill for most teams. Agreed, completely. The threads then leap from that true statement to "therefore run your PaaS on a single Docker box," and that leap is where things start breaking.
The taxonomy the debate keeps ignoring
The debate is usually framed as two camps: Kubernetes maximalists versus simplicity realists with a VPS. But the self-hosted PaaS ecosystem already sorted itself into two substrates years ago, and the awesome-list taxonomy shows it — the same "self-hosted PaaS" category mixes tools with fundamentally different foundations:
| Tool | Substrate | Multi-machine story |
|---|---|---|
| Dokku | Plain Docker, one server | None by design — the original mini-Heroku, one box |
| CapRover | Docker Swarm | Swarm clustering since the early days, containers scheduled across nodes |
| Coolify v4 | Docker over SSH per server | Dashboard manages many servers, but each app is placed on a box by hand; full clustering is the undated v5 roadmap |
| Dokploy | Docker Swarm + Traefik | Multi-server exists but demands a registry, same-architecture nodes, and manual care — no automatic storage cleanup on extra nodes |
| Kubero | Kubernetes + GitOps | Real scheduler, real self-healing — but you bring the cluster |
This table is the whole debate in miniature. The "simplicity" camp is not one thing: CapRover and Dokploy already conceded that one box is not enough and reached for Swarm, the simplest real scheduler available. The Kubernetes-backed entries conceded the opposite — that once you need scheduling, self-healing, and declarative state, you might as well stand on the orchestrator with the deepest ecosystem.
And here is the tell: every tool on the Docker side of that table eventually re-implements, badly, a subset of what the other side gets for free. Health checking and rescheduling. Placement and bin-packing. Ingress shared across machines. The simplicity was never in the architecture — it was in deferring the hard problems until the second machine arrives.
The second-machine test
Forget philosophy. Here is the concrete experiment the TODO item demands: you adopted a single-box tool for your first app, business is good, and now you need a second machine. What breaks?
Nothing provisions the machine for you. There is no declarative node lifecycle — no object that says "this fleet has two machines" and makes it true. You provision the VPS by hand, install Docker by hand, join it to whatever clustering exists by hand. Every future machine repeats the ritual, including the drift.
Your images need a registry now. On one box, the image you built is sitting right there. The moment a second node must pull it, you need a registry every node can reach, credentials on every node, and a deploy path that authenticates everywhere. Dokploy's docs say this outright — multi-server requires a registry and same-architecture servers — and its issue tracker carries the scars of Swarm's rough edges: registry credentials that do not propagate on scale operations, Docker version skew between Swarm nodes breaking overlay networking, Traefik state coupled to one node's filesystem.
Storage and state go sideways. Volumes live on one machine's disk. Dokploy does not perform automatic storage cleanup on extra nodes. Stateful anything — the database your PaaS one-click-installed — is suddenly a placement constraint you manage in your head: never let that container move, because its data cannot follow.
Failure handling is you. When the box dies at 2 a.m., nothing reschedules, because there is no scheduler with a global view — only per-server Docker daemons and a dashboard that can no longer reach one of them. Coolify's own v5 roadmap is the market's honest confession here: the most popular single-box PaaS on the planet, tens of thousands of stars, named multi-server scalability as its headline feature — with mesh networking and a host agent as the plumbing. Plumbing is not a scheduler, and there is still no date.
None of this means single-box tools are bad. It means they are one-box tools: superb until the workload outgrows the box, with no declarative bridge to what comes next. The migration off them is a replatforming, not an upgrade — new substrate, new networking model, new failure semantics, all discovered under pressure.
What Cluster API changes — and when one box is honestly enough
Cluster API exists for exactly the seam above. It turns "the fleet" into declarative objects — Cluster, MachineDeployment, Machines — reconciled by controllers against infrastructure providers, including providers for bare metal and Hetzner-class dedicated hardware. Adding a node stops being a runbook and becomes a field:
# before: provision a VPS, SSH in, install Docker,
# join the Swarm, verify overlay networking, register
# the node in the dashboard, place apps by hand
# after:
replicas: 3 # was 2 — the controllers do the restThat one-field diff is doing a lot of quiet work: provisioning the machine, bootstrapping it, joining it to the cluster, and converging it to the declared state — continuously, not once. Configuration drift, the thing that turns every hand-built fleet into snowflakes, becomes something the control loop grinds away instead of something you audit quarterly. The kubelet-flag removal that ruins an operator's weekend? It is a manifest change rolled out by machine replacement, with the old nodes drained first — the same boring mechanism as every other upgrade.
Crucially, none of this is visible to the developer pushing code. The git-push surface sits on top — build from a repo, get a running HTTPS service — and the Kubernetes underneath is something the platform owns, not something its users operate. That is the distinction the HN threads collapse: the developer experience of Heroku with the ownership model of hardware you control. Kubero already demonstrates the shape — a Heroku-style layer that assumes Kubernetes rather than apologizing for it.
But intellectual honesty cuts both ways, so here is the concession the backlash deserves: if you have one app, one server, predictable load, and no second machine on any roadmap, the single box wins. Dokku or a Compose file on a VPS is cheaper, simpler, and faster to set up than any fleet will ever be. Kubernetes-backed ownership pays off at the second machine, the first 2 a.m. page, the first compliance questionnaire about failover — not before.
Adopting a fleet for a side project is exactly the premature optimisation the threads warn about. Adopting a single box for a business that will need a fleet is the same mistake in the other direction: optimizing for day one and replatforming on day two hundred.
A workable decision rule:
- Stay on one box while one machine holds your load with headroom, downtime tolerance is measured in hours, and the team is you.
- Move to owned fleet when you need two machines, when a dead box must heal without you, or when "who can provision infrastructure" needs to be a manifest review instead of SSH access.
Look forward a year and the direction is clear. The single-box tools are all walking toward clustering — Coolify's v5, Dokploy's multi-server, CapRover's Swarm since day one — because their users keep hitting the same ceiling. The Kubernetes side is walking toward invisibility: Gateway API replacing annotation soup, in-place pod resizing removing restart churn, fine-grained kubelet authorization narrowing break-glass access. Both sides are converging on the same destination from opposite directions: infrastructure you own, surfaced as a push, where the orchestrator is a fact rather than a hobby. The only question is whether you arrive there by replatforming under pressure or by starting on the substrate that already goes there.
Curious where you sit on that curve? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
