Frequently asked questions

It runs one loop per node group: monitor, decide, provision, deploy through your adapter, verify by load balancer health, route, heal, drain, destroy. Inputs are CPU per node and the request and open-connection metrics from the load balancer, read once a minute while your Hetzner project holds up to 25 nodes and less often per node above that, inside the Hetzner API budget, which is counted per project. While a project only observes, its read-only token cannot change anything in it. Before the Rehearsal, Hetscale turns on the delete protection you confirm and snapshots your seed; the Rehearsal then creates one short-lived server and deletes it again while you watch. It is a control plane only; your traffic never passes through us.

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 of your seed, then waits for it to pass the load balancer health check. With the webhook adapter your CI or a shell script deploys the current release to it and reports it ready. If Coolify deploys your seed, it keeps deploying there, and the new server is a copy Coolify never learns about. No agent is required and Hetscale never has SSH access to your servers. The one thing it sends with a new server is a fixed cloud-init step, the same for every server and without secrets, that removes Coolify’s monitoring container, Sentinel, where there is one, so a copy never reports to Coolify as your seed. An optional metrics agent comes later.

group: web
provision:
  snapshot: my-web-snapshot
  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. Scale-out adds the nodes the load needs, within the group’s rate cap (one node per 5 minutes with the default Balanced policy) and its per-hour cost guard, and counts nodes on their way or warming up as capacity; scale-in removes one node at a time, after a cooldown that follows every action, and only when the remaining nodes would stay under the scale-out threshold. Scale-in is always stricter than scale-out, and it never happens while metrics are missing, stale or rate-limited. In detail: When Hetscale adds or removes a server.

Observe: records what it would have done; while a project only observes, its token can only read. Rehearsal: a supervised rehearsal that creates one short-lived server, checks it, drains and deletes it while you watch; Hetzner bills at least one started hour. Propose: each scaling action waits for your approval; healing acts on its own. Live: executes inside your range. A group moves to a safer mode at any time, with immediate effect; Live needs a passed Rehearsal, and Propose is a switch of a Live group.

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, Falkenstein)
       reason: CPU 78% > 75% for 3 min
       range:  2–6, now 4 → 5
       cost:   +1 node-hour, billed by Hetzner

No. Set the range and the mode once. In Live it acts inside that range and writes a line with the reason for every action; in Propose it waits for your approval. Notifications tell you when something changed state; the log is there when you want to read it.

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.

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. In detail: Removing a server without dropping requests.

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.

Hetscale does not read Hetzner’s status page. While Hetzner shows a server starting, stopping, migrating or in another transitional status, or an action locks it, its minutes do not count toward healing. For a maintenance of your load balancer, or of the network in your location, announced on Hetzner’s status page, choose Hold for maintenance in the group’s Controls for the window. Until it ends, no server is scaled in or replaced for looking unhealthy, and scale-out goes on. Without the hold, when every server of a group with a minimum of 2 or more fails the health check together, Hetscale replaces none of them, alerts you once and, after 10 minutes, starts one new server as a test, and the group is not paused. When only some servers fail, or the minimum is 1, each failed server gets a new server beside it, the seed included, and three new servers in a row that fail pause the group until you resume it. In detail: What happens when a server dies.

The one you pinned for the group: a snapshot id or an image digest, never ":latest". The Deployment page shows the current release and when it was taken. For a group that boots from your seed’s snapshot, it warns once the release is older than 30 days. You can change that age, or leave it empty to turn the warning off. When you publish a new release you point the group at it, or take a new snapshot of the seed; new nodes use it, and running nodes keep theirs until they leave or you replace them, one at a time, from the group’s Servers page; an earlier release can be made current again on the Deployment page. If Coolify deploys your seed, new nodes start from the current release, not from Coolify: take a new release after each Coolify deployment has finished, and the Deployment page reminds you. The page shows the snapshots Hetscale took, their total size and what they cost a month at list price, and “Delete unused snapshots” deletes, in one confirmed click, those no release, server or new server needs; the current release and the two releases before it stay for a rollback. To keep new servers patched, take a new release. In detail: Releases, rollouts and rolling back.

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.

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.

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.

A project you only observe holds a read-only Hetzner token. It cannot create, change or delete anything; that is enforced by Hetzner, not by us. From the Go Live steps on, for Rehearsal, Propose and Live, the project needs a Read & Write token: you create it in the Hetzner Console and connect it with “Connect Read & Write” on the group’s Go Live page, and it takes the place of the read-only one, which is erased at once.

Hetscale holds that token. It is stored with envelope encryption, never placed in job payloads, and used only for the API calls the log shows. The master key that protects it lives in AWS KMS in Frankfurt and never leaves it: only Hetscale’s control plane may use it, from its own address, and every use is logged, with an alert on any other. The token is never written to a log or to any of your servers. Revoking it in the Hetzner Console stops Hetscale from that moment; a Hetzner action already accepted may still complete, and your servers keep running as they are.

Anything that creates and deletes servers for you needs a Read & Write token somewhere, whether you run it yourself or a service runs it: a self-run autoscaler keeps it in your cluster or on one of your servers. As of October 2026, a Hetzner token reaches a whole project, so give Hetscale a dedicated Hetzner project per application, and the token reaches that project alone. What Hetscale writes in your project, and what it never touches: Security.

Your users’ requests never pass through Hetscale, so a breach of Hetscale exposes none of them, and Hetscale holds no SSH private key: it never logs in to your servers. A project you only observe holds a read-only token, so at worst someone could read that project, never change it.

