Managed Kubernetes vs. Self-Hosted: Outsource Operations or Run It Yourself?

Hand off Kubernetes operations or secure them? WZ-IT operates Kubernetes clusters on your infrastructure or hosted in Germany. Monitoring runs 24/7; the response to P1 incidents follows the service level. View managed Kubernetes operations

"Managed or self-hosted?" mixes three decisions: whether it has to be Kubernetes, where the control plane runs, and who does the work below and above it. This guide separates them. It compares four operating models, places responsibilities in a matrix with vendor sources, and gives a decision rule with testable criteria, including the cases where self-operation or no Kubernetes at all is the right answer. Status October 2026. Prices are in the guide to managed Kubernetes cost; this one is about responsibility.

Table of contents

• The decision rule
• Four operating models on the market
• Responsibility matrix: who does what
• When a provider control plane is enough
• When a service provider takes over operations
• When self-operation is enough
• When you do not need Kubernetes at all
• Staff, bus factor and on-call
• Questions before outsourcing
• Status and sources
• How WZ-IT does it
• Further guides

The decision rule

Check from top to bottom; mixed forms are possible, for example a provider control plane with a service provider for the operations above it.

Two people for cover are an assumption (leave, illness, resignation); four people for 24/7 follow from the 25 percent rule of Google SRE practice, see staff and on-call. Whether Kubernetes is needed at all is covered by Do we need Kubernetes?.

Four operating models on the market

The Kubernetes documentation names the options for handing off the build: serverless, managed control plane, managed worker nodes and integrations (Production environment). On the market (status 28 October 2026), four models can be told apart:

Model A hands off a layer, model C the work. Hosters in model C with "operations included" sit between the two. Prices and worked examples are in the cost guide.

Responsibility matrix: who does what

The column "Control plane from the provider" follows the vendor documents (AKS, GKE, EKS). The column "Service provider" shows the scope that day-2 providers name on their service pages; the contract is binding.

The BSI requires a data backup of the cluster including etcd and persistent volumes for Kubernetes; snapshots must not replace it (APP.4.4.A5, in German). That is why backup is its own row in the matrix: a provider control plane backs up etcd, not your volumes and databases (backup layers).

When a provider control plane is enough

• The workloads already run at the provider, with data, identity and networking, and the location of the control plane is uncritical.
• The team carries nodes, add-ons and monitoring and only wants to hand off control plane and etcd. Count the work that remains: on AKS that is network policies, workload monitoring, cluster backup and compliance.
• An SLA for the API is enough: AKS Standard commits to 99.95 percent with availability zones, AKS Free has no financially backed SLA (Microsoft Learn).

The limit: the provider SLA protects the API, not your application. Without on-call in the team, response at night stays unstaffed.

When a service provider takes over operations

• Fewer than two people know the cluster or the platform work should not sit in the team.
• The infrastructure is fixed: Proxmox, bare metal or an EU provider without a managed Kubernetes product. Hetzner offers none on its cloud product page.
• Response outside office hours is required without staffing four people. Offers differ here: ayedo Priority and Adacor state 24/7, pexon and Kubewerk Mon-Fri (prices and times in the cost guide).
• Evidence is demanded: a service provider delivers it only if the scope provides for it.

The limit: the service provider operates the cluster, not your application. kloudease explicitly excludes feature development and fixes in application code from its SREaaS package (services); whether deployments and database contents are included is settled by the scope.

When self-operation is enough

Self-operation is not a fallback. It fits when:

• Kubernetes is part of the product and platform work is a core competence.
• Cover and process exist: at least two people who know the cluster, an upgrade process with staging and rollback, a tested etcd restore and alerts that someone receives. Kubernetes supports the three most recent minor versions with about one year of patch support; 1.34 reached end of life on 27 October 2026 (releases). A cluster therefore has to move up a minor version at least once a year.
• External access is ruled out (air gap without access for third parties, special hardware, regulatory requirement), so neither a provider control plane nor a service provider is an option.
• The cluster is not productive: learning and testing are the obvious reason for self-operation.
• Office hours are enough: then a small team can carry self-operation without an on-call rota.

