Documentation

From 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.

The words Hetscale uses for autoscaling on Hetzner: node, node group, seed, release, adapter, traffic provider, readiness, drain, ownership labels, the modes.

Observe, Rehearsal, Propose and Live: what each mode may do on your Hetzner servers, how to switch between them, and what every action records.

Connect a Hetzner project with a Read token: where to create the token, what Hetscale checks before it stores it, and the read that follows.

Start a node group in Observe: answer three questions, pick a load balancer and a seed, then get the day-0 report and 14 days of decisions Hetscale would take.

The Go Live page's steps, in order: Live opened, the Read & Write token, delete protection, release v1, SSH keys, stock fallback, Rehearsal, the switch.

Put a new token of the same Hetzner project in place of the current one: when to do it, what Hetscale checks, which permission it accepts and what happens.

Node groups and projects are archived, never deleted: when a node group can be archived, what archiving stops, what stays readable, and how to restore.

Invite people to your organisation, what owners and admins can do, how seats count, what happens when someone leaves, and deleting your data.

Stop Hetscale, cancel the plan, delete your account, then find and remove what it left in your Hetzner project: servers, snapshots, placement groups, labels.

Retire the servers you ran before Hetscale one at a time, so servers of the node group take their place and the group can scale below their count.

Your pipeline deploys each new node: a signed node.created event, your deploy, a ready report, then the load balancer health check opens traffic.

Deploy to a webhook group from GitHub Actions with the Hetscale Deploy action: the deploy lock, the release, the server list and each new server.

Kamal 2 on a webhook group: the host list from the inventory, the deploy lock while Kamal rolls the fleet, and a deploy for each new server.

Autoscale an app Coolify deploys: Coolify keeps deploying to one server, Hetscale clones it. What the seed needs, the Sentinel step, a release per deploy.

How Hetscale decides to add or remove a Hetzner server: what it measures, the default thresholds, how many servers a scale-out adds, and what holds a scale-in.

Time to Capacity runs from the decision that asks for a server to its first healthy check at your load balancer: its phases, what shortens it, where to see it.

How Hetscale removes a Hetzner server: out of the load balancer first, a drain window for open requests, a clean shutdown, then a delete inside the paid hour.

When a Hetzner server stays unhealthy at your load balancer, Hetscale starts a new server beside it from the current release. What happens to the failed one.

What Hetscale does when Hetzner has no stock of your server type: the other locations of the zone, the fallback modes, capacity deficit and the stock view.

A schedule holds a node group at a floor or under a ceiling at the same time every week, so the servers for a known peak are there first. Pro and Team.

How Hetscale replaces servers on an older release one at a time, what stops it, and how to roll back to an earlier release.

Scrape every node group’s servers, newest Time to Capacity, state and limits from /v1/metrics in the Prometheus text format, on Pro and Team.

On Pro and Team, send alerts to a Slack or Discord channel, and alerts or every timeline event to your own signed webhook, beside the alert mail.

Read, export and change node groups with an API token: one JSON document per group, settings changed safely with If-Match, Observe started, the Archive.

On the first of each month, a mail adds up your node groups’ month: scale-outs, scale-ins, healings, time short of capacity, Time to Capacity and cost.

Every change in your organisation, by its people, their API tokens and Hetscale, sealed into a SHA-256 hash chain: reading it, exporting it, checking it.

Save a scaling policy once for your organisation and copy it into node groups on purpose: versions, applying them, and leaving a template. On Team.

The messages the panel shows when it refuses a Hetzner token, in its own words, with what each one means and what to do. Nothing is stored after a refusal.

Why a node group is paused, in the words the panel uses, and how to resume it: from its controls, on the billing page, or in the Hetzner Console.

The three counts on the dashboard and a project’s Reconciliation tab: servers Hetscale never touches, quarantined servers, and servers gone from Hetzner.

When a node group is short of capacity, and what else holds a new server: your plan, a euro ceiling, the cost guard, the node cap. What the panel shows.

Why a new server fails its health check or its Rehearsal, in the words the panel uses: where to look, the usual causes on a copy of the seed, and each fix.

The Hetzner Cloud limits a node group meets, from API requests and Primary IPs to networks and load balancer targets, and what Hetscale does at each one.

What Hetscale does with each Hetzner Cloud API answer, from 5xx and 412 to 423 and 429: retry, fall back, treat as done, wait or stop. A 429 never means gone.