Kubernetes on Hetzner: Cloud, bare metal or Proxmox?
Timo Wevelsiep•Updated: 22.07.2026Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.
Building Kubernetes on Hetzner as a complete application platform? WZ-IT designs and operates clusters on Hetzner Cloud, dedicated servers or Proxmox, including networking, GitOps, monitoring, backup and private access. Explore Kubernetes on Hetzner
Kubernetes can run on Hetzner in three fundamental models: on cloud VMs, directly on dedicated servers or inside a Proxmox environment. The models differ less in Kubernetes itself than in provisioning, failure boundaries, storage, load balancing and responsibility for the cluster lifecycle.
Hetzner provides the infrastructure and official Kubernetes integrations. The platform itself is built by the customer or an operations partner. When searching for "managed Kubernetes on Hetzner", first clarify whether that means only a managed control plane or complete operations including GitOps, monitoring, backup and workloads.
Contents
- Comparing the three operating models
- Kubernetes on Hetzner Cloud
- Kubernetes on dedicated servers
- Kubernetes on Proxmox at Hetzner
- Networking and secure access
- Load balancing and ingress
- Storage, databases and backups
- GitOps, upgrades and observability
- Choosing an architecture
Comparing the three operating models
| Model | Characteristics | Typical fit | Additional responsibility |
|---|---|---|---|
| Hetzner Cloud | API-driven VMs, networks, load balancers and volumes | Dynamic node pools, standardized platforms, fast setup | Control plane, nodes, CNI, GitOps, policies and workloads |
| Dedicated servers | Fixed physical performance, local NVMe, no hypervisor layer | Constant base load, data-intensive workloads, predictable capacity | Provisioning, hardware replacement, load balancing and storage architecture |
| Proxmox on dedicated servers | Kubernetes nodes as VMs on a virtualization layer | Mixed VM and container estates, separated environments | Both Proxmox and Kubernetes lifecycles and joint capacity planning |
A fourth model combines cloud VMs and bare metal. The Cluster API Provider Hetzner can manage both resource types declaratively. That flexibility also increases the number of components that must be upgraded, monitored and understood during an incident.
Kubernetes on Hetzner Cloud
In a cloud architecture, the control plane and workers run on Hetzner Cloud servers. The official Hetzner Cloud Controller Manager connects Kubernetes to the Hetzner Cloud and Robot APIs. The CSI driver exposes Hetzner Cloud Volumes through Kubernetes StorageClasses.
A complete platform also needs at least:
- a CNI such as Cilium or Calico,
- an ingress controller or the Kubernetes Gateway API,
- DNS and certificate automation,
- a container registry,
- GitOps using Argo CD or Flux,
- metrics, logs and alerting,
- backup and tested recovery,
- a documented upgrade strategy.
Cloud VMs simplify automated node creation and replacement. A complete application platform adds GitOps, ingress, certificates, observability, backup, security policies and controlled upgrade procedures to the cluster.
Kubernetes on dedicated servers
Dedicated servers give Kubernetes direct access to CPU, memory and local NVMe drives. This can suit constant base load, build workloads, data processing and stateful services.
The trade-off is a broader operational scope. Hetzner's community tutorial for Kubernetes on bare metal explicitly notes that load balancing, fault tolerance, network security, hardening and CSI storage require additional configuration.
Production planning must answer:
- How are servers installed and replaced reproducibly?
- Where do the control-plane nodes and API endpoint run?
- How are hardware and data-centre failures isolated?
- Which data remains local, is replicated or uses external storage?
- How long does node or site recovery take?
Cluster API can automate the machine lifecycle. It does not replace capacity, storage and recovery architecture.
Kubernetes on Proxmox at Hetzner
Proxmox is not a prerequisite for Kubernetes. The combination is useful when a Hetzner dedicated environment must also host classic VMs, appliances, database servers or separated customer environments.
Kubernetes nodes run as VMs. This creates defined virtual resources and simplifies standardized provisioning of control-plane and worker nodes. It also creates two operational platforms:
- Proxmox owns compute, virtual networks, storage and VM availability.
- Kubernetes owns scheduling, service networking, deployments and workload state.
VM-level backups and Kubernetes backups serve different purposes. A VM snapshot replaces neither consistent database backups nor protection of Kubernetes resources and persistent volumes. Both layers need joint recovery testing. The Kubernetes on Proxmox guide explains the architecture in more detail.
Networking and secure access
Production clusters should not route management, node and workload traffic over public networks by accident. A typical design separates:
- private node-to-node traffic,
- Kubernetes API access for administrators and automation,
- public application entry points,
- private internal applications and management services,
- outbound traffic and, where required, stable egress addresses.
The Kubernetes API, Argo CD, Grafana and internal services can be reachable through NetBird as a private access path. Public applications instead receive controlled ingress or gateway endpoints.
Load balancing and ingress
On Hetzner Cloud, the Cloud Controller Manager can connect Kubernetes services of type LoadBalancer to Hetzner Cloud Load Balancers. An ingress controller or gateway then routes traffic to applications.
Bare metal does not provide this path automatically. External load balancers, HAProxy, kube-vip or MetalLB may fit depending on the network design. The choice depends on public IPs, BGP, layer-2 reachability and upstream networking. TLS termination and load-balancer failure handling must be defined before production.
Storage, databases and backups
For cloud nodes, the Hetzner CSI driver exposes persistent volumes. Bare-metal or Proxmox architectures may use local volumes, Ceph, Longhorn, Rook, NFS or external storage. None is universally correct.
The data model drives the choice:
- Can a volume move to another node?
- What latency and IOPS does the application require?
- Does the database replicate itself or should storage replicate?
- What recovery point and recovery time objectives apply?
- Where do backups go if the cluster or site fails?
A Kubernetes backup covers cluster resources, persistent-volume data and application-consistent database backups. Restore tests belong in the operating model, not only in the initial project.
GitOps, upgrades and observability
Kubernetes versions and platform components have separate release cycles. The desired state should therefore be versioned and rolled out automatically. A typical stack contains:
- Terraform or OpenTofu for Hetzner resources,
- Cluster API, Ansible or Talos for node and cluster lifecycle,
- Argo CD or Flux for platform and applications,
- Prometheus and Grafana for metrics,
- Loki or a comparable logging stack,
- Alertmanager and defined response paths,
- Velero and application-specific backup tools.
The decisive factor is not the length of the tool list but documented ownership: who upgrades Kubernetes, verifies backups, responds to alerts and owns the application?
Choosing an architecture
| Starting point | Likely starting model |
|---|---|
| New platform with dynamic workers | Hetzner Cloud with API-driven provisioning |
| Constant, compute-intensive base load | Dedicated workers with automated lifecycle |
| Existing Proxmox cluster and mixed workloads | Kubernetes nodes as standardized VMs |
| Several applications but little internal platform capacity | Operated cluster with explicitly defined scope |
| One small application on one server | Compare Docker Compose or Coolify before selecting Kubernetes |
WZ-IT can combine Hetzner infrastructure, the Kubernetes platform, NetBird access, GitOps and managed operations in one responsibility model. The architecture is derived from workloads, failure objectives, data, team and budget.
Sources
Rather have it operated?
You'd rather not run Kubernetes yourself? WZ-IT handles setup, operations and maintenance - GDPR-compliant from Germany.
Frequently Asked Questions
Answers to the most important questions
Hetzner provides cloud and dedicated resources plus Kubernetes integrations such as its Cloud Controller Manager and CSI driver. The Kubernetes control plane and platform components are built and operated by the customer or an operations partner. WZ-IT therefore provides managed operations for Kubernetes on Hetzner, not a native Hetzner managed Kubernetes product.
Cloud VMs suit API-driven and flexibly scalable node pools. Dedicated servers provide fixed performance and substantial local NVMe capacity, but require more automation for provisioning, replacement and storage. Hybrid architectures can combine both models.
No. Kubernetes can run directly on cloud VMs or bare metal. Proxmox is useful when the same hardware must also host VMs, separated tenants or other infrastructure workloads and a virtualization layer is operationally desirable.
On Hetzner Cloud, the official Cloud Controller Manager and CSI driver integrate load balancers and cloud volumes with Kubernetes. On dedicated servers, load balancing and storage require a separate design, such as external load balancers and a suitable distributed or external storage system.
The baseline includes private node networks, restricted Kubernetes API access, Network Policies, separated identities, secret management, hardened node images, regular updates and tested backups. Administrative access can additionally use NetBird instead of public endpoints.
Yes. Scope can include cluster lifecycle, GitOps, monitoring, logging, upgrades, backup and restore tests, and incident processes. Responsibilities and response times are defined separately for infrastructure, platform and applications.
More on Kubernetes
- What is Kubernetes?
- Do we need Kubernetes?
- Kubernetes vs Docker Compose vs Coolify
- Kubernetes on Proxmox
- Kubernetes on Hetzner
- Kubernetes on OVHcloud
- European Kubernetes providers compared
- k3s vs. RKE2 vs. Talos
- Longhorn vs. Rook-Ceph
- Kubernetes backup: the four layers
- Access Kubernetes privately with NetBird
- Gateway API vs. Ingress
- MetalLB vs. kube-vip
- Migrate from ingress-nginx to the Gateway API
- Migrate from Helm 3 to Helm 4
- Taking over a Kubernetes cluster: audit checklist
