PaaS by Default, Kubernetes the Exception: What the 2026 Consensus Flip Gets Right — and What It Still Gets Wrong

For a decade the default advice was the same sentence with the nouns swapped: every team will need Kubernetes eventually, so you might as well start there.

In 2026 that sentence flipped. Across Hacker News threads, self-hosting roundups, and "you don't need Kubernetes" essays that actually charted this time, the new consensus reads "PaaS by default, Kubernetes the exception." The evidence cited is always the same lineage: Coolify, Dokku, CapRover, Dokploy — single-box Docker PaaS tools that let a small team push a git repo and get a running HTTPS service without ever touching a cluster.

That flip is right about the median team. It is wrong about the choice it implies is binary. A git-push surface and a Kubernetes substrate were never in tension — unless you build the PaaS on a single machine. A platform that exposes Render-style ergonomics on top of Cluster API gives you the thing the new consensus actually wants — PaaS simplicity — without inheriting the one-machine ceiling that makes every single-box tool a migration project the moment you outgrow it.

TL;DR — The flip, the correct insight, and the missing third option​

The core deliverable of this post is the bottom row: why the new binary is false, what concretely breaks when a single-box PaaS meets its second machine, and how a Cluster API PaaS avoids that seam while keeping the same developer surface.

1. What the flip gets right: most teams never needed a cluster​

The old consensus was not irrational — it was overfitted to the companies writing the loudest case studies. Between 2015 and 2023, every "we run Kubernetes in production" post from a FAANG-adjacent team implicitly set the default for a 3-person startup. The operational tax was treated as tuition you pay early for scale you might need later.

The 2026 correction is an empirical one. Three data points keep recurring in the roundups and HN comments that now drive the new default:

• Workload shape. Essays that quantify the threshold — notably a widely-cited March 2026 "you don't need Kubernetes" piece — converge on the same rule of thumb: fewer than 5 microservices, a small engineering team, and under ~10k daily active users is not a Kubernetes-shaped problem. It is a containers-on-one-or-two-machines problem. That describes the median team, not a corner case.

• Cost of the median PaaS vs. the median box. A $5–6/month Hetzner or Hostinger VPS running Coolify hosts what the same workload costs $50–200/month on metered cloud platforms once you add a managed database and egress. Coolify itself wants 2 GB RAM, so a 4 GB VPS ($7–14/month) is the realistic floor, but the order-of-magnitude gap holds. For a side project, an internal tool, or a pre-product-market-fit SaaS, the arithmetic is not close.

• Operational simplicity at the developer surface. Coolify, Dokku, CapRover, and Dokploy all converge on the same primitive: git push → build → HTTPS. Dokku has been quietly reliable for over a decade; CapRover foregrounds one-click apps; Coolify and Dokploy aim for the fuller PaaS surface (databases, previews, multi-project). A developer who never learns kubectl still ships. That is a real win, and the new consensus is correct to center it.

Where the old advice said "learn Kubernetes before you need it," the new advice says "don't pay the Kubernetes tax until the workload demands it." On that, the flip is right — and the burden of proof has properly reversed. The question is no longer "why aren't you on Kubernetes?" It is "what about this workload actually requires you to operate a cluster yourself?"

2. The single-box ceiling: what concretely breaks at the second machine​

Single-box PaaS tools are not lightweight Kubernetes. They are Docker-on-one-host with a nice UI. That is exactly why they are simple — and exactly why the second machine is not an incremental step but a seam where the abstraction leaks.

None of this is a criticism of the tools for their intended shape. Dokku on one VPS is a superb answer to "I have one app and one box." Coolify's multi-server support is real and improving, but the fundamental architecture remains an agent on each host, not a declarative fleet API. The distinction matters when the team that chose "one VPS and done" hires two more engineers, adds a background worker that needs isolation, or lands a customer that requires data residency in a second region.

The cost of that seam is not just operational — it is a migration. The team re-platforms: from Docker-on-one-host to either a hosted PaaS (Render, Railway, Fly.io) with per-service pricing, or to Kubernetes they now have to learn under deadline. The simplicity they bought becomes the migration they pay for.

3. The false binary: PaaS and Kubernetes were never opposites​

The new consensus frames the choice as two poles:

• Left pole: PaaS simplicity (Coolify, Dokku, Heroku-like). You get git push and a URL. You give up fleet control and portability.
• Right pole: Kubernetes. You get fleet control and portability. You give up simplicity and pay the YAML tax.

That diagram has no middle, so every team is forced to pick which tax to pay. The middle exists and has existed for years — it is just not a single-box tool. It is a PaaS whose substrate is Kubernetes but whose surface is not.

Concretely, there are three PaaS shapes, not two:

Shape C is the argument the binary erases. It keeps the left pole's ergonomics — a developer pushes a repo and gets a URL, buildpacks detect the stack, TLS and domains are automatic — while keeping the right pole's property — the fleet is a set of Kubernetes MachineDeployment and Cluster objects that any Cluster API provider can reconcile. The tenant gets portability (the same App CR works on Hetzner today, another provider tomorrow) without ever writing a Deployment manifest.

