Hetscale vs Kubernetes on Hetzner
Autoscaling on Hetzner with Kubernetes (kube-hetzner, hetzner-k3s, Syself Autopilot) or with Hetscale on the servers you run, on the same six rows.
| Row | Hetscale | Kubernetes on Hetzner |
|---|---|---|
| Migration | None: your servers, your load balancer and your deploy tool stay as they are. | Containerise the application and move it into a Kubernetes cluster on Hetzner: one you build with kube-hetzner or hetzner-k3s, or one Syself Autopilot runs. |
| Traffic path | Your Hetzner load balancer to your servers; your traffic never passes through Hetscale. | The cluster’s ingress, which routes requests to the pods that serve them. |
| Who deploys | You, with the tool you use today: new servers boot from a snapshot of your server, or your own pipeline deploys them through a signed webhook. | You, to the cluster: manifests or Helm charts from your CI or a GitOps tool; Kubernetes places the pods on the nodes. |
| Kubernetes needed | No. | Yes. Built yourself, you run the cluster, its upgrades and the Cluster Autoscaler, which adds nodes when pods cannot be scheduled. Syself Autopilot runs the cluster’s lifecycle (provisioning, scaling, upgrades) for you. |
| Per-server fee | None, and no meter either: your plan covers the capacity of your fleet. | Built yourself: none; kube-hetzner, hetzner-k3s and the Cluster Autoscaler are open source, and the cost is the time to run them. Syself: no charge per node or cluster; a base platform fee from €299 plus a share of your cloud spend that varies by plan, or a free plan with one cluster of up to 5 nodes. |
| Try it with your own data | Observe: connect a read-only Hetzner token; Hetscale reads 30 days of history, writes a ranged report, then records for 14 days what it would have done. | Built yourself: build a cluster and deploy a copy of the application to it. Syself: a 14-day trial with full access, or the free plan. |
Facts about Kubernetes on Hetzner as of October 2026, from the sources below.
When Kubernetes on Hetzner is the better choice
Kubernetes is the better choice when you run many services that share one pool of servers, or when scheduling is complex: workloads with different resource needs, placement rules, jobs and long-running services side by side. The Cluster Autoscaler then adds nodes when pods cannot be scheduled and removes them when their pods fit elsewhere. If you already run Kubernetes on Hetzner with a working autoscaler, keep it. Hetscale declines a load balancer or a seed that Kubernetes manages: it scales servers that run without Kubernetes. Syself Autopilot fits when you want that cluster without running its upgrades and failover yourself.
When Hetscale is
Hetscale is the better choice when your servers are already on Hetzner, the web tier is stateless and sits behind a load balancer, and the team keeps the deploy tool it has. It adds servers to a node group in your own Hetzner project when load rises, removes them when it falls and replaces the ones that fail; nothing moves into containers or a cluster. Autoscaling for Hetzner shows how it works, the load-balancer-ready case the setup, and the calculator what a fleet that follows your load costs. The long comparison, with the loop built by hand, is in How to autoscale a web application on Hetzner Cloud without Kubernetes.
How do Cluster Autoscaler settings map to Hetscale?
| Cluster Autoscaler | Hetscale |
|---|---|
--scan-interval, default 10 s: how often the cluster is evaluated |
No setting: each node group is decided once a minute, from metrics at one-minute resolution |
--max-node-provision-time, default 15 min, can be set per node group |
“Readiness deadline”, per node group, 15 minutes by default, 5 to 60: a new server that has not passed the load balancer’s health check by then is deleted and reported |
--scale-down-delay-after-add, default 10 min |
“Wait after any change before removing a server”, per node group, counted after every change: a scale-out, a scale-in, a healing, a change of yours or a schedule |
--scale-down-unneeded-time, default 10 min: how long a node must be unneeded before it can be removed |
The window of the node group’s scale-in rules: a server is removed only when every scale-in rule holds for its whole window, by default CPU below 35% for 10 minutes |
| Several node pools | Several node groups, for example one per application; within one node group, fallback types while its own type is out of stock: up to three in your order, or the cheapest in stock within a price cap |
The trigger does not map. The Cluster Autoscaler adds nodes when pods cannot be scheduled on the nodes there are. Hetscale adds servers when the CPU, requests per second or open connections per server it measures cross a rule of the node group, and it has no pods to place. The Cluster Autoscaler’s defaults come from its FAQ, read in October 2026.
Sources
- kube-hetzner (GitHub) checked 2026-10-02
- hetzner-k3s (GitHub) checked 2026-10-02
- Cluster Autoscaler, Hetzner provider (GitHub) checked 2026-10-02
- Cluster Autoscaler FAQ (GitHub) checked 2026-10-18
- Syself Autopilot for Hetzner checked 2026-10-02
- Syself pricing checked 2026-10-02
- Syself Kubernetes autoscaling checked 2026-10-02