Go Live

A node group goes Live from its Go Live page, one step after the other: Hetscale writes to your project only through these steps, and scales only after the last one. Each step shows its state, such as Done, Next, Waiting or Optional. Where Go Live sits in the whole path, from connecting to a floor of two servers, is in the quickstart.

1. Live opened for your organization

Live needs a plan. Until your organization has one, the step says so, and the organization’s owner chooses one on the Billing page; the first payment opens Live. Once it is open, the step names the plan and the servers it covers. If the plan ends, the step says so, and Live resumes once a plan applies again.

2. Read & Write token

A Read token cannot be upgraded, so create a second token in the group’s Hetzner project, with the Read & Write permission (Security → API tokens → Generate API token), and paste it under Connect Read & Write. Hetscale checks that the token sees the group’s load balancer, then puts it in the project in place of its Read token, which is erased at once. The project and its node groups stay where they are, and nothing changes in your Hetzner project yet: the group still only observes.

A second node group of the same project needs no second token; its step shows as done. The project’s other groups in Observe read through the same token, and Hetscale’s write gate holds every scaling write for a node group that is not Live. When your plan’s projects are all in use, the step is refused: a node group stays in its own project, so change the plan on the billing page.

3. Delete protection

Delete protection lists the project’s servers and load balancers, with the seed, your servers behind the load balancer and the group’s load balancer checked. For what you confirm, Hetscale turns on Hetzner’s delete protection: Hetzner then refuses to delete it until someone turns its protection off in the Console. Hetscale turns protection on, never off. A server managed by Terraform needs delete_protection = true in its configuration, or the next apply turns protection off.

4. First release

Take release v1 runs a preflight, then asks Hetzner for a snapshot of the seed; new servers boot from it. The preflight checks through the Hetzner API what it can: the network zone, the seed behind the load balancer, the architecture, the server type, the health check, delete protection and the disk, and it warns when fewer than 5 of the project’s 50 placement groups are free or, under “Route to the internet”, when a seed without a public IPv4 has no route 0.0.0.0/0 in its networks (Servers without public addresses). It also shows how much of the last 7 days the seed’s server type could be ordered in the zone, and warns when that was less than 90% while the group would wait for its type: new servers and replacements then wait while the type is out, unless a fallback mode uses other types (When your Hetzner server type is sold out). When Hetzner no longer sells the seed’s type in the zone, that line warns that no new server can be of that type, the Rehearsal’s included, and names up to three types that fit: pick a fallback mode at step 6. While Hetzner has announced a date to stop selling the type, “Retirement of the type” warns with that date. “Without Kubernetes” fails, and blocks the release, when the load balancer carries the label of Kubernetes’ cloud controller manager or the seed the label of its Cluster Autoscaler. You confirm what it cannot: no state on the disk, the database elsewhere, jobs safe to copy, the application starting on boot, and the disk copied as it is, .env included. When Coolify deploys the seed, a sixth line asks you to confirm that Coolify itself runs on another server, not on the seed: a copy would boot a second Coolify (Coolify). The snapshot is taken while the seed runs and stays in your Hetzner project.

After a failed Rehearsal, or before the first one, Take release v1 again replaces release v1 with a new snapshot of the seed once you have fixed a cause on its disk: the application not starting on boot, a missing .env, a route file, the bind address or a firewall on the server. It runs the same preflight and declarations. Release v1 keeps its number and only its image changes: the server type, networks, firewalls and public addresses stay those of the first take. The earlier snapshot is no longer used; once the group is Live, Delete unused snapshots on its Deployment page removes it. No Rehearsal starts while the snapshot is being taken. Once a Rehearsal has passed, the step is closed, and a Live node group takes new releases on its Deployment page.

5. SSH keys

Optional. SSH keys, on this page and on the node group’s Deployment page, picks which of the project’s keys new servers get; without one, every scripted SSH command as root on a new server is refused. Pick them before the Rehearsal when your pipeline deploys over SSH as root. The details are in step 3 of the quickstart.

6. Stock fallback

Optional, from release v1 on. Stock fallback chooses what new servers do while the seed’s type is out of stock or no longer sold, the Rehearsal’s server included: wait for the type, try up to three types you list in order, or take the cheapest fitting type in stock under a monthly price cap (Can it use another server type?). Hetscale never picks a type for you. When Hetzner no longer sells the seed’s type in the group’s locations, the step reads “Needed”: the Rehearsal cannot get a server without a fallback mode. It is not offered while a Rehearsal runs; once the group is Live, its settings hold the choice.

7. Rehearsal

Before the first run, Readiness deadline, from release v1 on, sets how long a new server has to become ready before Hetscale deletes and reports it, the Rehearsal’s server included: 15 minutes by default, from 5 to 45. With the webhook adapter, raise it when your pipeline’s queue and deploy take longer than 15 minutes, or the Rehearsal fails. It is not offered while a Rehearsal runs; once the group is Live, Advanced in its Settings holds it, up to 60 minutes.

Start rehearsal: Hetscale creates one server from release v1, waits until the load balancer routes to it, then drains and deletes it. Hetzner bills the server’s started hours, usually one. Your own servers are not touched. A failed run names the step that failed; start it again once you have fixed it. A cause on the seed’s disk needs Take release v1 again first (step 4). A new server never becomes ready lists the usual causes and their fixes. What the Rehearsal reports is on Modes.

8. Live

Set Min, Max and a Policy, then Go Live. From the next minute Hetscale decides for the group: it adds servers from release v1 when load rises and removes the ones it added when load falls. Your own servers count toward min and max and are never removed; to retire them one at a time, see Hand your own servers over to the node group.