Almost never. GitHub's guidance says self-hosted runners should almost never be used for public repositories, because any user can open a pull request and compromise the environment. Use GitHub-hosted runners for untrusted pull requests, which start from a clean, ephemeral virtual machine.
Why the runner type matters
When a workflow runs a contributor's build script, that script runs on the machine. On a GitHub-hosted runner, the virtual machine is ephemeral and isolated, so there is nothing persistent to compromise. GitHub states that self-hosted runners do not have those guarantees and can be persistently compromised by untrusted code in a workflow.
A compromised runner is worse than a failed build. It may sit inside your network, hold cloud credentials, cache files for later jobs, and run jobs for other repositories.
What about private repositories?
GitHub says to be cautious there too. Anyone who can fork the repository and open a pull request, generally those with read access, can compromise the self-hosted runner environment, including gaining access to secrets and the GITHUB_TOKEN.
Environments do not fix this. GitHub notes that workflows on self-hosted runners are not run in an isolated container even when they use environments, and environment secrets should be treated with the same level of care as repository and organization secrets.
Options when you need your own hardware
| Need | Safer approach |
|---|---|
| Special hardware such as GPUs | Dedicated runners for trusted branches |
| Access to internal systems | Run untrusted checks on hosted runners, trusted deploys on your own |
| Large builds | Larger hosted runners or sharded jobs |
| Reproducibility | Ephemeral runners created per job and destroyed after |
A policy you can adopt
- Pull request checks from forks run on hosted runners.
- Self-hosted runners are assigned to specific repositories, not shared across the organization.
- Self-hosted runners are ephemeral and have no standing credentials. Use short-lived tokens issued per job.
- Network egress from runners is restricted to what builds need.
- Workflow files that choose the runner are covered by code owner review.
- Review runner groups on a schedule and remove idle ones.
The fifth point matters because a contributor who can edit a workflow can change the runs-on label. Fork pull request workflows that need approval give you a chance to see that change before anything runs.
Signs you have a problem
- Runners that have been up for weeks.
- Cloud credentials stored on disk of the runner.
- A runner group open to every repository in the organization.
- Pull request workflows labeled with a self-hosted label on a public repository.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how continuous monitoring surfaces change after the initial scan, which is the habit that catches a stale runner setup.
Where Safeguard fits
Safeguard offers asset discovery and policy controls that help you see what exists in your estate. You can start with a free scan of your code.
Quick check
Are ephemeral self-hosted runners acceptable for public repositories?
They reduce persistence risk, but GitHub still advises caution. Prefer hosted runners for untrusted pull requests.
Does an environment protect a self-hosted runner?
No. Jobs on self-hosted runners are not isolated in a container even when they use environments.
Sources
Last reviewed: 19 October 2026.
