Hetscale vs a do-it-yourself autoscaling script
Autoscaling Hetzner servers with your own script (the hcloud CLI, cron, a metrics alert) or with Hetscale, on the same six rows, and when each one fits.
| Row | Hetscale | A do-it-yourself script |
|---|---|---|
| Migration | None: your servers, your load balancer and your deploy tool stay as they are. | None: the script works on the servers and the load balancer you have. |
| Traffic path | Your Hetzner load balancer to your servers; your traffic never passes through Hetscale. | Your Hetzner load balancer; the script adds and removes its targets. |
| 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: the script boots new servers from a snapshot or with cloud-init, or calls your deploy. |
| Kubernetes needed | No. | No. |
| Per-server fee | None, and no meter either: your plan covers the capacity of your fleet. | None: the hcloud CLI is open source; the cost is the time to write the script and look after it. |
| 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. | On your own project, once the script is written. |
Facts about A do-it-yourself script as of October 2026, from the sources below.
When a script is the better choice
A script is the better choice for one server type in one location, with someone on call. When the load is predictable and a person notices a server that boots broken, a cron job that reads CPU and calls the hcloud CLI does the job, and it costs nothing but its upkeep. How to autoscale a web application on Hetzner Cloud without Kubernetes builds that loop step by step and lists where it needs more: health before traffic, the drain, the billing hour, stock, deleting the wrong server, flapping, missing metrics and a record of why.
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, but nobody wants to own the loop. It waits for the load balancer’s health check before a server counts, drains before it deletes, follows the location and type fallback when stock runs out, deletes only servers carrying its own labels and writes the reason for every action. Autoscaling for Hetzner shows how it works, the Docker Compose case the path from one server to a node group, and the calculator what a fleet that follows your load costs.
Sources
- hcloud, the Hetzner Cloud CLI (GitHub) checked 2026-10-02