Hetzner Cloud
Configure and validate Hetzner for servers, networks, volumes, firewalls and SSH keys.
Supported provider surface
The v0.0.5 Hetzner adapter covers account validation, resource discovery and planning for networks, virtual machines, volumes, firewalls, and SSH key import. The Kubernetes lifecycle remains a separate, agent-executed boundary.
Prepare the Hetzner project
- ✓Create a dedicated project or document the exact shared-project ownership boundary.
- ✓Create a scoped API token and store it through a ClusterPilot secret reference.
- ✓Select approved locations, server types, network CIDRs, firewall sources, volume policy, and naming convention.
- ✓Confirm quotas for servers, vCPU, primary IPs, networks, volumes, and other planned resources.
- ✓Prepare an approved SSH public key; keep private key material inside the supported secret-to-agent path.
- ✓Confirm outbound access to package and image sources, or complete the Harbor/air-gap plan first.
Rate limits and concurrency
Hetzner documents a default Cloud API limit of 3,600 requests per hour per project, with gradual replenishment. ClusterPilot also applies bounded provider concurrency, retry, and circuit-breaker behavior. Treat the provider response headers and ClusterPilot retry guidance as authoritative for the current request.
Hetzner Cloud API referenceNetwork and ingress decisions
| Decision | Single CP01 | Managed HA VIP |
|---|---|---|
| Control plane | One control-plane endpoint; non-HA. | At least three control-plane nodes. |
| Endpoint | Stable endpoint on CP01. | L2 VRRP/Keepalived virtual IP. |
| Ingress | HAProxy on CP01 can front workers. | HAProxy/Keepalived reconciliation across control-plane nodes. |
| Provider firewall | Must explicitly permit approved API and 80/443 sources. | Must permit VRRP/L2 design and approved client traffic. |
ClusterPilot can manage node host-firewall and endpoint configuration inside the lifecycle boundary. Provider-level firewalls remain provider infrastructure and must be included in the provider plan.
Provider acceptance evidence
- ✓Credential validation proves the intended project identity and no broader scope.
- ✓Create and delete tests leave no unowned servers, networks, IPs, volumes, firewalls, or SSH keys.
- ✓Rate-limit and transient provider failure recovery are tested without duplicate resources.
- ✓Private network routing, DNS, NTP, SSH, package/image access, and API endpoint traffic work from every node role.
- ✓A failed lifecycle run produces a complete residual-resource inventory and safe cleanup path.