Coolify

Hetscale autoscales an app that Coolify deploys on Hetzner without changing how you deploy: your Coolify keeps deploying to one server, the seed, and Hetscale boots new servers from a snapshot of it. Hetscale calls no Coolify API and holds no Coolify token, and Coolify never learns about the new servers, so they need no registry image, no Coolify multi-server setup and no Coolify server slot.

What does the seed need?

• A Hetzner load balancer in front of it that terminates TLS. In Coolify, give the application an http:// domain or set the proxy to None: a proxy on each copy asking for its own certificate behind a balancer fails. When Coolify’s proxy serves the app, it routes by host name, so enter your domain as the HTTP domain of the balancer’s health check.
• Coolify itself on another server, not on the seed: a copy of the seed would boot a second Coolify, with its scheduler, backups and notifications.
• The database and any other state elsewhere, on another server or a managed service, as for every seed Hetscale copies: no Coolify database or persistent storage on the seed.
• cloud-init in the seed’s operating system, as in Hetzner’s own images: a new server’s first boot runs Hetscale’s one step through it (below).

The Coolify single-server case lists what to move when Coolify, the app and the database share one server.

How do I start?

In Start observing, answer “Coolify” to “How do you deploy a new version?”. The node group then copies the seed Coolify deploys to, and Before Live adds “Coolify runs on another server” to its list. At Take release v1 on the Go Live page, the preflight asks a sixth line beside the five every seed gets: “Coolify itself runs on another server, not on the seed.” Hetzner’s API cannot show where Coolify runs, so you confirm it. The rest is the same as for any seed: Go Live.

A node group created earlier with Coolify as its adapter shows “This group still uses the Coolify adapter” on its Deployment page and starts no Rehearsal. Deploy from the seed’s snapshot moves it to this path and asks the same sixth line.

What happens to Coolify’s Sentinel?

Coolify runs a monitoring container, Sentinel (coolify-sentinel), on every server it manages, and a regular server has no switch to turn it off. On a copy of the seed it would report to Coolify as the seed, so a dead seed would look alive. Every new server Hetscale boots from a seed’s snapshot, with the snapshot or the webhook adapter, therefore runs one fixed cloud-init step on its first boot that removes that container. The step is the same for every server, carries no secret, does nothing where the container is missing, and is the only step of Hetscale’s that runs inside a server. Coolify’s proxy and your app come up on the copy through their restart policies, as on the seed.

In Hetscale’s own run on Coolify 4.4.3, the step removed Sentinel on every new server before it reported, no new server reported to Coolify, and Coolify showed the seed and the app running throughout.

How does a Coolify deployment reach every server?

Coolify deploys to the seed only. New servers boot from the group’s current release, not from Coolify, and Hetscale does not see a Coolify deployment. After each one has finished:

1. On the group’s Deployment page, which shows “Coolify deploys your seed” as a reminder, choose Take a new release.
2. Choose Replace older servers: one at a time, a server from the new release starts and, once it serves, an older one leaves through the drain window (Releases, rollouts and rolling back).

In the same run, a Coolify deployment, a new release and a replacement put the new version on every server. Until you take the release, scale-outs and healing boot the previous one. Make current on an earlier release moves new servers back; the seed keeps what Coolify last deployed to it, so roll it back in Coolify as well.

Can the seed be promoted?

No. The seed is the only server Coolify knows, and a promoted seed can be removed by scale-in, so Promote to managed is not offered for a seed Coolify deploys. It stays an adopted, protected member: scale-in never selects it and healing never replaces it.

What is inside the snapshot?

Everything on the seed’s disk, as with every seed: the .env files Coolify writes for your app are in every snapshot and on every new server, and the snapshots stay in your Hetzner project. The copies also carry the seed’s authorized_keys, Coolify’s public key among them.

What does this not cover?

• A release taken by itself after a Coolify deployment: you take it on the Deployment page.
• Coolify deploying each new server: planned. When a Coolify release can deploy an app to one server at a time, node groups whose app meets Coolify’s multi-server rules may use it, and Hetscale will register their new servers in Coolify then.
• A Coolify database or persistent storage on the seed: move them off it first.

The Coolify autoscaling page gives the overview, and the calculator estimates the cost.