Schedule a cluster
Run a cluster only when somebody needs it. Down at night, up in the morning — and the machines stop costing while it sleeps.
Three ways to live
A cluster's ⋯ › Schedule… offers:
- Always on — the default.
- On a schedule — up and down at set times. Pick the days (Weekdays, Every day, or your own), the Up and Down times in your time zone, and dates to skip under Except. The default is Mon–Fri 08:00–20:00. Cron is there for the brave.
- For a while — the cluster is deleted for good at the end: 2 hours, 8, 24, 3 days, 7 days, up to 30 days. For the demo on Thursday that nobody will remember to clean up on Friday.
What a down keeps
A scheduled down releases the machines, so they stop billing. It keeps what you would not want to rebuild: the volumes, the certificates, the load balancers' addresses, the network, the names, the platform's own secrets. An up builds the machines again and binds everything back on the same addresses.
Workloads that came from an app deployment come back by themselves. Things you applied by hand with kubectl do not — their volumes return, their manifests do not. Deploy what you want to survive the night.
By hand
- Take down now… — one scheduled down, now.
- Bring up now… — back up early, on the same addresses.
- Keep running… — skip the downs until a moment you pick, then the schedule carries on.
- Extend lifetime… / Make permanent… — for a for a while cluster that turned out to matter.
The platform cluster cannot be scheduled: everything else leans on it.
When machines run out in the morning
An up asks Hetzner for machines like a build does, and Hetzner may be out of a type. In the schedule you can allow the up to wait for stock, to take a bigger type of the same family after a while, or to try other locations you approve. Nothing more expensive happens unless you said so.