Choosing Between Managed and Self-Hosted Kubernetes

The managed-versus-self-hosted Kubernetes decision gets pitched as a cost question, but on most engagements the deciding factor is actually operational headcount — specifically, whether the team has someone whose job is to own cluster upgrades, node pool scaling, and incident response for the control plane itself.

Teams under roughly a dozen engineers are almost always better served by a managed control plane, even at a real price premium, because the alternative is an engineer's attention getting pulled into cluster operations instead of the product. Past that size, with a dedicated platform function, self-hosting starts to pencil out — both on cost and on the flexibility to run configurations a managed offering won't support.

The mistake we see most often is a team adopting self-hosted Kubernetes because a blog post described managed offerings as expensive, without accounting for the engineer-hours self-hosting actually costs. Cost comparisons that ignore operational load are comparing the wrong numbers.

Our rule of thumb during scoping: if the client can't name who currently owns cluster upgrades, that's the answer to whether they should be self-hosting.