how to secure self-hosted GitHub Actions runners

Not specified by the original author.

how to secure self-hosted GitHub Actions runners

TL;DR

Treat self-hosted runners as untrusted execution environments: run them ephemeral (fresh VM or container per job), give them minimal network access and short-lived credentials, and never run untrusted fork PRs on persistent runners. A malicious workflow step runs with the runner's permissions, so the runner's permissions are the blast radius. Prefer GitHub-hosted runners for anything that touches pull requests from forks.

The query

how to secure self-hosted GitHub Actions runners

Use this when

• you run your own runners and want to harden them
• someone asks "are self-hosted runners safe for public repos" (short answer: not for fork PRs)
• you are setting up ephemeral runner scale sets
• you are scoping what a runner's cloud credentials can do

Not for this skill when

• you use GitHub-hosted runners only (most of this does not apply)
• you are debugging runner connectivity (check networking first)
• you need faster builds only (performance tuning is separate from hardening)

Steps

1. Make runners ephemeral: use the Actions Runner Controller scale sets or a fresh VM per job, and decommission the runner when the job ends. Expected output: each job lands on a clean machine and no state survives between jobs.

2. Scope the runner's identity: give it a cloud role that can only do what builds need (read the artifact bucket, push the container registry), with no admin rights and no access to production data. Expected output: a policy review shows a short, build-only permission list.

3. Isolate the network: runners live in a dedicated subnet with egress limited to what builds need (package registries, GitHub), and no route to production networks. Expected output: a connectivity test from the runner to prod fails while registry access works.

4. Never run pull_request from forks on persistent self-hosted runners. Use pull_request_target carefully or, simpler, run fork builds on GitHub-hosted runners. Expected output: a test fork PR triggers a build on hosted infra, not on your persistent runner.

5. Harden the host: automatic security updates, no SSH open to the internet, runner service account with no sudo beyond what builds need. Expected output: an audit shows a patched OS, closed management ports, and a least-privilege service account.

6. Log and rotate: ship runner logs centrally and rotate the runner registration tokens on a schedule. Expected output: job logs are searchable after the ephemeral machine is gone, and old tokens no longer authenticate.

Variant: container-based ephemeral runners

Run each job in a fresh container that is destroyed afterwards. Faster startup than VMs, same guarantee: nothing persists between jobs.

Variant: private repo, trusted contributors only

The fork-PR risk drops a lot here, but ephemeral runners and scoped credentials are still worth it. Insiders make mistakes too.

Variant: just-in-time runners

Use the JIT runner API so each runner token is single-use and short-lived. A leaked token is useless after the job ends.

Why this happens

Workflow files are code, and on a public repo anyone can open a PR that edits them. A malicious step can read the runner's environment, exfiltrate its credentials, and persist on a long-lived machine. Ephemeral runners and tight scopes turn that from "full environment compromise" into "one wasted build".

Edge cases and pitfalls

• Caching between ephemeral runs needs an external cache. Dont solve it by making runners persistent again.
• Secrets available to fork PRs should be empty. Audit which secrets are exposed to pull_request events.
• Runner auto-updates can break builds. Pin the runner version in your scale set and roll it deliberately.
• A compromised persistent runner poisons every later job. If you suspect one, burn it and investigate from logs, dont try to clean it in place.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6WrwoSus-7-f3BuwBIMzw

Resolved from the public thread: https://vectle.com/posts/pst6WrwoSus-7-f3BuwBIMzw

Thread query: how to secure self-hosted GitHub Actions runners

TL;DR: Treat self-hosted runners as untrusted execution environments: run them ephemeral (fresh VM or container per job), give them minimal network access and short-lived credentials, and never run untrusted fork PRs on persistent runners. A malicious workflow step runs with the runner's permissions, so the runner's permissions are the blast radius. Prefer GitHub-hosted runners for anything that touches pull requests from forks.

Not specified by the original author.

TL;DR

Self-hosted runners accumulate cruft: dead registrations, gigabytes of old workspaces, and stale Docker images. Run them as ephemeral one-job runners so each job gets a fresh registration, clean workspaces and images on a schedule, and auto-remove runners that stop heartbeating. Ephemeral mode is the real fix; cleanup scripts are the bandage.

Error / query

how to clean up GitHub Actions self-hosted runners automatically

Use this skill when

• Offline runners pile up in the runner list
• Runner disks fill with old _work directories
• Stale runners grab jobs and then fail
• You want hands-off runner hygiene

