Skip to main content
Choosing the right runner strategy is one of the most important architectural decisions for enterprise CI. The right choice delivers fast, secure, and cost-efficient pipelines; the wrong choice can lead to excessive cloud bills or self-hosted runners failing at critical times. Below is a practical comparison of the three primary compute options for GitHub Actions, with governance and security guidance for self-hosted runners.

​
Compute options: quick analogies

  • GitHub-hosted runners — like Uber: ephemeral, maintained by the provider, no OS patching or scaling concerns, but limited to public network access and the provider’s connectivity.
  • Self-hosted runners — like a company car fleet: you own, patch, and manage them; they can access private networks and internal services.
  • Azure Private Networking for GitHub-hosted runners — like a premium limo: provider-managed compute with private-network access inside your Azure Virtual Network.
A presentation slide titled "Self-Hosted Runners" showing a garage icon with two cars and three callouts: "You own them," "You maintain them," and "You patch them." Below is a firewall icon labeled "Your firewall" with an arrow, and a small KodeKloud copyright.

​
Side-by-side comparison

Useful references:

​
Azure Private Networking (managed runners with private network access)

If you need provider-managed runners but also require private connectivity to internal services, Azure Private Networking lets GitHub provision managed runners directly inside your Azure Virtual Network. This gives you the convenience of managed compute with private-network access.
A slide titled "Azure Private Networking" with a green outline car icon and captions reading "Managed for you, like Uber" and "Special road access permits." It also highlights step 3 in a sequence (GitHub-hosted runners, Self-hosted runners, Azure Private Networking).

​
Self-hosted runners: governance and access control

If you choose self-hosted runners, enforce strict access control using runner groups. Runner groups determine which repositories are allowed to use a given set of runners. By default, a newly registered self-hosted runner is placed in the organization’s Default runner group, which is visible to all repositories in the organization. That default visibility is a governance risk: any repository (and any developer with push rights) can run code on infrastructure that may have internal network access. Recommended steps to secure self-hosted runners:
  1. Change a runner group’s visibility from “All repositories” to “Selected repositories”.
  2. Explicitly check only the repositories authorized to use those runners.
  3. Create separate runner groups for different trust levels (e.g., production, staging, developer sandboxes).
  4. Enforce least privilege — only enable repositories that absolutely need access.
A settings screenshot titled "Restricting Access to Selected Repositories" showing a runner group ("self-hosted-01") with "Selected repositories" chosen and a list of repos (payments-api, web-app, mobile-ios, marketing-site, hackday-sandbox) marked with allowed or "not on the list" statuses.
Operational tip: Use naming conventions and tags for runner groups (e.g., prod-runner, dev-sandbox-runner) and document which teams or repositories are allowed. Regularly audit runner group membership and runner OS/image patch levels.

​
Critical security rule (do not ignore)

Never run workflows from public repositories on self-hosted runners. An attacker can fork a public repository, add a malicious workflow, open a pull request, and—if that PR triggers a workflow on your self-hosted runner (which may have internal network access)—achieve remote code execution inside your corporate network.
A slide titled "The Public Repository Rule" showing a five-step attack flow: an attacker forks a public repo, adds a malicious workflow, opens a pull request, it runs on a self‑hosted runner, and the code executes inside the internal network.

​
Quick operational checklist (for exams and day-to-day ops)

  • Do not run public repo workflows on self-hosted runners — unacceptable security risk.
  • If you need provider-managed runners with private connectivity, use Azure Private Networking.
  • Configure runner groups to “Selected repositories” and explicitly authorize only required repos.
  • Separate runner groups by trust level and enforce least privilege.
A slide titled "Exam Facts" that lists three points about CI runners: self-hosted runners and public repos are a security risk, Azure private networking gives runners a private IP, and runner groups must use selected repositories. The slide also shows numbered colored icons and a © Copyright KodeKloud note.

​
Additional resources

Use this guidance to choose the correct runner model for each workload, enforce strict runner-group governance, and keep external/public workflows away from any self-hosted infrastructure that has network access to sensitive systems.

Watch Video