We're Leaving Kubernetes: What the Exit Posts Get Right About Small-Team Overhead, and What a PaaS Layer Answers

Every few months, Hacker News upvotes another farewell to Kubernetes. The genre peaked with Gitpod's "We are leaving Kubernetes" — 517 points, hundreds of comments — but the script barely changes between installments: a small team tallies what the full CNCF stack cost them, walks away to something simpler, and reports feeling liberated. The most interesting moment in that whole thread wasn't the exit itself, though. It was a two-comment exchange buried in the discussion: "You know that Cloud Run is effectively a Kubernetes PaaS, right?" — "Not the case. Cloud Run doesn't run on Kubernetes. It supports the Knative interface."

That exchange is the entire debate in miniature. So before the war stories, here is the fair accounting this post will defend, complaint by complaint:

The short version: the leavers are right about the bill and often wrong about what they're buying when they leave. "Leave Kubernetes" usually cashes out as "rent someone else's Kubernetes-shaped API" — which is a perfectly good trade, as long as you know you're making it.

The overhead bill is real, and it has numbers​

Start by steelmanning the exit posts, because the numbers they cite check out. A March 2026 postmortem that circulated widely put it bluntly: Kubernetes ate 15 hours of its author's week, every week, for two years — three engineers sharing maintenance for a cluster serving a startup, working out to roughly 1.1 full-time engineers doing nothing but Kubernetes. Another team priced their eight-month Kubernetes experiment at $45,000 for the migration, $84,000 in extra infrastructure overhead, and an estimated $60,000 in lost productivity from slower shipping and maintenance drag.

The floor costs are structural, not anecdotal. AWS EKS and Google GKE both charge $0.10 per cluster per hour — $73 a month per control plane before a single pod runs. Practitioners consistently report the minimum viable production cluster landing between $300 and $1,000 a month once nodes, storage, and load balancing join in. One cluster is easy to dismiss; five clusters is a line item that needs a meeting.

Then there is the YAML tax, the complaint that shows up in every thread from "Do I Need Kubernetes" through "I Didn't Need Kubernetes" to the latest farewell. A September 2026 comparison from a small team is representative: the Docker Compose version of a service took one afternoon; the Kubernetes version consumed most of a week and produced more YAML than the service had application configuration. Nobody disputes this ratio. Raw Kubernetes asks a five-person team to become part-time platform engineers — upgrades, RBAC, ingress controllers, storage classes, monitoring — to run a handful of stateless services that would fit on one machine.

And the after-action reports from teams that left are genuinely striking: one widely shared account reported an 89% increase in deployment success rates and a 62% reduction in infrastructure costs after removing Kubernetes, plus uninterrupted vacations for the first time in two years. Mocking those results misses the point. For a team running a few services with no dedicated platform staff, the orchestration cost was never amortized across enough workloads to pay for itself.

So grant the leavers their core claim: self-operating raw Kubernetes is a bad deal for a small team running stateless services. The question is what follows from it.

What Gitpod's exit actually proves — and what it doesn't​

Gitpod's farewell is the most-cited exhibit in the genre, and the most misquoted. Read past the headline and the details matter enormously: Gitpod spent six-plus years running cloud development environments on Kubernetes before building Gitpod Flex, a ground-up replacement architecture they started in January 2024 and shipped that October.

Development environments are just about the worst possible fit for Kubernetes' design center. Kubernetes was built for stateless microservices with predictable resource profiles; Gitpod needed high-performance disks, ballooning memory, live migrations, and hard isolation for untrusted tenant code. Scheduling latency that is invisible for a web deployment becomes user-facing lag when a developer waits for an environment. RAM overbooking — the standard trick for bin-packing stateless pods — becomes a reliability hazard when every workload's memory footprint balloons unpredictably. The replacement architecture runs VM-level isolation with up to 896 cores and 12TB of RAM per environment and cut infrastructure costs 70%.

Here is the representativeness check the genre usually skips: Gitpod's 70% cost reduction came from moving to a VM-level architecture purpose-built for stateful, bursty, security-sensitive workloads — not from discovering that YAML was unnecessary. Quoting Gitpod to justify moving a three-service SaaS off Kubernetes is like citing a cargo airline's fleet decision to pick a family car. The workloads share a scheduler the way a jumbo jet and a bicycle share the concept of wheels.

This is the pattern across the whole canon. Each exit post is really two claims bundled together: "our workload's needs diverged from what Kubernetes optimizes for" (usually true and specific) and "therefore Kubernetes is overkill" (a generalization the evidence rarely supports). The honest version of the genre would be titled "We're Leaving Self-Operated Kubernetes for Workloads It Was Never Built For." Less clickable. More accurate.

The exit that isn't an exit: you kept the interface​

