The short answer

For most indie developers, solo founders, and small teams running a handful of production apps, managed Kubernetes is usually the better default. Self-hosted Kubernetes is the right call only when you have a specific reason — strict data residency, deep customization, or a dedicated platform engineer who genuinely wants the work.

The reason is not about Kubernetes being bad software. It is about how much of your week disappears into keeping the cluster alive instead of shipping features.

Why this decision matters more than it looks

Kubernetes is the default container orchestrator for a reason: it gives you consistent deployments, scaling, and rollouts across environments. The catch is that the orchestrator itself is a complex piece of infrastructure with its own upgrade cadence, security model, and observability requirements.

When you run it yourself, you are not just running your app — you are also running:

  • Version upgrades, roughly every few months, with a support window for each release.
  • Control plane patching and security hardening (RBAC, network policies, pod security standards, secrets handling).
  • An observability stack — metrics, logs, traces — if you want to know what is happening before users tell you.
  • Networking plumbing — CNI plugins, ingress controllers, service meshes, internal DNS.
  • Backup and disaster recovery, because Kubernetes does not bundle native workload backups.

None of these are impossible. They are just ongoing work, and they do not stop once the cluster is “set up.”

What “managed Kubernetes” actually means

A managed Kubernetes service (EKS, GKE, AKS, and similar offerings) runs the control plane for you: the API server, scheduler, etcd, and controller manager. You typically still manage your worker nodes, your workloads, and your application-level configuration, but the provider handles cluster provisioning, control-plane upgrades, and control-plane high availability.

What you usually keep responsibility for:

  • Node pools and node OS patching (unless the provider also abstracts this away)
  • Application deployments and rollouts
  • Cluster-level security policies and IAM/RBAC choices
  • Ingress, DNS, TLS, and observability for your workloads

What you hand off:

  • Control-plane provisioning and uptime
  • Kubernetes version upgrades for the control plane
  • etcd backups at the control-plane level
  • The “is the API server up at 3 AM” question

What “self-hosted Kubernetes” actually means

Self-hosted means you install and operate every component of Kubernetes yourself — control plane and worker nodes — on bare-metal servers, cloud VMs, or a mix. You pick the distribution (upstream, kops, kubeadm, or a vendor-packaged option), the CNI, the ingress controller, the storage layer, and the observability stack.

You also keep the entire upgrade cycle, security patching, backup story, and capacity planning in-house.

The trade-offs, framed from a founder’s perspective

Operational attention

This is the biggest one. Multiple practitioner reports in this space flag that a meaningful share of teams running self-hosted Kubernetes run into stability, security, or operational issues in the first 18 months — not because the technology is flawed, but because production operations require specialized skills that go well past the initial install.

As a founder, the practical question is: how many hours a week do you want to spend on the cluster instead of the product? If the answer is “near zero,” managed wins.

Scaling complexity

Kubernetes is excellent at scaling workloads once it is set up. What is less obvious is that the scaling decisions — how many nodes, when to autoscale, how to handle traffic spikes, how to plan capacity — are ongoing analytical work. Managed services typically surface simpler scaling primitives (node pools, autoscalers, serverless options) that hide some of this from you.

Cost predictability

Self-hosted looks cheaper on the surface: just the underlying compute. The real cost is engineer time. Practitioner estimates commonly land in the range of roughly half a full-time engineer dedicated to operations for a single non-trivial production cluster — more if it is business-critical. For a small team, that is a significant slice of payroll going to infrastructure rather than the roadmap.

Managed Kubernetes shifts part of that cost into a predictable line item on your cloud bill, plus the managed-service premium. The trade is variable engineer time for a fixed fee.

Portability and lock-in

A common argument for self-hosting is “no vendor lock-in.” The reality is more nuanced. Managed Kubernetes services generally run upstream-compatible Kubernetes, so your workloads and manifests are portable. What can be sticky is the surrounding glue: IAM roles, load balancers, storage classes, ingress annotations, secrets integrations, and observability tooling.

If portability matters deeply to you, focus on the parts that actually lock you in (IAM, networking, storage) rather than the control plane itself.

Customization and control

