Attaching a Runner: The DevOps Term Nobody Explains Until It Costs You

Description and use

Deploying and managing runners in CI/CD lets teams control costs and scale pipelines, avoiding hidden infrastructure expenses.

Problem

Teams often assume CI/CD tools like Octopus Deploy or Jenkins are self‑contained, but they actually rely on underlying infrastructure—‘runners’—that can become costly if not understood.

Outcome

By explicitly attaching runners and choosing appropriate hosting, teams can control costs, scale pipelines, and avoid hidden infrastructure expenses.

Workflow

• 1. Identify the CI/CD tool (Octopus Deploy, Jenkins, GitHub Actions).
• 2. Determine runner hosting option: Kubernetes/OpenShift, cloud provider, or self‑hosted machine.
• 3. For self‑hosted: navigate to repo/org Settings → Actions → Runners, click "New self‑hosted runner".
• 4. Follow setup instructions on the target machine (e.g., Raspberry Pi).
• 5. Runner registers and opens an outbound connection to GitHub, polling for jobs.
• 6. Deploy pipelines; each step runs on the attached runner without additional inbound network configuration.

Evidence

"Attaching a runner" isn't expensive for a single developer on a single project. In an enterprise, with many people deploying and merging into main constantly, it can cost a fortune.

Source

The agent process on the Pi opens an outbound, long‑lived connection to GitHub's servers and polls for jobs — it isn't GitHub "pinging" the Pi from the outside.

Source