Are third-party GitHub Actions runners secure?
Is it safe to run GitHub Actions on a third-party runner?
A third-party GitHub Actions runner is as safe as its isolation and its access: look for a fresh, single-use VM for every job so nothing survives into the next one, access limited to the repositories you select, and secrets that stay in GitHub and reach only the job that uses them. A persistent machine reused across jobs is the risky pattern, and GitHub warns against self-hosted runners on public repositories for exactly that reason. Sengi runs every job in its own fresh VM on dedicated AMD Ryzen 9 7950X3D bare metal boosting past 5 GHz, its GitHub App is installed only on the repositories you choose, and your secrets and logs stay in GitHub.
Last checked October 23, 2026, against GitHub’s secure-use guidance for Actions and its self-hosted runner documentation.
What should I ask a runner provider?
| Question | Why it matters | Sengi |
|---|---|---|
| Does every job get a fresh machine? | Files, credentials and processes left by one job can reach the next. | Yes. A fresh VM per job, destroyed afterwards. |
| Which repositories can it run? | Limits what a compromised runner could touch. | Only the ones you select when you install the GitHub App. |
| Where are secrets stored? | Secrets kept outside GitHub are another place to leak them. | In GitHub, passed to the job at run time. |
| Where do logs live? | Logs can carry tokens and internal paths. | In GitHub. |
| Does the Docker daemon start clean? | Cached images and containers can carry state between jobs. | Yes, with the VM. |
What should my workflow still do?
- Set
permissions:to the least the job needs, soGITHUB_TOKENcannot write where it does not have to. - Pin third-party actions to a full commit SHA rather than a moving tag.
- Use OIDC with
id-token: writefor cloud access instead of long-lived keys. - Protect deployments with environments and required reviewers.
These hold on every runner, GitHub’s included. Where each part of a private-repository job lives is in do third-party runners work with private repositories?, and how the providers compare is in the runner comparison.
Frequently asked questions
Do third-party runners see my secrets?
The job does, as on any runner: GitHub stores your secrets and passes the ones a job references to that job at run time. That is why isolation matters. On a fresh VM per job, nothing a job saw survives into the next one.
Are self-hosted runners safe for public repositories?
GitHub advises against it. On a persistent self-hosted runner, code from a pull request can compromise the machine, its secrets and later jobs. If you self-host, use ephemeral just-in-time runners that accept one job each.
Does Sengi keep anything between jobs?
Only what you cache. Every Sengi job runs in its own fresh virtual machine with a clean Docker daemon, destroyed when the job ends. Paths saved with actions/cache and Docker layers saved with type=gha are stored outside the VM and restored when a later job asks for them.
Does OIDC work on third-party runners?
Yes. OIDC tokens are issued by GitHub to the job, not by the runner, so cloud login without long-lived keys works the same way. On Sengi, OIDC token issuance under id-token: write has been tested.
The fastest hardware for your GitHub Actions.
AMD Ryzen 9 7950X3D desktop CPUs boosting past 5 GHz, on bare metal with local NVMe, a fresh VM for every job, and 2 vCPU jobs ready in 2 seconds. Builds finish up to 1.9× faster than on GitHub’s runners, and at up to half GitHub’s price per minute they cost up to 74% less per build. Change one runs-on line, or give your coding agent one prompt and it opens the pull request for you.