A Read & Write token is stored with envelope encryption. The master key that protects it lives in AWS KMS in Frankfurt and never leaves it: only Hetscale’s control plane may use it, from its own address, and every use is logged, with an alert on any other. A copy of our database or of its backups cannot open the token without that key.

The limit is the token itself. Someone who took over the control plane’s server could open the tokens as the control plane does, from its address, for as long as they held it; every use would still be logged. And as of October 2026 a Read & Write token reaches the whole Hetzner project, because Hetzner offers no narrower scope. The ownership guard is a rule in our software: it limits what Hetscale’s own code shuts down or deletes, not what someone holding the token can do through the Hetzner API.

So give Hetscale a dedicated Hetzner project per application, so the token reaches that project alone, and revoke the token in the Hetzner Console whenever you are in doubt: it stops working from that moment. If we become aware of a breach of the security of your data, we tell your organisation’s owner by email without undue delay, and within 48 hours at the latest, as the data processing agreement says. In detail: Security.

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 (a snapshot of your server, also one Coolify deploys to, or a webhook to your CI). 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 creates the server from the snapshot of your seed, or hands it to your CI through a webhook, whether Docker Compose, cloud-init or Coolify put your application on the seed. With Coolify, Coolify keeps deploying to the seed and Hetscale copies it: it calls no Coolify API and holds no Coolify token, and new servers need no registry image, no multi-server setup and no Coolify server slot. Coolify itself runs on another server, TLS ends at the load balancer (an http:// domain in Coolify, or its proxy set to None), and the .env files Coolify writes on the seed are in every snapshot, like anything else on its disk. A mode in which Coolify deploys each new server itself is planned. In detail: Coolify in the docs.

No. Every new node boots from the group’s current release: a snapshot id or an image digest, never ":latest". When you publish a new release, point the group at it; new nodes use it, and running nodes keep theirs until you replace them, one at a time, from the group’s Servers page. With Coolify you keep deploying in Coolify and take a new release in Hetscale after each deployment has finished. While your own pipeline rolls the fleet, it holds the group’s deploy lock through the API, so scaling waits and a failed server is still replaced.

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.

Yes: give the node group the same Min and Max, when you choose Go Live on its Go Live page or later under Capacity in its Settings. The group then keeps that many servers, your own included, and Hetscale adds or removes none for load. Healing works as in any group: a server your load balancer reports unhealthy for 3 minutes, while Hetzner reports no reboot or lock, gets a new server beside it from the current release, which takes its slot, so the count stays the same. With a minimum of 2 or more, a failed server Hetscale created leaves through the drain window once its replacement serves and the group’s “Keep a failed server” time has passed; with a minimum of 1 it stays, out of traffic and still billed by Hetzner, until you remove it or it is healthy again. If the new server fails too, healing stops after that one attempt and alerts you. “Replace older servers” on the Servers page moves the servers Hetscale created to a new release, one at a time. Your seed is never removed or replaced unless you promote it: if it fails, a server starts beside it.

Two things to know. A server that is unhealthy while its own CPU is pinned is overloaded, not dead, and a group already at its maximum cannot scale out: once the overload grace has passed, nothing is replaced or removed, the group page shows “Attention required” and you get an alert. And the group goes Live like any other: it needs a plan, a Read & Write token and a passed Rehearsal, and its servers count toward your plan, the seed included. In detail: What happens when a server dies.

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, there is no meter and we never take a percentage of your Hetzner bill: a Hetscale plan is a flat monthly price for the node capacity it covers.

Every node of your node groups in Live or paused, added up over every Hetzner project you connect: Starter 5, Growth 20, Pro 50, Team 150. That includes the servers you already run, the group’s seed among them; a node group in Observe is not counted, and neither is a node that is draining. Node groups are unlimited on every plan.

The nodes are still created: the capacity is a commercial number, never the reason your application runs short during a peak. The time spent above it counts against a monthly budget (Starter 24 h, Growth 48 h, Pro 72 h, Team 120 h) that resets on the first. When that budget is spent, one mail gives you seven days to move up a plan; after that new nodes above the capacity are held until you change the plan or the month ends, nothing running is touched, scaling below the capacity continues and the plan never holds healing. A switch on your organisation’s profile keeps you within the plan instead. There is no overage billing and no meter.

No. Hetscale shows the cost of the nodes it created, computed from Hetzner list prices, and the worst case for a group at max. It does not know your other projects, volumes, snapshots or legacy prices and does not guess at them; the figure is not your Hetzner invoice.

Your existing server keeps the price it has today: Hetscale never replaces it or scales it in unless you promote it to a managed member. Even then, a scale-in takes the servers created since the price change first. Only the nodes added for a peak are billed at today's hourly rate, and only for the hours they run. The calculator uses today's list prices for those hours.

A member of your organisation, or an invitation still open. Starter has two seats, Growth three, Pro five; Team has viewer, operator and admin roles instead of a seat count. The owner or an admin invites by address from the Members page; the link works for a week and only for that address. A downgrade removes nobody: new invitations wait until members leave.

When the 14-day trial ends, polling stops and you keep a free monthly capacity report: refresh it every 30 days with a read-only token, no polling in between, no card. If a payment fails or a plan is cancelled there is a 14-day grace period, then Hetscale only observes your groups until a plan applies again; nodes are never destroyed and everything stays in your Hetzner project. What stays, and how to remove it when you leave: Leaving Hetscale.

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 us. This website sets no cookies.