Per-install identity
Every Runaway install gives itself an immutable identity on first boot — a short
unique id that it stamps onto everything it owns. That id rides in two places:
embedded in every runner’s name, and applied as an install= label on every
runner container.
Why it exists
Section titled “Why it exists”Without it, two Runaway installs that share a GitHub org, or two agents sharing one Docker host, can’t tell their own runners from the other’s. The cleanup routines — deregistering offline GitHub runners, force-removing stray containers — would then operate on a peer’s runners by mistake. With a per-install id, each install scopes those routines to its own resources.
The rule is simple and conservative: if an install can’t prove it owns a runner, it leaves that runner alone. Anything not carrying this install’s id is never deregistered and never force-removed.
What it makes safe
Section titled “What it makes safe”- Trialing an upgrade beside production. Run a new install alongside the old one against the same org. Each only manages its own runners.
- Migrating to new hardware. Bring up the hub on a new box while the old one is still draining. Neither stomps the other; the old install’s ephemeral runners finish their jobs and disappear on their own. To carry your configuration and identity across, export a backup and restore it with Move — see Backups and recovery.
Lifecycle, not job execution
Section titled “Lifecycle, not job execution”This identity isolates lifecycle — which install is allowed to clean up which
runners. It is separate from job execution isolation, which decides which
runner picks up which job. Job routing is handled entirely by runner
labels matched against runs-on. The install id
keeps two installs from interfering with each other’s housekeeping; labels keep
their jobs from landing on the wrong runners.