For GitHub self-hosted runners, the platform updates only the runner application. You are responsible for the operating system and every other tool on the machine. GitHub-hosted runners are the opposite: GitHub handles maintenance and upgrades. Your patch workload depends on which one you pick.
What the documentation says
GitHub's documentation on self-hosted runners says they receive automatic updates for the runner application only, and that you may disable those automatic updates. It adds that you are responsible for updating the operating system and other software. It also says self-hosted runners do not need a clean instance for every job.
For hosted runners, the docs say machine maintenance and upgrades are taken care of for you. Each hosted runner is a new virtual machine, and the software tools in GitHub-owned images are updated weekly, a process that takes several days.
Side by side
| Aspect | GitHub-hosted | Self-hosted, long-lived | Self-hosted, just-in-time |
|---|---|---|---|
| Runner app updates | Platform | Platform, unless you disable | Platform |
| OS and tool patches | Platform | You | You, through the image |
| Clean state per job | New VM | Not guaranteed | At most one job |
| Persistent compromise risk | Low | Higher | Lower |
Why long-lived runners age badly
A long-lived runner collects state. Old toolchains, cached credentials, leftover files and stale packages pile up. Because nobody logs into it, it is easy to ignore until something fails.
The GitHub security guide goes further: self-hosted runners can be persistently compromised by untrusted code in a workflow, and should almost never be used for public repositories. Organization or enterprise runners are riskier because one compromise can reach several repositories.
Just-in-time runners help, with limits
The security guide says just-in-time runners perform at most one job before being removed. That turns patching into an image problem: rebuild the base image on a schedule and every new runner starts patched. The guide also cautions that reusing hardware can expose information from the environment, and that you cannot guarantee a runner only runs one job in every setup.
A patch plan for runners
- Decide per repository: hosted, or self-hosted with a reason.
- For self-hosted, build the image from a pinned base and rebuild weekly.
- Keep automatic runner application updates on unless you have a tested alternative.
- Restrict which repositories can use each runner group, and use private repositories only, as GitHub recommends.
- Record OS version and tool versions per runner and review monthly.
For a threat view of this setup see a self-hosted runner executes strangers code.
Safeguard's policies and gates apply on the pull request, and its dependency scanning covers the code those runners build. A free scan is at gold.safeguard.sh/scan.
Common mistakes
Teams often assume the platform patches everything, leave a runner running for years and share one runner group across many repositories. Write down which class each runner belongs to and who owns its image.
Quick check
Does GitHub patch the OS on my self-hosted runner?
No. The documentation says you are responsible for the operating system and other software. Only the runner application updates automatically.
Are just-in-time runners a full fix?
No. They limit a runner to at most one job, but GitHub cautions that reusing hardware can expose information from the environment.
Sources
- About self-hosted runners
- About GitHub-hosted runners
- Secure use reference
- Managing access to self-hosted runners
Last reviewed: 19 October 2026.