Now the thread's sharpest exchange. When one commenter claimed Cloud Run is effectively a Kubernetes PaaS and another corrected them — Cloud Run runs on Borg, Google's internal scheduler, and merely implements the Knative interface — both were half right, and the correction is the more important half.

Cloud Run reimplements the Knative Serving API without Kubernetes underneath. The practical consequence: a service defined as a Knative manifest is portable between fully managed Cloud Run and self-hosted Knative on your own Kubernetes cluster. Same container runtime contract, same YAML shape, different operator. Teams that "left Kubernetes" for Cloud Run didn't leave the ecosystem's interface model at all — they left self-operated control planes while continuing to speak a Kubernetes-native serverless dialect.

This is the same trick Heroku's buildpack contract pulled a decade ago: the interface outlives any particular substrate. And it reframes the exit decision entirely. The choice was never "Kubernetes or simplicity." It is "who operates the substrate under a portable interface — you, or someone you pay per request."

That reframe demands honest cost math in both directions, because the meter cuts both ways:

• Idle or spiky workloads favor the meter. A staging environment or an internal tool that serves a few thousand requests a day costs pennies on Cloud Run and a full node (or a shared cluster's slice plus its $73 control plane) on Kubernetes.
• Steady workloads favor the flat cost. A service handling sustained traffic on owned hardware — say, a Hetzner machine at a fixed monthly price — quickly undercuts per-request pricing, and the gap widens with utilization. The teams reporting 60%+ cost cuts after leaving were typically paying cloud list prices for underutilized managed clusters, the worst of both worlds.
• The crossover moves with team size. One service on Cloud Run is obviously cheaper than one EKS cluster. Fifty services on Cloud Run's meter versus fifty services bin-packed onto owned nodes is a very different spreadsheet — and orchestration toil per service falls as the platform amortizes it.

"Rent someone else's Kubernetes-shaped API" is a good deal at low scale and a margin leak at high scale. The exit posts almost always describe the first regime and generalize to the second.

What a git-push PaaS layer answers​

With the bill validated and the exit properly labeled, the remaining question is whether there is a third option between "operate raw Kubernetes yourself" and "rent the meter." There is, and it is the structure the leavers are implicitly asking for: a platform layer that owns the fleet while developers keep the push-and-run simplicity.

Map each surviving complaint to the layer that absorbs it:

• Control-plane toil → the platform's job, done once. Upgrades, node provisioning, ingress, TLS, and monitoring are operated by the platform (or its automation, on a Cluster API-managed fleet of owned machines) and amortized across every tenant. No individual team pages through a kubelet upgrade again.
• The $73-plus floor → amortized flat cost. Owned nodes have no per-cluster control-plane meter; the fixed hardware cost spreads across all services on the fleet instead of landing on one team's five-service cluster.
• The YAML week → generated, not written. Buildpacks turn a git push into an image; the platform renders Deployment, Service, ingress, and autoscaling from a small app manifest. The developer's interface is git push, not 400 lines of manifests — the same simplification the Cloud Run leavers bought, without the per-request meter.

Notice what this structure concedes to the leavers: developers should never touch raw Kubernetes for routine deploys. The YAML burden, the upgrade toil, the control-plane pager — all real, all correctly diagnosed. The disagreement is only about the prescription. The exit posts conclude the substrate must go; the PaaS answer is that the substrate needs an operator, and that operator should be a platform serving many tenants rather than each team serving itself.

This is also why the Knative lesson cuts in the platform's favor. Interfaces that survive substrate changes — Knative services, buildpacks, plain HTTPS — are exactly what a good PaaS exposes. If the workload contract is portable, the team keeps its exit options while the platform competes on operations, not lock-in.

A decision rule for the next farewell post​

The next "we're leaving Kubernetes" post is already being drafted somewhere, and it will probably be right about its author's situation. Use this rule to tell whether it's right about yours:

1. Fewer than ~10 services, no platform staff, spiky traffic? Leave, or rather rent — Cloud Run or its equivalents are the rational choice, and Knative compatibility keeps the door open.
2. Steady traffic on workloads Kubernetes fits (stateless services)? Price the meter against owned nodes before concluding anything; the exit posts' savings usually come from escaping underutilized managed clusters, not from escaping orchestration.
3. Stateful, bursty, or untrusted workloads at scale? You may genuinely need a different substrate, Gitpod-style — but that is an architecture decision, not a simplicity decision, and it costs engineering years, not an afternoon with Compose.
4. Past the single-team stage but not ready for per-team clusters? That is the PaaS-shaped hole: one fleet, many tenants, git-push interface, orchestration cost amortized instead of repeated.

Kubernetes was never the product; it was always infrastructure waiting for someone to productize it. The leavers proved that raw infrastructure is a bad product for small teams. The right response was never to pretend the toil doesn't exist — it's to put a layer over it so no team pays the bill twice.

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.