Self-hosted gives you full access to etcd, every admission controller, every CNI option, and every Kubernetes version. Managed services limit you to supported versions and pre-configured defaults. If your business genuinely needs an unsupported Kubernetes version, a custom CNI, or unusual admission policies, that is a real reason to self-host — and a rare one for small teams.

When self-hosted Kubernetes is genuinely the right call

Self-hosting earns its cost when at least one of these is true:

  • Strict regulatory or data-residency requirements that exclude public-cloud control planes.
  • You already have a platform engineer on the team who treats Kubernetes operations as a product they want to own.
  • You need unusual customization — specific Kubernetes versions, custom CNI/CSI plugins, or deep integration with on-prem hardware that managed services cannot accommodate.
  • You are optimizing for compute cost at scale and have the operational maturity to match — usually past the small-team stage.

If none of those apply, self-hosted Kubernetes is mostly paying an operational tax in advance for flexibility you may never use.

When managed Kubernetes is the right call

Managed is the right call when:

  • Your team is small (or solo) and your attention is the scarce resource.
  • You are running production workloads but Kubernetes itself is not the product.
  • You want to delegate version upgrades and control-plane patching.
  • You are on a single cloud and do not need exotic Kubernetes versions.
  • You want cost predictability more than minimum possible cost.

If that describes you, managed Kubernetes is the boring, correct answer.

And when neither is the right call

This is the part most “managed vs self-hosted” articles skip. For many small production apps, Kubernetes itself is overkill.

If you have:

  • One or two services
  • Predictable traffic
  • A small database, simple queues, and basic background jobs
  • No need for complex rollout strategies or autoscaling beyond “scale up the box”

…then a simpler platform will save you more time than either Kubernetes option. Consider:

  • Platform-as-a-Service app hosts (Render, Fly, Railway, Heroku-style platforms) that deploy from git, handle TLS, and scale with a slider.
  • Container hosts with built-in orchestration (Fly apps, Railway services, Cloud Run, App Runner) that give you container-based deployment without the cluster abstraction.
  • Single-VM deployments behind a load balancer, with a managed database alongside, when traffic is genuinely low.

The honest framing: choose Kubernetes when your workload shape justifies it. If it does not, the best Kubernetes decision is the one you do not make.

Practical next steps

  1. Write down what your app actually needs. Number of services, scaling behavior, traffic pattern, data-residency constraints. If you cannot fill this in honestly, you are not ready to compare orchestration platforms.
  2. Estimate the operational cost honestly. Multiply the time a competent engineer would spend weekly on cluster upkeep by their loaded cost. Compare that number to the managed-service premium.
  3. Try the simpler option first. Deploy to a PaaS app host or a container host for a quarter. If you outgrow it, that is the right time to look at Kubernetes — and you will know why you need it.
  4. If you pick managed Kubernetes, pick the cloud you already use. EKS if you are on AWS, GKE if you are on GCP, AKS if you are on Azure. The marginal integration benefit usually beats cross-cloud portability.
  5. If you pick self-hosted, treat it as a product. Dedicated owner, documented runbooks, rehearsed upgrade and restore procedures, and a budget for observability tooling. Half-committed self-hosting is how outages happen.

FAQ

Is managed Kubernetes just “Kubernetes with extra steps”?

No. It is Kubernetes with the control plane abstracted away. Your workloads, manifests, and tooling are still standard Kubernetes. What changes is who is on call for the API server.

Can I switch later without rewriting my app?

Usually yes at the workload level, because managed services run upstream Kubernetes. What you may have to rewrite is the surrounding glue: ingress annotations, IAM roles, storage classes, and secrets handling. Plan for that work, not for rewriting your application.

Do managed services lock me into a cloud?

The Kubernetes layer does not. The cloud-specific bits — IAM, networking, storage, load balancers — do. If avoiding cloud lock-in is a priority, weigh that against the operational savings.

How big does my team need to be to self-host responsibly?

There is no fixed number, but as a rough rule: at least one engineer whose primary job is platform operations, with backup coverage, and a willingness to treat the cluster as a product with on-call, runbooks, and a roadmap. If that is not your team, self-hosting will quietly compete with your product work.

Sources