How should I isolate CI runners on a dedicated server?
A CI runner executes code supplied by workflows and their dependencies. Treat that code according to its trust level and avoid sharing a production administration environment with untrusted builds. Owning the physical server does not prevent a build job from compromising the software environment it can access.
Before you start
- An inventory of permitted repositories, job trust levels and required build secrets.
Instructions
1. Separate trust boundaries
Distinguish reviewed internal releases from pull requests or other untrusted contributions. Use the CI platform’s runner groups, repository restrictions and approval controls, while recognising that approval alone does not create runtime isolation. Prefer disposable isolated job environments where the platform supports them.
2. Limit credentials and host access
Give each job only the tokens, network paths and artifacts it needs. Avoid exposing production secrets or a privileged host container socket to untrusted work. Restrict access between unrelated repositories and consider whether cached dependencies or workspaces could carry modified files into a later trusted job.
3. Validate lifecycle and maintenance
Confirm how the environment is cleaned or replaced between jobs, how credentials expire and who patches the operating system and build tools. Test artifact integrity and access boundaries. GitHub’s documentation specifically warns that self-hosted runners can persistently retain compromise from workflow code; account for that risk in the design.
Check the result
- Untrusted jobs cannot reach production credentials or unrelated repositories’ data.
- The runner lifecycle removes unauthorised state and uses reviewed, scoped credentials.
Troubleshooting
- A later job behaves differently on the same runner
- Inspect reused workspaces, caches, tools and services for state left by earlier jobs. Recreate the affected environment through the supported process rather than trusting partial cleanup after a suspected compromise.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.
