Hetzner autoscaling for the servers you already run
Hetzner Cloud has no built-in autoscaling. Hetscale adds it to the servers you already run: new servers boot from your pinned release, take traffic only after your load balancer’s health check passes, and leave when load falls. No Kubernetes, no migration; your traffic never passes through Hetscale.
- Autoscaling and self-healing: capacity when load rises, a replacement when a node dies
- Pay for your normal load. Scale for your peak load.
- No Kubernetes, no migration: your account, your deploy tool, your traffic path
- Works with Docker or cloud-init, Coolify, and any webhook or CI
- Try it read-only first: 14 days of Observe on a read-only Hetzner token, no card
How does Hetscale autoscale Hetzner servers?
As of September 2026, Hetzner Cloud gives you servers, snapshots, a load balancer with a health check and an API, but nothing that decides how many servers to run or replaces one that stops answering. Hetscale runs that loop for a node group: the servers behind one load balancer that run the same stateless application.
- 01WatchCPU and requests read
Reads the CPU of each node and the requests at your load balancer through the Hetzner API. Missing metrics stop decisions; they never count as a server gone.
- 02Decideload high · one more
Compares them with the group’s scaling rules, and scale-in is always stricter than scale-out. Defaults: out when CPU stays above 75% for 3 minutes, in when it stays below 35% for 10 minutes. Yours to change.
- 03Createweb-4 · pinned release
Creates the server in your project from the release you pinned, never
:latest. When the type is sold out, it follows the fallback chain: another location in the same network zone, then, if you allow it, larger types in your order or the cheapest one in stock within your price cap. - 04Health checkweb-4 · no traffic yet
Your load balancer’s own health check opens traffic to the new node. Until it passes, the node receives nothing.
- 05Drain or replaceweb-4 draining
When load falls, a node leaves through the drain window: out of the load balancer first, then a clean shutdown and delete. A node that dies is replaced by one started beside it.
What do you need to start?
- A Hetzner Cloud project with your servers in it.
- A load balancer with a health check in front of them. No load balancer yet: Put your Docker Compose app behind a Hetzner Load Balancer.
- A stateless application behind it: the database, sessions and uploads live somewhere other than the servers that scale.
- A way to bring a new server up: a snapshot of your server, also one Coolify deploys to, or a webhook to your CI.
Where you start decides the work before it: the onboarding cases give each starting point its prerequisites and fit, and the setup Hetscale does not fit says why and what would change that.
What keeps you in control
- Ownership guardDeletes only servers it created or a seed you promoted: ledger, labels and name must all match.
- Health gateNo node receives traffic before your load balancer says it is healthy.
- Pinned releaseEvery new node boots the release you chose, never :latest. Shown on the group page.
- ProposeApprove each scaling action in the dashboard; unapproved proposals expire.
- RehearsalWatch one node created, checked, drained and deleted before going Live.
- Emergency stopPause a group, or stop every create and delete in it; moving to a safer mode is immediate.
- Action logEvery action carries its trigger, the metric values and the rule that fired.
- web-4draining
- web-3healthy
- web-4 · clean shutdown and deletea server it created
- web-3 · never touchednot in the ledger
What does it cost?
Pay for your normal load. Scale for your peak load.
Your account, your bill: the server you already run keeps its price, and the nodes added for a peak are billed hourly by Hetzner only while they run. Hetscale’s plan is a flat monthly price for the node capacity it covers, with no per-server fee and no meter.
Plans and pricesFrequently asked questions
Does Hetzner Cloud have autoscaling?
No. As of September 2026, Hetzner Cloud has no auto scaling group: nothing holds a number of servers, applies a scaling rule or replaces a server that fails. It has the parts one is built from: servers, snapshots, a load balancer with health checks, labels, hourly billing and an API. Hetscale adds the group on top of them, in your own project.
Do I need Kubernetes?
No. Hetscale works with the servers you run today, whatever runs on them: Docker, cloud-init, Coolify or your own deploy. Kubernetes is the right tool for many services with different scaling and scheduling needs; for one stateless web tier behind a load balancer, a node group does the job with far less to operate.
Can a new node receive traffic before it is ready?
No. A new node joins your load balancer as a target when it boots or, with the webhook adapter, once your pipeline reports it ready; the load balancer then sends it no traffic until it passes the health check you already configured, and that status is the signal Hetscale trusts. A report or probe of yours never opens traffic on its own. A node that never passes within the deadline is destroyed and the attempt is logged with the load balancer's reason.
What is self-healing?
If a node stays unhealthy at the load balancer for 3 minutes and Hetzner does not report it as rebooting, Hetscale creates a replacement beside it from the group’s current release, waits for the replacement to pass the health check and routes to it. Capacity is added before anything is removed. In a group with a minimum of 2 or more, a failed node Hetscale created, or a seed you promoted, leaves once its replacement serves and the group’s “Keep a failed server” time has passed: its diagnostics are recorded, then it is drained and deleted. A failed node of a group with a minimum of 1, your seed server and any other server of yours are never deleted: they stay out of traffic for diagnosis until you remove them or they are healthy again. If the replacement fails its health check too, healing stops after that one attempt and alerts you, because two failures in a row point at the release, not the server. When every server of a group with a minimum of 2 or more fails at once, the cause is something they share, such as the load balancer or a database: Hetscale replaces none of them, alerts you once, and after 10 minutes starts one new server as a test.
A node that is unhealthy while its own CPU is pinned counts as overloaded, not dead: the group scales out instead of replacing it. When capacity cannot be added (at the maximum, the cost guard, your node cap or euro ceiling, a stock shortage), nothing is replaced or removed; the group is marked attention required and you are notified, and again if it lasts. In detail: What happens when a server dies.
What if the Hetzner API is unavailable or a create fails?
A rate-limited API pauses decisions and an unavailable one is tried again; neither is ever read as "server gone". A create that fails is retried from its recorded intent, never duplicated. When your server type is sold out, Hetscale tries another location of the same network zone, then, if you allow it, up to three larger types in your order, or the cheapest one in stock within a price cap you set, until your type is back, and tells you what it did. The group page shows whether each location sells the type now and its share over 30 days, with a recommendation that is shown, never applied; if the whole chain is exhausted the group is marked in capacity deficit and you are notified. Scale-in never happens while metrics are missing. In detail: When your Hetzner server type is sold out and Hetzner API errors and what Hetscale does.
Can Hetscale delete servers that are not part of a group?
No. It deletes only servers it created and a seed server you promoted to a managed member, and only when their labels and name match its ledger. Anything else is listed and never shut down or deleted, even if it sits behind the same load balancer.
What if Hetscale itself goes down?
Your servers keep running exactly as they are; traffic never depended on Hetscale. Nothing scales or heals until it is back. When it is back, it re-reads the current state of the project and continues from there: a server it had already started to remove finishes leaving, and nothing else is deleted because it was away.
When should I not use Hetscale?
When load is flat (one fixed server is cheaper than any control plane), when state lives on the node, when you already run Kubernetes with a working autoscaler, or when your servers are not on Hetzner Cloud. Hetscale next to Kubernetes on Hetzner and a do-it-yourself script, with when each is the better choice: Compare.
Related reading
- How to autoscale a web application on Hetzner Cloud without KubernetesHetzner has no auto scaling group and you do not need Kubernetes to build one. What autoscaling needs on plain servers, the loop by hand, and where it bites.
- AWS Auto Scaling Groups, explained for Hetzner usersHetzner Cloud has no auto scaling group. What each part of an AWS ASG does, and what Hetzner has in its place: a snapshot, a load balancer, an API, or nothing.
- Put your Docker Compose app behind a Hetzner Load BalancerCreate a Hetzner Load Balancer, add a health check, move TLS from the server to the balancer without downtime, point DNS at it. One server today, more later.
- From one Coolify server to automatic scaling on HetznerCoolify deploys to several servers but does not decide how many. What has to move off a single Coolify box before the app can scale, and how an autoscaler fits.
- QuickstartFrom a Hetzner project to a node group in four steps: connect read-only, read the day-0 report, run one Rehearsal, go Live with a floor of two nodes.