Dora NodaSomewhere in 2026, the default advice on Hacker News quietly flipped. For a decade, the answer to "how should we deploy this?" was some variant of "just use Kubernetes." Now the top-voted answer is usually the opposite: start on a PaaS, and reach for raw Kubernetes only when you have a scaling problem that actually demands it.
The verdict, in three sentences: the PaaS-default crowd is right about the developer experience and wrong about the substrate. What they are rebelling against is operating Kubernetes by hand, not Kubernetes itself — the declarative, self-healing, portable machinery underneath is the part worth keeping. So the winning shape is not PaaS instead of Kubernetes but PaaS on top of Kubernetes: a git-push golden path with the full substrate one layer down for the day you outgrow it.
| Question the title asks | Short answer (substantiated below) |
|---|---|
| What is the pro-PaaS argument actually objecting to? | YAML sprawl, day-2 ops surface, and the learning-curve tax on a small team — not declarative infrastructure itself |
| What is it NOT objecting to? | Desired-state reconciliation, self-healing, and portability off a single vendor or box |
| When is raw Kubernetes the right call? | Multi-cluster, multi-team, or specialized-scheduling needs — the genuine exception |
| Where does a Kubernetes-native PaaS fit? | It is the default path that keeps the exception available without a replatform |
That table is the whole article in miniature. The rest of this post substantiates every row — including the strongest case against its own conclusion.
What the PaaS-default crowd is actually objecting to
Read a dozen "don't use Kubernetes" threads and three concrete complaints recur. They are worth enumerating precisely, because each one locates the pain in operating Kubernetes, not in its ideas.
1. YAML sprawl and API surface area. A production workload on raw Kubernetes is never "a container." It is Deployments, Services, Ingresses, certificates, NetworkPolicies, resource quotas, autoscalers, and the CD pipeline gluing them together — each with its own schema, versioning, and failure modes. Matthias Endler's widely shared "Maybe You Don't Need Kubernetes" essay made this the canonical objection years ago, and the 2026 threads repeat it: a two-person team ships a CRUD app and inherits a distributed-systems API surface to babysit. One 2026 account put it bluntly: "self-hosted Kubernetes means the same base Linux box configuration, plus setting up k8s, plus the networking — and that's the point."
2. The day-2 operations burden. Setup is the easy part; upgrades, incident response, and cost control are the tax. Komodor's 2025 Enterprise Kubernetes Report found nearly 80% of production outages trace back to system changes — upgrades, deploys, config edits — rather than the infrastructure itself failing. Platform-engineering roundups summarizing Spectro Cloud's 2025 data report 88% of teams seeing year-over-year TCO increases, with cost the number-one challenge at 42% and three-quarters saying complexity inhibits adoption. A 2026 summary of CNCF survey data tells the same story from the incident side: roughly 80% of Kubernetes-related incidents stem from operational complexity, not infrastructure failure. The numbers disagree on decimals but agree on direction: Kubernetes is mature, but running it well is still a discipline, and the discipline is what bills you.
3. The learning-curve tax on a small team. The same roundups put the staffing cost of a production Kubernetes platform team at 3–15 full-time engineers — $450K to $2.25M a year in labor alone before a single app ships. A two-person startup cannot spend that, so it spends the scarcer currency instead: founder attention. Every hour spent debugging why a network policy blocks Grafana is an hour not spent on the product. The PaaS-default argument is, at bottom, an attention-allocation argument — and for a team of two, it is nearly unanswerable on those terms.
Note the shape of all three objections. None of them says "declarative infrastructure is bad." None says "I wish my app stayed down when the process crashed." They say: this machinery costs more attention than my team has. That distinction is the hinge of the whole debate.
What they are NOT objecting to
Here is the tell. Ask the "we don't use Kubernetes" crowd what they run instead, and the answers rhyme: Render, Railway, Fly.io — or a Docker Compose box behind a deploy script. And ask what those platforms do, and the description is Kubernetes' feature list with the YAML filed off: desired state declared somewhere, unhealthy processes restarted automatically, traffic shifted without downtime, the app portable away from any single machine.
As one 2026 piece distilled it: most "we don't use Kubernetes" claims actually mean "we wrapped Kubernetes so developers never see it." The substrate properties survive every migration story:
- Declarative desired state. Nobody migrates off Kubernetes demanding more snowflake servers. The teams that leave for a PaaS keep GitOps-shaped workflows — repo as source of truth, diffs as deploys — because declaring what should exist beats SSH-ing into what does.
- Self-healing reconciliation. The complaint is never "my pods restarted themselves." Crash loops, failed health checks, rescheduling onto healthy nodes — every PaaS reimplements this loop, because the alternative is pagers.
- Portability off a single vendor or box. Teams flee Heroku-style lock-in toward platforms they can leave. The objection is to being trapped, not to the orchestrator abstraction — which is precisely why the "just a VPS and Compose" answer eventually hits its own wall, as the next section concedes honestly.
So the rebellion is narrower than its slogans. Developers are not voting against orchestration, reconciliation, or portability. They are voting against personally operating the machine that provides them. Any honest resolution of the debate has to preserve the three properties above while removing the three burdens in the previous section.
The steelman: the case for never-Kubernetes, stated fairly
Before arguing for Kubernetes-underneath, steelman the other side — because for a large class of teams, "never Kubernetes" is genuinely the right answer, and this post would be marketing rather than analysis if it pretended otherwise.
The win is real and measurable. Developers who leave self-operated clusters for managed PaaS report the kind of numbers that end arguments: one widely shared 2026 account describes moving from Kubernetes to Render, saving roughly $3,800 a year in direct costs while shipping noticeably faster with the ops burden gone. Entry pricing explains why: Render and Railway start around $5–7 a month per service, Fly.io prices similarly at the low end, and a single small VPS can host a handful of services for tens of dollars a month. Against a platform-team salary band starting near half a million dollars, this is not a close fight. If your workload fits on one box or inside one vendor's guardrails, the rational move is to rent the golden path and spend your attention on the product. Full stop.
Single-box Docker PaaS tools extend that win to owned hardware. Coolify, Dokploy, and Dokku give a team the Heroku-shaped "push and get a URL" flow on a VPS they rent for pocket change, with no per-service meter running. For side projects, MVPs, and small SaaS products with predictable traffic, this is arguably the best deal in infrastructure: vendor independence plus PaaS ergonomics at VPS prices. Nothing in this post disputes it.
The breaking point is the second machine. Here is where the honest accounting turns. Single-box tools solve "manage the box you already have" and stop there: no fleet-wide node provisioning, no declarative machine lifecycle, no story for what happens when one server is not enough — or when it dies at 3 a.m. and its replacement needs to exist by 3:15.
The team that adopted a single-box tool for its first app discovers, at the worst possible moment, that scaling means replatforming: new substrate, new deploy flow, new failure modes, learned under pressure. Managed PaaS defers the same cliff differently — the price ladder (a few dollars per service, then tens, then a Heroku-scale bill with no free tier left) and the guardrails (sleeping instances, connection caps, no GPUs on demand) decide your architecture for you until leaving means rewriting it.
And the obvious counter — "doesn't Kubernetes underneath just reintroduce the tax?" — needs a direct answer. Yes, if every team operates its own cluster per app: a private Kubernetes install per service is the worst of both worlds, all of the YAML with none of the amortization. The tax stays gone only when the complexity is paid once, by the platform, and amortized across every team on the golden path. The concrete exhibit is Cloud Foundry's Korifi: cf push against a Kubernetes cluster, with orgs, spaces, and service bindings expressed as Kubernetes RBAC and CRDs the developer never touches. The developer's total Kubernetes surface is zero commands; the operator's is one fleet instead of N snowflakes. That asymmetry — platform pays once, tenants pay nothing — is the entire economic argument, and it fails exactly when the asymmetry collapses. State the boundary plainly: hidden Kubernetes that each tenant still has to feed and water is not a PaaS, it is a timeshare on toil.
The false choice: PaaS versus Kubernetes misframes the stack
With the steelman conceded, the framing error becomes visible. "PaaS vs. Kubernetes" compares a user experience with a substrate, as if choosing a restaurant meant voting against farms.
The stack has layers, and the debate is really about which layer a small team should touch:
- The app UX layer — push code, get a URL, env vars, logs, rollbacks, preview environments. This is what developers touch daily, and it should be a PaaS.
- The substrate layer — scheduling, reconciliation, networking, storage, machine lifecycle. This is what absorbs failures at 3 a.m., and Kubernetes is the best-tested open implementation of it we have.
Every "we left Kubernetes" story that ends happily is a story about moving up a layer, not about the lower layer disappearing. Gartner's oft-cited forecast — 80% of software engineering organizations running dedicated platform teams with internal developer platforms by 2026, up from 55% in 2025 — describes exactly this migration at enterprise scale: Kubernetes stays, and a PaaS-shaped platform gets built in front of it so product engineers never file a ticket against a YAML file. Korifi does it for the Cloud Foundry experience; internal developer platforms do it per company; Kubernetes-native PaaS products do it as the product itself.
The practical payoff is the escape hatch. When a team on a Kubernetes-substrate PaaS outgrows the golden path — needs a custom operator, a GPU scheduling policy, a multi-cluster topology — it drops one layer down into APIs and primitives that already run its workloads, with the same manifests, the same tooling, the same hiring pool.
When a team on a single-box or closed PaaS outgrows its golden path, it replatforms: the deploy flow, the networking model, and the operational knowledge all get replaced at once. Option value is the product. You buy it by keeping the substrate standard underneath the experience that hides it.
Decision guide: which path, honestly
No universal default survives contact with real constraints, so here is the table — including the column where this post's own thesis loses:
| Your situation | Take this path | Why |
|---|---|---|
| Solo dev or 2-person team, CRUD/MVP, traffic fits one box | Managed PaaS (Render, Railway, Fly.io) or single-box tool (Coolify, Dokploy) on a VPS | Cheapest attention cost; the steelman wins outright at this scale |
| Small team, growing SaaS, cost ladder biting, data-residency or margin pressure | Kubernetes-substrate PaaS (self-hosted, git-push, Render-compatible API) on machines you own | Golden-path UX today; standard substrate tomorrow; no replatform at the second machine |
| Multi-team org, platform team exists, many services | Internal developer platform on Kubernetes (build or Korifi-style) | Amortize one platform team across N product teams; Gartner's 80% are here |
| Multi-cluster, regulated, GPU/specialized scheduling, custom operators | Raw Kubernetes (with Cluster API for the fleet itself) | You have the exception the verdict names — operate the substrate deliberately |
Two notes on reading it. First, the middle rows are a ladder, not tribes: a team should be able to climb from row one to row two to row three without rewriting its deploy flow, which is precisely what a standard substrate buys. Second, the bottom row is real. Teams running multi-cluster fleets, regulated infrastructure, or accelerator-heavy AI workloads are not over-engineering — they have the scaling problem the PaaS-default advice exempts, and they should operate Kubernetes with a platform team sized for it (budget the 3–15 FTE band with eyes open, not as a surprise).
The verdict, restated
PaaS should be the default because attention is a startup's scarcest resource. Kubernetes should be the exception as a daily interface — while remaining the standard as the substrate, because every workload eventually wants declarative state, self-healing, and portability.
Replatforming onto those properties under pressure is the most expensive migration of all. The 2026 consensus got the UX right; keep its golden path, and make sure there is rock under it.
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.