The HN thread that says "we wrapped Kubernetes so devs never see it — the infra team still runs K8s, but app devs see a polished internal PaaS" is describing Shape C from the inside. The observation "none of these 'alternatives' kill Kubernetes — they wrap it" is precisely the point: wrapping is the feature. Kubernetes is not the exception because teams do not need it; it is the exception because most tenants should never have to operate it directly. The PaaS should.

A note on BYOC: Northflank and Qovery both point at the same insight — put a PaaS control plane on infrastructure you own — but charge $299–$2,099/month for the control plane on top of the cloud bill you already pay. The economic structure is a second layer of margin. A self-hosted PaaS on owned Hetzner capacity has one bill — the hardware — and the PaaS is the fleet's API, not a rented dashboard in front of it.

4. How Bex resolves it: the same git push, without the one-machine ceiling​

Bex is Shape C made concrete: an open-source, Render-compatible PaaS that runs on machines you own, with Kubernetes and Cluster API underneath and invisible at the developer surface.

A developer's interaction looks like any PaaS:

# bex.yml — lives in the repo, no Kubernetes manifest in sight
app: my-api
build:
  type: buildpack   # or dockerfile
env:
  DATABASE_URL: ${postgres.connectionString}
domains:
  - api.example.com

git push bex main
# → build, deploy, HTTPS, logs, rollbacks — same shape as `git push render main`

What the platform operator sees is different. The fleet is declarative Kubernetes objects reconciled by Cluster API Provider Hetzner (CAPH):

# MachineDeployment — "the fleet should be 3 CX22s in fsn1"
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: workers-fsn1
spec:
  replicas: 3
  template:
    spec:
      infrastructureRef:
        kind: HetznerMachineTemplate
        name: cx22-fsn1

Adding a second (or tenth) machine is not "provision a VPS and install the agent." It is replicas: 3 → 4 and kubectl apply. The new host boots, joins the cluster, and the scheduler places workloads. Draining, upgrading, or moving a workload between hosts is a Kubernetes primitive, not a shell session on a specific box.

Operationally, this is why Shape C does not have the single-box seam:

• No migration when you outgrow one host. The same App that ran on a single-node cluster during prototyping runs unchanged on a 10-node fleet in production. The abstraction that was git push on day one is still git push on day 1,000.
• No vendor lock to a hosted PaaS's pricing page. The Render-compatible API means a team can move an app between Render and Bex without rewriting the deployment contract, but the fleet itself is portable via Cluster API — not via a vendor's export button.
• No per-service meter that multiplies with architecture. A hosted PaaS bills every service, preview environment, and build minute separately; a self-hosted fleet bills the Hetzner invoice for the machines — whether they run 3 services or 30. The marginal cost of the next service is scheduling, not a new line item.

This is not an argument that every team should operate Cluster API themselves. It is an argument that the platform should, so the tenant does not have to and does not have to choose between "simple now" and "portable later."

5. So when is Kubernetes actually the exception?​

The new consensus says "Kubernetes the exception." Taken literally, that suggests most teams will never touch Kubernetes at all. A more precise statement is: operating Kubernetes directly should be the exception. Benefiting from Kubernetes — portability, scheduling, declarative fleet lifecycle — should be the default, just invisible.

A practical checklist for the team asking "do we need to see Kubernetes?":

• You should stay on the PaaS surface (any shape) if: fewer than ~5 services, one team, one region, no hard data-residency or compliance requirement that names the substrate, and your scaling story is "a bit more CPU/RAM" not "a different failure domain."
• You should be on Shape C (PaaS on Cluster API) if: you want the PaaS surface and you want to own the fleet — for cost (flat Hetzner vs. per-service meter), for sovereignty (machines in a jurisdiction you chose), or for portability (the same App CR on a second provider next year).
• You should operate Kubernetes directly if: you have a platform team whose product is the platform, you need custom controllers/operators, or you have compliance or networking requirements that genuinely require you to own the control plane's configuration beyond what any PaaS (self-hosted or not) abstracts.

For the vast majority of product teams, the answer is the first or second bullet. The third is the real exception — and it is a staffing and organizational decision, not a technical inevitability. The mistake of the 2015–2023 era was treating the third bullet as the default. The mistake the 2026 correction risks is treating the first bullet as the only alternative, when the second exists and removes the ceiling the first imposes.

6. The consensus was half-right — finish the thought​

The 2026 flip is a genuine correction. Treating Kubernetes as the starting point for every team was wasteful, and the single-box PaaS renaissance proved that most workloads are well-served by git push → URL on a single VPS. The median team should start on a PaaS.

But "PaaS by default" does not mean "single-box PaaS by default." The moment the discourse treats every PaaS as a single VPS with a dashboard, it recreates the very binary it was trying to escape — PaaS or Kubernetes, simple or portable, cheap now or scalable later. That binary was always a product of which tools were demoed, not which architectures are possible.

A PaaS built on Cluster API is the concrete counterexample: the developer never sees Kubernetes, the fleet is Kubernetes all the way down, and the second machine is not a migration. You get the simplicity the new consensus correctly demands without accepting the ceiling it incorrectly treats as inherent to PaaS.

The old wisdom said every team will need Kubernetes eventually, so pay the tax now. The new wisdom says most teams will never need Kubernetes, so never pay the tax. Both miss the shape that actually matches how teams grow: you needed Kubernetes the whole time — you just should never have had to see 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.