Self-Hosted Runners: Bring Your Own CI/CD Hardware
A self-hosted runner is your own machine executing CI/CD jobs, giving you full control over its environment and network. Use it for private network access or custom hardware. The footgun: you are now responsible for all security, updates, and maintenance.
WHY IT EXISTS Cloud CI/CD providers offer managed runners for convenience, but these generic environments can't access your private resources, like a database behind a firewall. They also offer limited hardware and software customization. Self-hosting solves this by letting your CI/CD jobs run on your own infrastructure, under your control.
THE MENTAL MODEL Think of a self-hosted runner as an employee you've given a company laptop and a VPN key. Instead of a random contractor (a cloud-hosted runner) working from a public space, you have a trusted agent inside your secure office (your private network). This agent can access internal files and use specialized tools you've installed on their machine.
HOW IT WORKS You install an agent application on a machine you control, such as a server in your data center or a VM in your cloud account. This agent continuously polls your CI/CD service (like GitHub Actions) for pending jobs. When it finds a job assigned to it, often via labels like 'gpu-runner' or 'windows-build', it pulls the job's instructions, executes them locally, and streams logs and artifacts back to the CI/CD service.
WHEN TO USE IT Use self-hosted runners when your job needs to: first, access resources in a private network (like a staging database); second, run on a specific operating system or architecture not offered by the cloud provider; third, use custom hardware like GPUs or powerful CPUs; or fourth, bypass cloud-runner concurrency limits.
WHEN NOT TO USE IT Avoid self-hosted runners for public open-source projects where you might run untrusted code, as this poses a major security risk to your infrastructure. They are also overkill for simple jobs that work on standard cloud runners, as the maintenance overhead (security patching, OS updates, agent updates) often outweighs the benefits.
ONE CANONICAL EXAMPLE A data science team needs to train a model using a specific GPU. They set up a self-hosted runner on a cloud VM with the required GPU and label it 'gpu-training'. In their CI/CD workflow, the training job specifies runs-on: self-hosted, gpu-training. The runner picks up the job, runs the GPU-intensive training script, and uploads the resulting model as a workflow artifact.
Read the original → docs.github.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.