Where Does the Work Actually Happen?
The CI/CD platform — GitHub Actions, GitLab CI, CircleCI — is a coordinator. It stores your pipeline configuration, tracks run history, and manages the queue of work. But it does not execute your shell commands directly. That work is delegated to runners (also called agents, executors, or workers depending on the platform).
A runner is a separate compute environment — a virtual machine, a container, or a physical server — with the necessary tools installed to execute the jobs you define. When a pipeline is triggered, the coordinator assigns jobs to available runners. The runner pulls the job definition, executes the steps, reports results back, and waits for the next job.
Types of Runners
1. Cloud-Hosted (Shared) Runners
Managed entirely by the CI/CD provider. You write your pipeline config and jobs run immediately on provider-managed infrastructure.
- Pros: Zero setup. No infrastructure to maintain. Scales automatically.
- Cons: Costs scale with usage and can become expensive for high-volume teams. Slower due to shared infrastructure and cold-start times. Your code and secrets run on infrastructure you do not control, which is a concern for highly sensitive builds.
2. Self-Hosted Runners
You provision and manage the machines. You install the runner agent software, register it with your CI/CD platform, and it begins accepting jobs.
- Pros: Full control over hardware (need a GPU for ML builds? Done). Cheaper at scale. Code and secrets never leave your network, which satisfies many compliance requirements.
- Cons: You own the operational burden: patching, scaling, monitoring, and recovering from failures.
3. Ephemeral Runners
A best practice for both security and correctness. Instead of a long-lived runner machine that accumulates state over time, a brand-new, clean environment (typically a fresh container or VM) is created for each job. Once the job finishes, the environment is completely destroyed.
This prevents a class of subtle bugs called runner pollution: a previous job leaves behind a file, an environment variable, or a cached credential that accidentally influences a subsequent job. With ephemeral runners, every job starts from a known-clean state. The trade-off is slightly higher startup overhead per job.
Runner Security Considerations
Runners that execute pull request pipelines from forked repositories are a known attack vector. A malicious contributor could submit a PR with a pipeline step that exfiltrates secrets from the runner environment. Most platforms mitigate this by not exposing secrets to pipelines triggered by external forks, but self-hosted runners require extra care: never run untrusted code on a self-hosted runner that has access to production credentials or internal networks.