A pipeline runner is an execution component preconfigured with the packages pipeline jobs need. Maintain runners alongside reusable pipeline code, but keep their responsibilities distinct: the runner supplies the execution environment; repository-owned pipeline code defines and references shared jobs and steps. section 6.3.7 section 6.2.2
Installing reusable logic on a runner is not a substitute for referencing a versioned pipeline library in the repository. Server- or runner-installed plugins make pipelines brittle and harder to maintain. section 6.2.2
Choose where runners execute according to the workload and network requirements:
- Use a private executor on cloud resources when a SaaS pipeline must reach services kept on internal networks. Unlike a hosted executor, this is self-managed. section 6.3.8
- Watch capacity: idle executors waste resources, while too few leave pipelines waiting. section 6.3.8
- Keep pipeline logic in versioned shared libraries rather than expanding runner configuration to carry it. section 6.2.2 section 6.5
Try a private runner locally
Start a local Kubernetes cluster, then use CircleCI’s container-agent to create a private runner resource. Configure CircleCI projects to use it; the agent watches those projects and runs their pipelines in containers started in the cluster. The experiment requires CircleCI CLI, Kind, kubectl, and Helm. section 6.3.8
$ brew install kind kubectl helm circleci
Shows the macOS Homebrew command for installing the tools required by the local runner experiment. section 6.3.8
