Build a Kubernetes cluster on Hetzner or have it taken over? WZ-IT chooses the provisioning path to fit team and workloads, builds the cluster on Hetzner Cloud or dedicated servers and operates it on request. See Kubernetes on Hetzner
Provisioning a Kubernetes cluster on Hetzner runs through four documented paths: the Terraform/OpenTofu module kube-hetzner, the CLI hetzner-k3s, Talos Linux (with talosctl or the community module hcloud-talos) and, for dedicated servers, the Cluster API Provider Hetzner. This comparison relies exclusively on the projects' repositories, releases, licence files and documentation, retrieved on 28 October 2026. As of October 2026. Assessments that are not evidence are labelled as such.
Contents
- What all paths have in common
- Project status compared
- Operations: upgrades, rollback and backup
- Platforms: ARM64 and dedicated servers
- The paths in detail
- Which path fits which team
- Status and methodology
- Our approach at WZ-IT
- Related guides
What all paths have in common
All paths connect Kubernetes to the platform through the same two Hetzner components. The Cloud Controller Manager (CCM, Apache-2.0, v1.39.2 from 22 October 2026) connects the Hetzner Cloud and Robot APIs and creates load balancers for services of type LoadBalancer. The CSI driver (MIT, v2.24.1 from 22 October 2026) provides Cloud Volumes as ReadWriteOnce volumes. Both projects build images for amd64 and arm64 (CCM, CSI). The Cluster API Provider Hetzner can use both components as well; for bare metal its documentation currently recommends the Syself CCM fork instead of the Hetzner CCM until an upstream release contains the fix for the Robot name lookup. Three properties apply regardless of the tool:
- Storage on Robot servers: the CSI driver does not work there. Dedicated workers need their own storage, for example Longhorn or Rook-Ceph (comparison). The CCM does not support routes for Robot servers; the CNI handles the pod networks.
- Kubernetes versions: according to its version policy, the CCM supports the three newest Kubernetes versions. For Kubernetes 1.34 to 1.37 the latest CCM version applies, for 1.33 version v1.37.0.
- Add-on versions: the tool decides which version runs in the cluster. kube-hetzner v3.2.1 sets CCM 1.33.0 and CSI 2.21.2 as defaults (source code, retrieved on 28 October 2026). The hetzner-k3s configuration reference names the same versions as manifest URLs. Older versions can lose functionality: CCM up to v1.30.0 no longer sets zone and region labels on newly initialised nodes since 1 July 2026 (note in the README).
Project status compared
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| Type | Terraform/OpenTofu module | CLI with YAML file | Operating system with talosctl; on Hetzner via CLI or the community module hcloud-talos |
| Licence | MIT | MIT | MPL-2.0; hcloud-talos: MIT |
| Current release | v3.2.1 (9 Sep 2026) | v2.7.0 (25 Oct 2026) | v1.14.5 (26 Oct 2026); hcloud-talos v4.1.4 (26 Oct 2026) |
| Recent releases | v3.0.0 (6 Jul), v3.1.0 (8 Aug), v3.2.0 (31 Aug 2026) | v2.5.0 (7 May), v2.6.0 (24 Jun 2026) | v1.14.0 (3 Sep), v1.14.2 (29 Sep 2026) |
| Maintenance | Open-source project, not affiliated with Hetzner | maintained by one developer according to the README | Sidero Labs, optional commercial support; Hetzner is a tier 3 platform |
| Distribution | k3s or RKE2 | k3s | Upstream Kubernetes (1.33 to 1.37 with Talos 1.14) |
| Node operating system | openSUSE Leap Micro (MicroOS for existing clusters) | Ubuntu 24.04, other images by ID | Talos Linux without SSH and shell |
| Prerequisites | OpenTofu or Terraform, Packer, kubectl, hcloud | the CLI, Hetzner token, SSH key | talosctl, image, endpoint for the Kubernetes API (for example a load balancer) |
Sources: kube-hetzner README and releases, hetzner-k3s releases, Talos releases and support matrix, hcloud-talos README.
Operations: upgrades, rollback and backup
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| Kubernetes upgrade | system-upgrade-controller, automatic or controlled by node label | hetzner-k3s upgrade, then check the jobs and run create again (docs) |
talosctl upgrade-k8s, beforehand with --dry-run (docs) |
| Operating system update | transactional, reboots through Kured | drain, update, reboot; Kured optional | talosctl upgrade with a new image |
| Operating system rollback | BTRFS rollback of the transactional system | not described in the docs | A/B image, fallback on boot failure, manually with talosctl rollback (docs) |
| Changes to the cluster | tofu plan and apply; major jump with a migration guide |
change the YAML, run create again |
apply or patch the machine configuration |
| etcd backup | S3 snapshots through etcd_s3_backup (docs) |
snapshot schedule, optional S3 | talosctl etcd snapshot, set up the schedule yourself (docs) |
| State | Terraform/OpenTofu state | YAML file, no Terraform state according to the docs | machine configuration and secrets; with hcloud-talos in the state |
Two details from the documentation affect day-to-day work. With hetzner-k3s the create command is explicitly required after an upgrade so that new nodes are created with the new k3s version right away. With Talos 1.14 the installer image is no longer published as ghcr.io/siderolabs/installer but delivered through the Image Factory as factory.talos.dev/metal-installer/<schematic-id>:<version>; upgrade scripts with the old path need to be adjusted.
Platforms: ARM64 and dedicated servers
| kube-hetzner | hetzner-k3s | Talos Linux | |
|---|---|---|---|
| ARM64 (CAX) | x86 and ARM can be mixed (support matrix) | ARM pools through image ID | amd64 and arm64; one image per architecture |
| Dedicated servers | Robot servers as additional agents over a vSwitch (docs), rated Advanced/special-case (support matrix) |
external worker pools with provider: robot, since v2.6.0; private network since v2.7.0; Debian or Ubuntu (docs) |
platform Metal (tier 1) through ISO or PXE; the Hetzner guide describes only the cloud |
| Control plane | Hetzner Cloud | Hetzner Cloud | Cloud or Metal |
| CCM and CSI | in the module, fixed default versions | in the tool, changeable through manifest_url |
install yourself |
For Talos on Hetzner Cloud, Hetzner has provided a public ISO since 23 April 2025, updated on a best-effort basis. Custom images are created in rescue mode, with Packer or with hcloud-upload-image. The community module hcloud-talos points out that some Hetzner ISOs have started Talos in metal mode instead of hcloud, which produces wrong provider IDs and broken CCM routes (issue 417); it recommends custom snapshots.
For pure bare-metal clusters the Cluster API Provider Hetzner (CAPH, Apache-2.0, v1.1.10 from 22 October 2026) is the fourth path. It manages cloud and bare metal, requires a management cluster and is based on kubeadm; the node images need a container runtime, kubelet and kubeadm. The project is maintained by Syself and the community, not by Hetzner. According to the documentation, the bundled bare-metal flavors are for demonstration only and not for production. For production, the tutorial in the Hetzner Community (author: Syself) recommends a custom configuration with load balancing, fault tolerance, network security and hardening.
The paths in detail
kube-hetzner describes the cluster as a module in the infrastructure code: control plane and agent pools, private network, firewall, load balancer and add-ons. The module works with OpenTofu and Terraform; how the two differ is covered in the guide Migrate Terraform to OpenTofu. State and module versions need attention: the move from v2 to v3 has its own guide that has you review every planned destroy or replace before the apply. The support matrix lists k3s on Leap Micro as the stable default and RKE2 as a supported variant.
hetzner-k3s creates servers, firewall and private network, installs k3s and sets up the CCM, CSI, System Upgrade Controller and Cluster Autoscaler. Everything is in one YAML file. Four months lie between v2.6.0 (24 June 2026) and v2.7.0 (25 October 2026), and according to the README the project is maintained by one developer. Anyone operating clusters with the CLI should factor this dependency into the assessment.
Talos removes SSH and shell; every change goes through the API. On Hetzner Cloud the team sets up the image, API endpoint (load balancer), CCM and CSI itself, or uses the community module hcloud-talos, which provides networking, Cilium, CCM and the Talos CCM. The module names its limits: changes to user_data and image are not applied to existing nodes, Kubernetes upgrades run through talosctl upgrade-k8s, and the supported Talos versions are tied to Kubernetes ranges (Talos 1.14.3 and newer with Kubernetes 1.32 to 1.37). For Talos itself see What is Talos Linux? and the comparison k3s vs. RKE2 vs. Talos; automation with OpenTofu on Proxmox is shown in Automate Talos on Proxmox with OpenTofu.
Which path fits which team
The following table is an assessment by WZ-IT. The "Evidence" column names the documentation basis.
| Starting point | Obvious path | Evidence |
|---|---|---|
| IaC routine with Terraform or OpenTofu, several environments from code | kube-hetzner | module in the state, Kured and System Upgrade Controller, OS rollback |
| One or a few clusters, no IaC stack, Ubuntu preferred | hetzner-k3s | one YAML file, no Terraform state; no OS rollback described |
| No SSH on nodes, API-driven configuration, A/B rollback | Talos | Hetzner tier 3, install CCM and CSI yourself, talosctl routine required |
| Dedicated servers as workers next to a cloud control plane | hetzner-k3s or kube-hetzner | Robot pools or vSwitch guide; CSI does not work there |
| Cluster made of dedicated servers, declarative management | Cluster API Provider Hetzner | management cluster required, flavors are demo only |
| Small team without capacity for upgrades and backups | operations by a third party | with every path, restore tests, monitoring and add-on maintenance remain with the operator |
Six questions need answers before the decision:
- Who runs the next Kubernetes upgrade, and with which command?
- Who updates the CCM and CSI, and when?
- Where is the etcd snapshot stored, and when was it last restored? (Backup and restore)
- Are control planes spread across several locations?
- Which sources may reach the Kubernetes API, SSH or the Talos API?
- Do workers need dedicated servers, and which storage carries the volumes there?
Status and methodology
The tables show the state as of 28 October 2026. Release dates come from the projects' GitHub releases, licences from the LICENSE files, functions from the README and documentation in the respective repository. Nothing was measured: no speed, no cost, no stability. Where the documentation does not describe a point, the table says "not described", not "not possible". The table on team size is an assessment. Version numbers and ratings change; the article gives the source for every figure.
Sources, retrieved on 28 October 2026:
- kube-hetzner: README, support matrix, upgrades, Robot guide, locals.tf v3.2.1
- hetzner-k3s: README, documentation on cluster, maintenance, external nodes
- Talos Linux: releases; documentation on Hetzner, upgrades, support matrix
- hcloud-talos and Cluster API Provider Hetzner: README and documentation
- Hetzner Cloud Controller Manager and CSI driver: README, version policy, Robot notes
Our approach at WZ-IT
We first clarify workloads, failure targets, team and the existing infrastructure pipeline, then the path. The cluster is built on your Hetzner resources: Cloud, dedicated or both, with private access to the API, GitOps and tested backups. Operating an existing or new cluster is available as Managed Kubernetes from €590 per cluster per month net, including 3 worker nodes (as of October 2026); each additional worker node costs €129.90. Monitoring runs 24/7, and the response to P1 incidents follows the service level. A cluster that is already running can be reviewed before the takeover with the cluster audit; the procedure is described in the audit checklist. The overview of architecture, networking and storage on Hetzner is in Kubernetes on Hetzner.
Related guides
- Kubernetes on Hetzner - Cloud, bare metal or Proxmox, networking, load balancers and storage
- k3s vs. RKE2 vs. Talos - distributions compared
- What is Talos Linux? - operating model without SSH
- Migrate Terraform to OpenTofu - migration guide for the infrastructure code
- Kubernetes backup and restore - the four layers
- MetalLB vs. kube-vip - load balancing on bare metal
Build a cluster on Hetzner or have operations taken over? WZ-IT plans cloud, dedicated and hybrid clusters and operates them by service level. Kubernetes on Hetzner · Managed Kubernetes
