From scale-up to wiped disk
BYOC runner lifecycle
What happens between a job being queued and the runner instance being destroyed, and where you can intervene.
Runners are ephemeral: one job, one instance, destroyed afterwards. The lifecycle matters mostly when something goes wrong in the middle of it.
- A job is queued and matched to a runner group by label
- If warm capacity exists the job starts immediately; otherwise the ASG scales up
- The instance boots, registers with GitHub using a short-lived registration token, and claims the job
- The job runs; logs stream to GitHub and metrics to the control plane
- On completion the runner deregisters, the disk is wiped and the instance is terminated
Scale-down safety
Scale-in is drain-based: an instance running a job is protected from termination until the job finishes. This is why a scale-down after a burst is not instant, and why it should not be.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.