Self-Managed vs Managed
With the three big offerings covered, the question is when to use any of them versus running Kubernetes yourself. The honest answer for most teams is: use managed. But there are real reasons to self-manage, and a framework for deciding beats a dogma either way.
This topic is the decision, not a product — weighing control and cost against operational burden, and naming the short list of cases where self-managing genuinely wins.
The Real Cost of the Control Plane
Running the control plane yourself means owning etcd durability and backups, control-plane HA, certificate rotation, version upgrades, and the on-call burden when any of it breaks at 3 a.m. These are exactly the tasks that are unglamorous, easy to neglect, and catastrophic when neglected. Managed providers do them well, at scale, for a fee that is almost always less than the engineering time they replace. For most teams that math is decisive.
When Self-Managing Wins
There are legitimate reasons to self-host. On-premises or edge deployments where no managed offering runs. Air-gapped or strict-compliance environments that cannot use a public cloud control plane. Specialized control-plane needs — custom scheduler, API server flags, or kernel-level requirements a managed provider won't expose. And genuine scale or cost situations where a large, sophisticated platform team can run clusters more cheaply than the managed premium. Notably, "we want control" or "we fear lock-in" alone usually do not justify the burden.
| Reason to self-manage | Strength |
|---|---|
| On-prem / edge (no managed option) | Strong |
| Air-gapped / strict compliance | Strong |
| Custom control-plane requirements | Situational |
| Large team, scale economics | Situational |
| "Control" / lock-in fear alone | Usually weak |
The Hybrid Middle
It is not strictly binary. Cluster API manages cluster lifecycle declaratively across environments (including on-prem), and on-prem distributions (OpenShift, Rancher, and others) package much of the operational tooling so self-hosting is less raw than bare kubeadm. These reduce — but do not eliminate — the burden, and they are the pragmatic path when you must self-host but want managed-like ergonomics.
A Decision Framework
Decide in this order. Is there a hard constraint (on-prem, air-gapped, compliance, a control-plane feature) forcing self-managed? If yes, self-manage — ideally with Cluster API or a distribution. If no, do you have a platform team that can operate the control plane better and cheaper than the managed premium, at your scale? Rarely yes — and if no, use managed. Default to managed; self-manage only when a concrete constraint or a real economic case demands it. The control plane is undifferentiated heavy lifting for almost everyone.
Self-managed — justified by hard constraints (on-prem, air-gapped, custom control plane) or genuine scale economics with a strong platform team.
Managed — the default — the control plane is undifferentiated work the provider does better and cheaper than your time.
- Self-managing for "control" or lock-in fear alone, taking on the burden without a concrete need.
- Underestimating the ongoing cost of etcd, HA, certs, upgrades, and on-call.
- Self-hosting from raw kubeadm when Cluster API or a distribution would ease most of it.
- Choosing managed without checking the one hard constraint (compliance, on-prem) that rules it out.
- Assuming managed eliminates all ops — it removes the control plane, not your side.
- Default to managed; self-manage only for a concrete constraint or a real economic case.
- When self-hosting, use Cluster API or a distribution rather than raw kubeadm.
- Cost the engineering time of operating the control plane against the managed premium honestly.
- Keep manifests portable so the decision can be revisited as needs change.
- Treat the control plane as undifferentiated heavy lifting unless you have a reason it isn't.
Knowledge Check
Which is a strong reason to self-manage Kubernetes?
- An on-prem, edge, or air-gapped environment where no managed control plane is available
- A general, unquantified desire for 'more control' over the cluster's internal components
- Fear of vendor lock-in to a single managed provider, on its own
- Wanting to use the standard Kubernetes API for your manifests
What is the recommended default for most teams?
- Managed — the control plane is undifferentiated work the provider does better and cheaper
- Self-managed with kubeadm for full hands-on control over etcd, HA, certs, and node upgrades
- Self-managed exclusively on bare-metal servers racked in your own on-prem datacenter
- Avoid Kubernetes entirely and run plain VMs
If you must self-host, what eases the burden over raw kubeadm?
- Cluster API or an on-prem distribution that packages operational tooling
- Running a single control-plane node to sidestep the complexity of HA setup
- Skipping etcd backups to save storage and reduce moving parts
- Disabling version upgrades to keep the cluster stable
You got correct