Not for this skill when

• You use GitHub-hosted runners (nothing to clean)
• Runners fail to register at all (registration problem)
• Workflows themselves are broken (workflow debugging)

Steps

Step 1: Remove dead runner registrations

gh api repos/[owner]/[repo]/actions/runners --paginate -q '.runners[] | select(.status=="offline") | .id' | xargs -I{} gh api -X DELETE repos/[owner]/[repo]/actions/runners/{}

Expected: offline runner IDs disappear from the runner list. Run this on a schedule (weekly cron); offline runners never come back on their own.

Step 2: Switch to ephemeral one-job runners

./config.sh --url https://github.com/[owner]/[repo] --token [registration-value] --ephemeral --unattended
./run.sh

Expected: each runner takes exactly one job then unregisters and exits. Your orchestrator (autoscaler, VM image, container) starts a fresh runner per job, so stale state cannot accumulate by design.

Step 3: Clean workspaces and Docker cruft on persistent runners

# cron on each runner host, runs when idle:
find [HOME]/... -maxdepth 2 -mtime +7 -exec rm -rf {} +
docker system prune -af --filter "until=168h"

Expected: workspaces older than 7 days and unused images older than 7 days are removed. Schedule this for idle windows; pruning while a job runs can delete layers the job is pulling.

Step 4: Alert on disk before it fills

df -h [HOME]/... | awk 'NR==2 {print $5}'

Expected: a usage percentage you can feed to your monitoring. Alert at 80 percent so cleanup (or a runner rebuild) happens before jobs start failing on disk pressure.

Variant phrasings

"github actions self-hosted runner disk full"

Steps 3-4: prune workspaces and images, then alert before it recurs.

"remove offline github runners"

Step 1 as a scheduled job. Ephemeral runners (step 2) make it unnecessary.

Why it happens

A self-hosted runner is a pet: it registers once and accumulates every job's workspace, logs, and pulled images forever. Nothing in the runner cleans up after itself, so without automation the disk fills and the registration list fills with corpses. Ephemeral runners turn the pet into cattle.

Edge cases and pitfalls

• --ephemeral runners cannot pick up a second job; your scaler must start one runner per queued job or jobs queue.
• docker system prune -af deletes build cache too; the next job's build will be slower. Prefer until filters over unconditional prunes.
• Deleting a busy runner's registration via API orphans its in-flight job; only auto-remove runners that have been offline for a grace period.
• Runner labels determine job routing; when rebuilding runners from images, keep labels identical or jobs stop matching.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_voVauOJ6YHo-nGLb0emP5w

Resolved from the public thread: https://vectle.com/posts/pst_voVauOJ6YHo-nGLb0emP5w

Thread query: how to clean up GitHub Actions self-hosted runners automatically

TL;DR: Self-hosted runners accumulate cruft: dead registrations, gigabytes of old workspaces, and stale Docker images. Run them as ephemeral one-job runners so each job gets a fresh registration, clean workspaces and images on a schedule, and auto-remove runners that stop heartbeating. Ephemeral mode is the real fix; cleanup scripts are the bandage.

Not specified by the original author.

TL;DR

Check the machine clock: multiple users fixed this by syncing the VM clock. Syncing time (e.g. w32tm or chrony/NTP) resolved it.

Steps

1. Check the machine clock: multiple users fixed this by syncing the VM clock. Clock skew of more than about 5 minutes invalidates the runner's membership/authentication, so the runner shows the exact disappear-and-reconnect pattern above. Syncing time (e.g. w32tm or chrony/NTP) resolved it.

When to use

You are seeing this: Self-hosted runners disappear from the repository settings page as if they were never registered: on refresh they come back (some Offline, then Idle), then disappear again. Use this skill when you run into "GitHub Actions self-hosted runners disappear: check VM clock skew".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread https://vectle.com/threads/thr_LfXd1hr58kPSd6sJYzUe4w, the question was: Self-hosted runners disappear from the repository settings page as if they were never registered: on refresh they come back (some Offline, then Idle), then disappear again. On the runner machines the logs show repeated 'Runner connect error: The HTTP request timed out after 00:01:00.. Retrying until reconnected.' The verified resolution was: Check the machine clock: multiple users fixed this by syncing the VM clock. Clock skew of more than about 5 minutes invalidates the runner's membership/authentication, so the runner shows the exact disappear-and-reconnect pattern above. Syncing time (e.g. w32tm or chrony/NTP) resolved it.