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

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

Tip

This is what lets you stand up a second hub next to a running one without fear — the new install can’t touch the old install’s runners, and vice versa.

• 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.

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.

Scale sets How labels route jobs — the other half of keeping installs cleanly separated.