Quickstart

Hetscale’s own setup takes about 15 minutes in every case. What comes before it depends on where you start; the onboarding cases list the prerequisite work and the time for each starting point.

What you need

• A Hetzner Cloud project.
• A load balancer with a health check on your application’s health endpoint, either a Hetzner Cloud Load Balancer or Cloudflare Load Balancing, with TLS terminated at it and DNS pointed at it.
• At least one server behind the load balancer, running a stateless workload: the database, sessions and uploads live outside the servers that will scale.
• A way to bring a fresh server up: a snapshot of an existing server, cloud-init, a webhook to your CI, or Coolify.

Without a load balancer, onboarding gives you a “get LB-ready” checklist first. Hetscale does not create the load balancer for you.

1. Connect read-only

Create a Hetzner API token with Read permission for the project and start the 14-day Observe trial. Hetzner tokens have exactly two levels, Read and Read & Write; a Read token cannot create, change or delete anything, and that is enforced by Hetzner, not by Hetscale.

Onboarding asks four questions before any resource is read: is there a load balancer, is the app behind Cloudflare, where is the database, how do you deploy. The answers map to a case with a fit score and a time estimate.

2. Read the day-0 report

Minutes after connecting, Hetscale reads the last 30 days of metrics for the servers behind your load balancer and writes the report: how many times more capacity was needed than was available, an estimated node range with a confidence label, the extra cost as a range, the signals it used and the ones it cannot see, days with CPU pinned at 100%, and a recommended policy labelled “default”. For 14 days it then records every decision it would have taken live, prefixed “would”.

3. Choose the adapter and run one Rehearsal

The adapter is how a new node gets your application:

• Snapshot: Hetscale takes a snapshot of the server you point it at (the seed) and records it as release v1. New nodes boot from it; your restart policies bring the containers up. The snapshot contains everything on the seed’s disk, including .env files, and stays in your project.
• Webhook: Hetscale sends a signed node.created event with the node’s IPs; your pipeline deploys to it and may report ready or failed. The load balancer health check remains the final signal.
• Coolify: Hetscale creates the server with Coolify’s SSH key, registers and validates it in Coolify, and triggers the deploy.

Going past Observe needs a second, Read & Write token. Then run one Rehearsal: Hetscale creates one node from the template, deploys through the adapter, waits for the load balancer health check, drains it and deletes it while you watch the timeline. Success unlocks Live; failure produces a report with the failing step and never leaves a node behind.

4. Go Live with a floor of two

Set the range. A minimum of 2 gives zero-downtime healing: when one node fails, the other keeps serving while the replacement comes up. The maximum is what the report suggests. Every mode can be changed at any time; moving to a safer mode takes effect immediately.

The seed server stays an adopted, protected member: scale-in never selects it and healing never replaces it. You can promote it to a managed member later, explicitly, with a confirmation that states the consequences.