Whoever chooses self-operation also decides on the distribution; k3s, RKE2 and Talos distribute the work differently.

When you do not need Kubernetes at all

The smallest platform that reliably meets the requirements for deployment, scaling and availability is the right one. Against Kubernetes speak:

• one or two servers with a few containers and even load,
• rare deployments without need for rolling updates or autoscaling,
• nobody who owns upgrades, security and incidents,
• unclear backups and restore targets already today,
• a single physical server as the entire infrastructure: a cluster on it creates no physical high availability.

The Kubernetes documentation separates learning environments from production clusters: a single machine is a single point of failure, and a cluster becomes highly available only with a replicated control plane, load balancing to the API server and enough worker nodes (Production environment). The alternatives are compared in Kubernetes vs. Docker Compose vs. Coolify.

Staff, bus factor and on-call

• Cover (assumption): two people with cluster skills are the lower bound so that leave, illness or resignation do not stop operations. There is no reliable statistic; the number is a setting you check for your team.
• On-call (sourced): according to Google SRE practice, an engineer spends at most 25 percent of their time on call. With one person on call at a time, 24/7 therefore needs at least four people; Google names at least eight for primary and secondary at one site, and six per site for two sites (SRE book, Being On-Call).
• Labour market (sourced): 79,000 IT specialists are missing, 97 percent of companies with IT vacancies have trouble filling them; IT administration and system operations are most sought (26 percent), followed by software development and architecture (17 percent) and cloud and infrastructure (14 percent) (Bitkom, 3 September 2026, in German).
• Hourly cost (sourced): 58.50 euros labour cost per hour worked in 2025 in information and communication (Destatis, in German). What that means for your cluster is worked out in the cost guide with break-even hours.

Outsourcing does not remove the staffing risk, it moves it into a contract. The questions below turn the contract into a fallback.

Questions before outsourcing

1. Who owns the repository? The desired state (GitOps) belongs in your organisation.
2. Do you keep admin access, also after the contract ends?
3. Are there runbooks that a third party can read?
4. How does handback work, with what notice period?
5. Which service window and response time apply in writing, also at night and on weekends?
6. Is a restore test part of acceptance?
7. What term applies? For comparison: Kubewerk states a minimum of 6 months, WZ-IT is cancellable monthly.

A "no" on 1 to 4 moves the problem instead of solving it.

Status and sources

• Status: 28 October 2026. The matrix follows the documents of Microsoft, Google and AWS; their split of responsibility can change.
• Assumptions: two people for cover; hour and price assumptions in the cost guide.
• Not examined: serverless containers, OpenShift and commercial distributions.

How WZ-IT does it

We operate clusters under model C: on your infrastructure (Proxmox, bare metal, EU cloud, EKS, AKS) or hosted in Germany. As an entry point we offer the cluster audit, from 1,490 euros one-time and creditable against the first month of operations; it is a configuration review, not a penetration test (cluster audit). Operations cost from 590 euros per cluster and month including 3 worker nodes, net; the service level sets the response to P1 incidents (service levels). Whoever keeps self-operation and needs occasional help uses Kubernetes support without a contract at 120 euros per hour net.

Further guides

• Managed Kubernetes cost - platform rental and operations with sources
• Do we need Kubernetes? - signals for and against Kubernetes
• Kubernetes vs. Docker Compose vs. Coolify - the smaller platform
• Taking over a Kubernetes cluster: audit checklist - check the existing state before operations change
• Kubernetes backup: the four layers - backup concept and restore test
• k3s vs. RKE2 vs. Talos - distribution for self-operation

Deciding on an operating model? WZ-IT takes over operations on your infrastructure or hosted in Germany, with price and service level per cluster. Managed Kubernetes operations · Kubernetes hosting · Cluster audit

Further reading: Kubernetes operations concept per APP.4.4