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.
