Skip to main content
bex.co
419
Blog

The 20-40% Kubernetes Tax: What Small-Team Maintenance Data Actually Costs, and When Fleet Management Pays It Off

8 min readDora NodaDora Noda
Self-Hosting
PaaS
Infrastructure
Engineering
Cost Optimization
Share

Ask a five-person engineering team what Kubernetes costs and they'll quote you the cloud bill. Ask their on-call engineer and you'll get a different number: 20-40% of one person's working hours, every month, gone to a cluster that never appears on an invoice.

That range isn't a guess. It's the number 2026 platform-engineering surveys keep landing on for small teams running their own Kubernetes: cluster upgrades, node patching, certificate rotation, etcd backups, and CNI/DNS debugging routinely consume a fifth to two-fifths of an engineer's time. At a loaded cost of $150,000-250,000 a year for that engineer, 20-40% works out to $2,500-8,000 a month — a second infrastructure bill, paid in hours instead of dollars, that never shows up next to the AWS invoice it's actually funding. This piece breaks that tax down line by line, shows what happens to it when the same work is automated by a fleet-managed control plane instead of a human, and gives a concrete framework for which side of that line a given team should be on.

The Tax, Broken Into Line Items​

"20-40% of an engineer's time" is an average of several distinct, recurring jobs, and they don't all show up on the same schedule:

  • Version upgrades. Kubernetes ships three minor releases a year, and each one is a real event — API deprecations to audit, admission webhooks to re-test, a control-plane and node-pool upgrade to sequence without downtime. This isn't a apt upgrade; it's a project with a rollback plan.
  • Node patching and OS maintenance. Every node in the fleet needs kernel and package updates, cordoned and drained in batches, validated for workload health before moving to the next batch.
  • Certificate rotation. kubeadm-issued client certificates expire on a one-year clock by default, and best practice is alerting 30 days out — one more calendar item a small team has to remember to own, on top of the cluster itself.
  • etcd backups. Snapshots are I/O-expensive and have to be scheduled around peak traffic, and a backup taken before the first post-install certificate rotation completes silently contains expired certs — the kind of gotcha that only surfaces during a restore, which is the worst possible time to learn about it.
  • CNI and DNS debugging. The single most time-consuming category in practice: figuring out why cross-service DNS broke after a CoreDNS update, or why a pod won't schedule, rarely has a runbook — it's investigation, not execution.

None of these is hard in isolation. What makes the 20-40% figure real is that they recur on independent schedules — a cert doesn't expire on the same week as a minor version bump — so a small team's on-call engineer is never more than a few weeks from the next one. Budget guidance in 2026 platform-engineering writeups reflects this directly: 0.5-1 full-time engineer per cluster for a hand-rolled setup, dropping to roughly 0.25 FTE only once a managed control plane is doing the recurring work instead of a person.

What the Same Work Costs When a Person Does It vs. When Automation Does​

The clearest before/after data point isn't a survey average, it's a single team's own numbers. A platform team managing 50+ Kubernetes clusters documented cutting its monthly maintenance load from 80 hours to 12 hours after moving cluster lifecycle operations — provisioning, upgrades, drift correction — onto declarative, Cluster API-style automation. That's an 85% reduction in the exact line items from the previous section, and it's not a hypothetical: it's what happens when "upgrade the node pool" and "reconcile a drifted node back to spec" stop being tickets a human executes and become a controller's reconcile loop.

That's the specific mechanism Cluster API (and Hetzner-targeting implementations of it, like cluster-api-provider-hetzner) is built around: cluster and machine lifecycle expressed as Kubernetes-native objects, with a controller watching and correcting drift continuously instead of a human running a runbook on a schedule. Cluster API's 2026 releases have pushed further into this — in-place node updates and chained upgrades that trigger automatically off a spec change, explicitly aimed at what one vendor writeup called the "maintenance debt" a hand-rolled cluster otherwise accumulates. The point isn't that Kubernetes gets simpler; it's that the recurring 20-40% of human time moves onto a control plane that runs it as code, the same way a Deployment object already replaced a human manually restarting crashed containers.

This is also the architectural bet behind bex: a git-push PaaS whose fleet underneath is Cluster API-managed Hetzner nodes, so a tenant gets git push → running HTTPS service, while node provisioning, upgrades, and self-healing are the platform's reconcile loop, not a line item on the tenant's own team's calendar.

When Teams Get This Math Wrong in Both Directions​

The case studies from the last two years split cleanly into two failure modes, and it's worth naming both, because "just use Kubernetes" and "never use Kubernetes" are both wrong the same number of times.

Over-provisioned Kubernetes, under-provisioned workload. One widely cited 2026 postmortem: a startup running a $47,000/month Kubernetes cluster for a workload serving 40,000 monthly active users — a workload the author says fit on a single laptop. Another team spent $340,000 migrating onto Kubernetes and deleted the whole setup six months later, citing a three-week new-engineer onboarding curve (versus three days on what they'd used before) and a rise in production incidents that tracked the migration, not the traffic. A mid-sized SaaS company running ~500,000 active users kept two full-time SREs dedicated to cluster maintenance; after migrating to a managed platform, that dropped to 0.5 of a person. In every one of these, the Kubernetes bill wasn't the problem — the 20-40% human-time tax on top of it was, for a workload that never needed the multi-node, multi-tenant machinery Kubernetes exists to provide.

Correctly-provisioned Kubernetes, un-automated lifecycle. The 80-to-12-hours case above is the mirror image: a fleet at real scale (50+ clusters) where Kubernetes was the right tool, and the tax wasn't the platform choice — it was running that platform's lifecycle by hand instead of through a reconciling control plane. A team in this position doesn't need to leave Kubernetes; it needs Kubernetes' own lifecycle management automated the way Cluster API is designed to do.

The number that separates the two: if a team is spending more than roughly 20% of engineering time on operations rather than product work, and the workload doesn't need multiple nodes or hard tenant isolation, the fix is a smaller footprint (Docker Compose, a single-box PaaS), not more automation on top of an oversized cluster. If the workload genuinely needs the fleet, the fix is automating the fleet's lifecycle, not staffing it.

A Concrete Framework​

Three questions settle which side of that line a team is actually on:

  1. Does the workload need more than one node? A single Hetzner box handles a surprising amount of real traffic. If the honest answer is "we run three replicas because that felt like the right number," not "we need N nodes for actual load or isolation," a hand-rolled or even a managed Kubernetes cluster is solving a problem that doesn't exist yet.
  2. Is the 20-40% tax being paid by a human or a control plane? If it's a human, and the team is past the single-node point, the ROI case for a Cluster API-managed fleet is the 80-to-12-hours number from above, not a vague "Kubernetes is complex" complaint.
  3. What does the loaded cost of the status quo actually total? $2,500-8,000/month in one engineer's time, plus the cloud bill for the cluster itself, is the real baseline a fleet-managed PaaS subscription needs to beat — and at that baseline, a managed control plane usually doesn't need to be free to win the comparison, just cheaper than a second infrastructure bill paid in hours nobody tracked as a line item.

The failure mode to avoid on both sides is treating "Kubernetes" as one decision. It's two: whether the workload needs a fleet at all, and — only if it does — whether that fleet's lifecycle runs on a human's calendar or a controller's reconcile loop.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on Cluster API-managed Hetzner machines you own, with node provisioning, upgrades, and self-healing handled by the platform's control plane instead of your on-call rotation. Star the repo on GitHub or deploy your first app today.

Sources​

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex
Back to all posts