Running Kubernetes on-premises means you operate the entire cluster yourself, from the hardware or virtual machines all the way up to the control plane. With managed Kubernetes, a provider runs the control plane for you, and you only take care of your own applications. Between those two extremes sits a third path many decision makers never even consider: a self-operated cluster on rented infrastructure, for example k3s on Hetzner Cloud. Which model fits you depends less on the technology itself than on how much control, operational effort, and data sovereignty you actually need.
I run production-grade k3s clusters on Hetzner Cloud and advise mid-sized companies on exactly this decision. You can find all my articles on running Kubernetes clusters collected on the Kubernetes page. This article lays out the three models honestly, without selling you on any single one, because each of them has good reasons for it and good reasons against it.
Three ways to run a Kubernetes cluster
At one end of the scale sits managed Kubernetes from a large cloud provider: you get a ready-made control plane, usually for a small monthly base fee, and pay for the nodes underneath it. At the other end sits your own data center: your own servers, your own network, full responsibility for every layer. In between sits the middle path I use for my own projects: you rent compute from a cloud provider but install and operate Kubernetes itself, typically with a lean distribution like k3s.
These three paths differ mainly in who owns which layer. With managed Kubernetes, the provider carries the control plane and often part of node maintenance too. With your own data center, you carry everything, from power supply to Kubernetes upgrades. With the middle path, you carry the Kubernetes layer yourself while the cloud provider supplies the physical infrastructure, the data center, and the network connection. That is not an academic distinction, it determines how much staff you need and how fast you can react when something breaks.
Managed Kubernetes at hyperscalers: what you give up for it
Managed Kubernetes is the most comfortable way in. You create a cluster through a web console or an API, the control plane runs highly available, and the provider handles upgrades of the control layer for you. For teams without a dedicated platform team, that is a huge win, because a large chunk of the Kubernetes operational burden simply disappears.
The price for that is less control. You get the control plane configured the way the provider decided, on their upgrade schedule, with their default settings. Maintenance windows are set by the provider, not by you. And depending on the provider, your data and cluster metadata may live outside Europe, or with a company not subject to European law, even when its data centers physically sit in Europe. For many applications that is not an issue. For mid-sized companies handling sensitive customer data, say in healthcare or finance, the question of data sovereignty is often the deciding factor in the selection, ahead of pure cost.
Kubernetes on premises in your own data center: full control, full effort
At the other end sits full self-operation: your own servers, your own network, your own racks. The advantage is obvious, you decide every configuration yourself, from the hardware through the operating system to the Kubernetes version, and your data never leaves your building. For companies with very strict requirements or with existing data center infrastructure, that can be the right call.
The price is high, and it is routinely underestimated. A cluster needs redundant hardware, a reliable power supply, networking gear, and staff who understand servers, storage, and Kubernetes itself. Then there is lead time: procuring and installing new hardware takes weeks to months, while an extra node in the cloud is ready in minutes. For a startup with a lean technology stack and few customers, an in-house data center is almost always overkill. For established companies with an existing operations team and clear compliance requirements, it can pay off instead.
The middle path: k3s on rented infrastructure in a German cloud
Right between these two poles is where I run my own clusters: with k3s, a lean Kubernetes distribution, on rented virtual servers at Hetzner, a German cloud provider. I rent compute, which means I skip owning hardware and the procurement lead time that comes with it, but I install and operate the Kubernetes layer entirely myself. My production clusters run three control plane nodes, spread across three separate data centers, on a hardened operating system built for exactly this purpose. The infrastructure is set up and managed with tools for declarative infrastructure description, so every server is reproducible from code.
This path gives you two things at once that the two pure models trade off against each other: full control over the Kubernetes configuration, without the lead times and staffing needs of an in-house data center. Everything I roll out goes through GitOps, so every change to the cluster is traceable in a Git repository instead of happening manually on the command line. Here is a simple first look at a freshly set up cluster:
kubectl get nodes -o wide
kubectl get nodes -L topology.kubernetes.io/region,topology.kubernetes.io/zone
The first command shows every node with its internal and external IP address and the operating system image. The second command adds each node's region and availability zone, as long as your cloud provider sets those labels. That is exactly how you check whether your control plane nodes really sit across multiple data centers or all live in the same building, which makes a real difference for resilience.
The downside of this model needs to be stated plainly: you need Kubernetes expertise in your team, because upgrades, security patches, and troubleshooting the control plane are on you, not on a provider. If your team does not have that knowledge and does not want to build it, managed Kubernetes is the better fit. Best practices for running Kubernetes on-premises or on rented infrastructure therefore do not start with the technology, they start with an honest assessment of how much operational knowledge your team already has or is willing to build.
Data sovereignty as its own decision criterion
Data sovereignty gets overlooked in cost comparisons far too often, even though it tips the scale for many mid-sized companies. The question is not only where a data center physically sits, but which jurisdiction the operator falls under and who might be able to access your data and configuration in a dispute. A German cloud provider headquartered in Germany operates under different conditions than an international hyperscaler with a European branch. Four questions belong together here, and location is only the first: who can technically access the data, who manages the keys for encryption at rest, which subprocessors are involved, and what the operating model does with a government request. A cluster in a German data center whose keys sit with the provider has less data sovereignty than one abroad whose keys you hold yourself. That is not a statement about which model is technically better, it is an additional dimension to weigh alongside cost and operational effort, especially when you handle personal or confidential data.
The three models compared
The table below summarizes how the three operating models differ across the criteria that matter most. It does not replace a case-by-case assessment, but it helps you place your own requirements.
| Criterion |
Managed Kubernetes |
Own data center |
k3s on rented cloud |
| Control over the control plane |
low, provider decides |
full |
full |
| Operational effort for Kubernetes |
low |
high |
medium to high |
| Effort for physical infrastructure |
none |
high |
none |
| Time to add capacity |
minutes |
weeks to months |
minutes |
| Kubernetes expertise needed in-house |
low |
high |
high |
| Influence on data sovereignty |
depends on provider |
full |
depends on provider, well controllable with a German one |
Frequently asked questions
What is the difference between Kubernetes on-premises and managed Kubernetes?
With Kubernetes on-premises, you operate every layer yourself, from the control plane down to the hardware. With managed Kubernetes, the provider runs the control plane and usually its updates too, and you only bring your applications. In between sit hybrid forms like a self-operated cluster on rented cloud infrastructure.
Is Hetzner suitable for a production Kubernetes cluster?
In my own experience, yes, I run production-grade clusters on it with multiple control plane nodes spread across separate data centers. Hetzner itself does not offer a ready-made managed Kubernetes product, though, you have to install and operate Kubernetes yourself, as with any other infrastructure provider, for example with k3s.
What does managed Kubernetes cost compared to running it yourself?
That cannot be answered responsibly with numbers without a concrete scenario, because both models shift costs into different categories: managed Kubernetes turns staffing cost into ongoing fees, running it yourself turns ongoing fees into staffing effort. I break down the individual cost blocks in Kubernetes Costs: What a Cluster Costs.
What best practices apply to Kubernetes on-premises or on rented infrastructure?
The most important one is honest expertise inside your team, because upgrades and troubleshooting of the control plane land on you. Beyond that, you want declarative, versioned configuration instead of manual changes, a backup strategy for the cluster state, and control plane nodes spread across multiple physically separate locations so a single outage cannot take down the whole cluster.
Where to go next
Which model fits you depends heavily on how your company is set up. For a closer look at typical operating models for mid-sized German companies, see Kubernetes for SMEs: An Operating Model, and I break down the actual cost blocks in Kubernetes Costs: What a Cluster Costs. And if you decide to run it yourself, think about backups early, more on that in Kubernetes Backup: etcd and Volumes.
My suggestion: write down control, operational effort, and data sovereignty for your own company and weigh them honestly. The answer usually falls out almost by itself, long before any provider's price list even enters the picture.
In full detail with all examples, this is covered in chapter 2 of my Kubernetes Practical Guide (Rheinwerk Computing), where I also cover which companies benefit from Kubernetes in the first place. The official Kubernetes documentation compares tools and operating models for production environments, and you can find the source of the distribution I use in the k3s project on GitHub.
