DevOps
CI Self-Hosted Runner Cleanup: Retire Build Machines After Workloads Move
Self-hosted CI runners tend to accumulate because each one was created for a reason: private network access, large builds, mobile signing, GPU tests, legacy operating systems, or release credentials. After workflows move to managed runners or newer pools, the old machines may keep checking in, consuming patches, secrets, disks, and attention.
Cleanup should retire build capacity only after the workloads and credentials have moved. An idle runner can still be the only place a quarterly release job works.
Build an evidence table
Inventory runners by label, operating system, repository access, last job, installed toolchain, network reachability, and credentials.
| Runner signal | Evidence to inspect | Cleanup risk |
|---|---|---|
| No recent jobs | Workflow schedules and release cadence | Rare release builds may not run weekly |
| Unique labels | Workflow files and branch filters | Deleting labels can strand jobs in queues |
| Installed signing tools | Mobile, desktop, or package release steps | Credentials may exist only on this runner |
| Private network access | Deploy, integration test, and artifact upload paths | Managed runners may not reach the same systems |
| Local caches | Build time and dependency mirrors | Cleanup may slow critical builds |
Export job history from your CI system and compare it with workflow definitions. The key review is whether any workflow can still target the runner through labels, groups, or repository permissions.
Do not rush these runners
Slow down when the runner holds signing certificates, deploy credentials, hardware devices, private network routes, or licensed build tools. Also slow down when the runner supports hotfix branches; the main branch may have moved while supported release branches still point at old labels.
Retire in stages
First, move workflows to the replacement pool and run representative builds there. Second, remove labels or repository assignments before destroying the machine, so queued jobs fail visibly in a controlled window rather than disappearing with the host. Third, rotate or remove secrets that lived on the runner. Fourth, archive any special toolchain notes needed for future incident recovery.
If the runner is kept, make that decision explicit. “Keep until macOS signing migration completes” is operationally different from “unknown old machine still connected to CI.”
Prevent runner sprawl
New self-hosted runners should require an owner, label contract, repositories allowed to use the runner, credential inventory, and expiry condition. For temporary migration runners, include the cleanup task in the same issue as the migration. For permanent runners, route patching and secret rotation alerts to the owner who can actually retire or maintain them.
Key takeaways
- Self-hosted runner cleanup touches builds, credentials, network access, and release support.
- Last job time is useful but incomplete for scheduled and branch-specific workflows.
- Remove routing labels and repository assignments before destroying hosts.
- New runners should ship with ownership, label scope, and an expiry condition.