Dora NodaCoolify has 52,000+ GitHub stars and 325,000+ reported users. CapRover has been running production apps since 2017. Both are held up in 2026 as proof that the self-hosting default should be a single-node PaaS, with Kubernetes reserved for the rare team that actually needs it. The argument is everywhere this year: pick a Docker-based tool, treat kubectl as a last resort, and you've dodged the complexity tax.
That argument quietly conflates two different things. "Kubernetes as a thing a team hand-operates" — writing YAML, running kubeadm, debugging etcd at 2 a.m. — is genuinely a tax most teams shouldn't pay. But "Kubernetes as the substrate underneath a platform's own UX" is a different claim entirely, and it's one the PaaS-first framing never engages with. Render runs on Kubernetes. Railway runs on Kubernetes. Heroku's Fir generation is built on Kubernetes. None of their users ever see it. The real choice in 2026 was never "PaaS or Kubernetes" — it's whether the Kubernetes underneath your PaaS is something you have to learn, or something the platform already absorbed on your behalf.
Where the PaaS-First Case Is Actually Right
Give it its due first. For a team shipping one to twenty apps off a single VPS, Coolify's pitch is close to unbeatable: point it at a $6/month box, connect a GitHub repo, and you have Heroku-style git push deploys, one-click databases, and automated SSL in an afternoon. CapRover has run the same playbook since 2017 with a smaller footprint. Neither requires you to know what a Deployment or a Service is. For that workload — no multi-region requirement, no compliance-driven HA mandate, one operator who is also the whole ops team — a single-node PaaS is not a compromise. It's the correct tool, and Kubernetes would be pure overhead.
The PaaS-first argument stops being descriptive and starts being prescriptive the moment it generalizes "correct for a single box" into "the default, with Kubernetes as the exception." That's the part worth pressure-testing, because it's exactly the point where these tools' architecture stops matching the claim.
The Ceiling the Narrative Doesn't Show You
Both flagship PaaS-first tools hit the same wall once "single box" stops being true, and it's a structural wall, not a rough edge that'll get sanded down in the next release.
Coolify's multi-node story is built on Docker Swarm. Reviewers who've run it past one node describe it plainly: workable for a small handful of servers, but "rough," with production HA requiring "more glue than you'd expect." There's no Kubernetes path once you outgrow it and no service mesh — Swarm is the ceiling, not a step toward one. CapRover supports Swarm clustering out of the box, which sounds like the harder problem solved, until you read how its failure modes are actually described: "quiet and painful." Swarm itself isn't dead — Mirantis has committed to supporting it through 2030 — but that's single-vendor stewardship of a niche orchestrator, not the multi-cloud, multi-vendor ecosystem of controllers, operators, and cloud-provider integrations that's grown up around Kubernetes since Swarm effectively stopped gaining new adopters years ago.
Concretely, here's what a single-node-first tool structurally doesn't give you, and what the Kubernetes side of the fence has had production-grade for years:
| Failure scenario | Coolify / CapRover (Swarm) | Cluster API–managed fleet |
|---|---|---|
| A node goes unresponsive | Manual detection, manual intervention; CapRover's Swarm failure modes are described as "quiet and painful" | MachineHealthCheck detects the unhealthy node and triggers automatic remediation |
| Rolling out a new node image / OS patch | No first-class primitive; ad hoc scripting across the fleet | MachineDeployment performs a declarative rolling replace, one node at a time |
| Scaling past a handful of servers | Swarm is described as "a hard ceiling if you outgrow it" | Fleet size is a spec field; the same reconciliation loop manages 3 nodes or 300 |
| Cross-node service routing / isolation | No built-in service mesh | Kubernetes' native Service/Ingress model, extensible with a mesh if needed |
None of this means Coolify or CapRover are badly built — they're solving a genuinely different problem (single-box simplicity) with tools scoped to that problem. It means the "just avoid Kubernetes" advice silently expires the moment a team's node count or uptime requirement moves past what a single box, or a Swarm cluster held together by hand, was ever designed to carry.
The Platforms Built on Kubernetes You Never See
Here's the part the PaaS-first framing skips entirely: the tools it holds up as the alternative to Kubernetes-based platforms are themselves competing against platforms that run on Kubernetes and simply never show you the seams. Render's infrastructure is Kubernetes underneath a git push interface. Railway's is too. Heroku's newer Fir generation — the direct successor to the platform that popularized git push heroku main in the first place — is explicitly Kubernetes-native. Users of all three type git push and get a running service back. Nobody is handed a kubeconfig.
That's not an accident of scale that only hyperscale vendors can pull off — it's what Cluster API was built to make reproducible for anyone. Cluster API Provider Hetzner (CAPH) reached its 1.0 GA in October 2024 after four years of development, and by GA it was already running in production across hundreds of organizations. Pair it with Talos Linux — an immutable OS with fewer than 50 binaries, whose entire node bootstrap is a single talosctl bootstrap command on the first control-plane node, with every subsequent node joining automatically — and a local cluster is up in under a minute, from two commands. That's not a materially higher-friction starting point than pointing Coolify at a fresh VPS. The difference isn't day-one friction; it's what's waiting on day 400, when node count or uptime requirements move.
Teams have already proven this transition happens at real scale outside the demo: a KubeCon EU 2025 talk documented migrating 35 production clusters, in an air-gapped environment, off hand-rolled kubeadm/Ansible/Puppet provisioning and onto Talos nodes managed declaratively through Cluster API. That's the tax the PaaS-first argument is actually afraid of — hand-operated Kubernetes, kubeadm and configuration-management scripts stitched together by a team that has to own every failure mode — being reduced to a MachineDeployment spec someone else's reconciliation loop keeps healthy.
Who Actually Carries the Kubernetes Tax
The honest version of this isn't "Kubernetes is free now." A Cluster-API-managed fleet still has real operational surface — someone has to run the management cluster, watch the CAPH controller, and own the CRDs that describe the fleet. That work doesn't vanish; it moves. The question that actually separates the two camps isn't PaaS-vs-Kubernetes, it's who's holding that surface:
- Hand-operated Kubernetes: your team learns
kubeadm, etcd operations, CNI selection, and upgrade sequencing from scratch. This is the tax the PaaS-first case correctly warns teams away from. - Single-node PaaS (Coolify, CapRover): nobody learns Kubernetes, but nobody gets
MachineHealthCheck-style self-healing or a rolling-replace primitive either — the ceiling described above is what you're trading for that simplicity. - A platform built on a Cluster-API-managed fleet: the declarative Machine/MachineDeployment layer absorbs the multi-node lifecycle work the same way Render's or Railway's control plane does internally — except the fleet runs on hardware you own, at Hetzner-class pricing, instead of inside a vendor's metered black box.
That third option is exactly what bex.co is: an open-source, AI-native Render alternative — push a git repo, get a running HTTPS service, on a Cluster-API-managed fleet you own rather than rent. The git push experience is identical to what a single-node PaaS gives you on day one. The difference only shows up the day a node dies at 2 a.m. or the fleet needs to grow past what one box, or one Swarm cluster, was ever going to carry — and by then, whether that difference was designed in from the start isn't something you can retrofit.
The Real Axis of Choice
"PaaS-first, Kubernetes as the exception" is good advice read narrowly: don't hand-operate a Kubernetes cluster if your workload doesn't need one. It's misleading advice read as the industry seems to be reading it in 2026: that avoiding Kubernetes and avoiding complexity are the same decision. Render, Railway, and Heroku Fir are the counter-evidence sitting in plain sight — three platforms with exactly the git push simplicity the PaaS-first case wants, running on the exact substrate it tells you to avoid. The question worth asking about any platform, self-hosted or not, was never "does it use Kubernetes." It's "who's operating the Kubernetes underneath, and did they design for the day you outgrow node one."
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 a Cluster-API-managed fleet instead of a single box with a ceiling. Star the repo on GitHub or deploy your first app today.
Sources
- Best Self-Hosted PaaS Platforms in 2026: Coolify vs CapRover vs Dokploy vs Server Compass
- Dokploy vs Coolify vs CapRover in 2026: Which Self-Hosted PaaS Fits Your Stack?
- Coolify vs CapRover: Which Self-Hosted PaaS Wins in 2026?
- Mirantis Commits to Long-Term Support for Swarm Through 2030
- Cluster API Provider Hetzner — GitHub
- What is the Cluster API Provider Hetzner — CAPH Docs
- Talos Linux: Bare metal to Kubernetes in under a minute
- Talos Linux: Bringing Immutability and Security to Kubernetes Operations — InfoQ
All figures and claims cited above are drawn directly from the linked sources.
