World map

 

BM

World C4: Pipeline Shields

Self-hosted runner risks

You will learn: why your own runner must never serve a public repo, and how to keep it clean.

Checked with GitHub Actions 2026-10 on 31 Oct 2026

The problem

Big builds are slow on hosted runners. So you use the spare PC in your office. Your repo is public. What could go wrong?

Watch

A hosted runner is a hired worker in a rented kitchen. Both are wiped after each shift. A self-hosted runner: Your own worker in your own back room: a machine you run that picks up jobs. It is not wiped after each job. is your own worker, in your own back room. Sort the facts.

Drag a card into a box. Or tap the card, then tap the box.

      Watch

      Tap each point on the timeline.

      Tap through it. GitHub’s advice: self-hosted runners should almost never serve public repos.

      Predict

      The hidden program is still there. Next, your deploy job runs on the same PC, with your Cloudflare token. What happens?

      Try it

      Safer setup, or risky? Swipe each one.

      Swipe right for good, left for needs work. Or use the buttons.

      1 / 4

      A fresh runner for every job, removed afterwards

      Check

      This repo is public. Tap the risky line.

      Tap every risky line. Each one shows the attack and the fix.

      Workflow file .github/workflows/build.yml

      You did it!

      You can now tell when your own runner is a risk.

      Go deeper (optional)

      Need your own runners anyway? Keep them for private repos. Make them do one job, then wipe them (just-in-time runners). Use runner groups to limit which repos reach them. Keep secrets and cloud access on the machine to a minimum. Even then, other jobs there may see secrets passed on a command line.