Autoscaling for Coolify apps on Hetzner
Coolify autoscaling needs the one thing Coolify does not do: decide how many servers to run. Hetscale adds that on Hetzner: Coolify keeps deploying as it does today, Hetscale copies the server it deploys to when load rises, and each copy takes traffic once the load balancer’s health check passes.
- Autoscaling and self-healing: a server when load rises, a replacement when one dies
- Coolify keeps building and deploying; your dashboard, logs and environment variables stay where they are
- No Kubernetes, no migration; your traffic never passes through Hetscale
- Pay for your normal load. Scale for your peak load.
- Try it read-only first: 14 days of Observe on a read-only Hetzner token, no card
What does Coolify do, and what does Hetscale add?
Coolify builds and deploys an application, to one server or to several, and keeps your environment variables and logs. It does not decide how many servers there should be, and it does not create or remove them when load changes. It has no view of load, no minimum and maximum, and no replacement of a server that fails its health check.
Hetscale adds that part. It reads the requests at your load balancer and the CPU of each server. When the group needs one more, it creates a Hetzner server from a snapshot of the server Coolify deploys to, the seed; it removes one when load falls. A server that stays unhealthy is replaced by one started beside it. Your traffic goes from your load balancer to your servers, as it does today.
- Coolify deploys.Builds and deploys your application to the seed, as it does today. Your dashboard, logs and environment variables stay in Coolify.
- Hetzner runs.Your servers and your load balancer, whose health check decides when a server takes traffic. Your account, your bill.
- Hetscale sizes.Decides how many servers the group needs, creates them from a snapshot of the seed, removes them, and replaces one that dies.
How does a new server join?
- 01Hetscale creates itweb-3 · from the seed’s snapshot
When the group needs one more server, Hetscale creates it in your Hetzner project from the current release, a snapshot of the seed Coolify deploys to, with Hetscale’s ownership labels on it. Hetscale calls no Coolify API.
- 02Coolify is left outweb-3 · Sentinel removed
Coolify runs a monitoring container, Sentinel, on every server it manages; on a copy of the seed it would report to Coolify as the seed. The new server boots with one fixed first-boot step that removes it, and Coolify never learns about the server.
- 03Load balancer decidesweb-3 · no traffic yet
The server takes traffic and counts as capacity only once the load balancer’s health check passes.
- 04Removal runs in reverseweb-3 draining
Out of the load balancer, a drain window for open connections, shut down and deleted. A server without Hetscale’s labels is never deleted.
Hetscale asks for no Coolify token and calls no Coolify API. The Hetzner token lives in one place; Coolify’s own Hetzner integration is not used. The first-boot step that removes Sentinel holds no secret and is the only thing Hetscale runs on a server. The .env files Coolify writes on the seed are inside every snapshot, which stays in your Hetzner project.
How Hetscale works, step by stepWhat do you need before you start?
The seed Coolify deploys to needs these before Hetscale copies it:
- All state is outside the servers that scale: database, sessions, uploads.
- TLS ends at the load balancer, with the Coolify proxy set to “None” or an HTTP FQDN.
- Coolify itself runs on another server, not on the seed: a copy of a server that runs Coolify would boot a second Coolify. You confirm this when you take the first release.
The new servers need no registry image, no Coolify multi-server setup and no Coolify server slot: they are copies of the seed. Where your Coolify setup stands today decides the work before it:
- Coolify on a single server, app and database togetherFit3 → 7/103 today, 7 once the prerequisite work is donePrerequisite work: move DB out, app off the Coolify host, load balancer, proxy setting
- Coolify, multi-server readyFit8/10Prerequisite work: none
What keeps you in control
- Ownership guardDeletes only servers it created or a seed you promoted: ledger, labels and name must all match.
- Health gateNo node receives traffic before your load balancer says it is healthy.
- Pinned releaseEvery new node boots the release you chose, never :latest. Shown on the group page.
- ProposeApprove each scaling action in the dashboard; unapproved proposals expire.
- RehearsalWatch one node created, checked, drained and deleted before going Live.
- Emergency stopPause a group, or stop every create and delete in it; moving to a safer mode is immediate.
- Action logEvery action carries its trigger, the metric values and the rule that fired.
- web-4draining
- web-3healthy
- web-4 · clean shutdown and deletea server it created
- web-3 · never touchednot in the ledger
Frequently asked questions
Do I lose Coolify?
No. Coolify keeps building and deploying your application to the seed, as it does today. Your dashboard, your logs and your environment variables stay where they are. The servers Hetscale adds are copies of the seed that Coolify never sees.
Does Coolify need my Hetzner API token?
No, and Hetscale needs no Coolify token. Hetscale creates the servers from the seed’s snapshot and calls no Coolify API. Coolify’s built-in Hetzner server creation is not used, because it cannot set the labels that make a server safe to delete later.
Can I keep the database in Coolify?
Yes, on a server that is not in the group. Coolify manages databases on any of its servers; the only rule is that the database server is never one of the servers that scale.
What about Docker Compose applications in Coolify?
They work if the stack keeps no state on the seed. Hetscale copies the whole server, so every new server runs the same stack: a database or a volume in it moves out first, and a worker or cron container in it runs on every copy.
Which Coolify versions are supported?
Hetscale calls no Coolify API, so there is no API version to match. The path was proven live on Coolify 4.4.3: no copy reported to Coolify, and the seed and the application stayed running in Coolify throughout.
Does a new node restart my other nodes?
No. A new node boots from the snapshot of your seed, and Coolify deploys nothing to it, so the servers Coolify runs are not touched. Your own Coolify deployments update the seed as they do today; the copies change only when you take a new release and replace them.
How do I deploy a new version?
Deploy in Coolify as you do today. When the deployment has finished, take a new release on the group’s Deployment tab, which reminds you, then replace the older servers. New servers boot from the current release, never from Coolify.
Will Hetscale register servers in Coolify?
Not today; it is planned. A pull request open upstream adds a deploy to a single server to Coolify’s API, and no Coolify release carries it yet. Once one does, a group whose application meets Coolify’s multi-server rules will have its new servers registered in Coolify and deployed by it; the others stay on copies of the seed.
Related reading
- From one Coolify server to automatic scaling on HetznerCoolify deploys to several servers but does not decide how many. What has to move off a single Coolify box before the app can scale, and how an autoscaler fits.
- Coolify on a single server, app and database togetherA single Coolify server that runs the app and its database. What has to move before the app can scale, and how Hetscale copies the app server once it has.
- Coolify, multi-server readyCoolify already deploys to several servers behind a load balancer, with state outside. Coolify keeps deploying; Hetscale adds copies of one of them.
- Cost and capacity calculatorEstimate what a fixed Hetzner fleet costs against one that follows your load. Ranged results from dated Hetzner list prices; assumptions shown.