Frequently asked questions

It runs one loop per scaling group: monitor, decide, provision, deploy through your adapter, verify by load balancer health, route, heal, drain, destroy. Inputs are CPU per node and request metrics from the load balancer, read once a minute for small groups and less often per node for large ones, inside the Hetzner API budget. Two modes never touch anything: Observe and Rehearsal. It is a control plane only; your traffic never passes through it.

A node is one Hetzner Cloud server. A node group is a set of identical, stateless nodes behind one load balancer that scale together within a min–max range. Most setups have one group, for example "web".

Hetscale creates the server from the snapshot, image or cloud-init you configured for the group, then waits for it to pass the load balancer health check. You can also point it at a webhook (your CI, a shell script) that runs your own deploy, or let the Coolify adapter register the node with your Coolify instance. No agent is required and Hetscale never has SSH access to your servers; an optional metrics agent comes later.

group: web
provision:
  snapshot: my-web-snapshot
  cloud_init: ./cloud-init.yaml
  webhook: https://ci.example.com/deploy   # optional

Example defaults: scale out when CPU is above 75% for 3 minutes; scale in when CPU is below 35% for 10 minutes; a cooldown after every action and a warm-up after a node becomes active. Scale-in is always stricter than scale-out, and it never happens while metrics are missing, stale or rate-limited.

Observe: read-only token, records what it would have done. Rehearsal: a supervised dry run that creates one node, checks it, drains and deletes it while you watch. Propose: each action waits for your approval. Live: executes inside your range. Any group can move between modes at any time; moving to a safer mode takes effect immediately.

Each action in the log carries the trigger, the metric values at that moment, the rule that fired, the range it was allowed to act in, and what it costs in node-hours. The same entry exists in Observe mode, prefixed with "would". Nothing happens without a line you can read.

15:00  create web-5 (cx33, fsn1)
       reason: CPU 78% > 75% for 3 min
       range:  2–6, now 4 → 5
       cost:   +1 node-hour, billed by Hetzner

No. A node becomes a load balancer target only after it passes the health check you already configured on the load balancer; that status is the signal Hetscale trusts. An optional extra probe of yours can only delay a node, never open traffic. A node that never passes within the deadline is destroyed and the attempt is logged with the load balancer's reason.

It is removed from the load balancer first, existing connections are given the drain window (default 60 seconds, up to 300) to finish, then the server is shut down cleanly and deleted. A node is never deleted while it is still a load balancer target.

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. The failed node is not deleted by healing: it is kept out of traffic for diagnosis and cleaned up by you, or by a normal scale-in once capacity is back. 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.

No. It deletes only servers it created, whose labels and name match its ledger. Anything else is listed, never touched, even if it sits behind the same load balancer.

Your servers keep running exactly as they are; traffic never depended on Hetscale. No scaling happens until it is back. Nothing is deleted on reconnect: it re-reads the current state of the project and continues from there.

A rate-limited or failing API pauses decisions; it is never read as "server gone". A create that fails is retried from its recorded intent, never duplicated. A server type out of stock is skipped for the fallback type or location you allowed; 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.

For the Observe trial, a read-only Hetzner project token. For Rehearsal, Propose and Live, a Read & Write token for that project, stored with envelope encryption. Revoking it in the Hetzner Console stops everything.

A Hetzner Cloud project, a load balancer with a health check, at least one server behind it, and a way to bring a fresh server up (snapshot, cloud-init, Coolify or a webhook). The trial needs only the read-only token.

Yes, for the group that scales. Anything on the node’s local disk is lost when the node is removed. Databases, queues and file storage should live on their own servers or managed services, outside the group.

Yes. Hetscale does not care what runs on the node. It creates the server and hands over to your adapter: a snapshot, cloud-init, a webhook to your CI, or the Coolify adapter, which registers the node with your Coolify instance and triggers the current deployment.

No. Every new node boots from the group’s current release: a snapshot id, an image digest or a Coolify deployment, never ":latest". When you publish a new release, point the group at it; new nodes use it, and a rolling replace swaps the existing ones surge-then-remove. Your own rollout can hold a deploy lock so scaling waits for it.

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.

No. Hetzner Cloud only. Dedicated servers cannot be created on demand through the Cloud API, so they cannot be autoscaled this way.

Hetzner, at Hetzner prices, on your own invoice. We don't charge per server and never take a percentage of your Hetzner bill; the only add-on is an extra scaling group at €4/month.

A person who can log in to the dashboard, approve Propose-mode actions and change settings. Solo has one seat, Pro three to five; Team has viewer, operator and admin roles.

When the 14-day trial ends, polling stops and the report is kept; you can refresh it once every 30 days. If a payment fails or a plan is cancelled there is a 14-day grace period, then groups drop to Observe; nodes are never destroyed and everything stays in your Hetzner project.

Metrics, decisions and the action log are stored in the EU. Hetscale stores no request payloads and sees no customer traffic, because none of it passes through it. This website sets no cookies.