I spent three years assuming my deployment infrastructure was someone else's problem. I'd push code to GitHub, a pipeline would spin up somewhere in the cloud, and a few minutes later my app was live. It felt magical. It wasn't until I joined a team where the DevOps costs were actually visible, listed right there in the monthly Slack report, that I realized I'd been living in a fantasy where infrastructure doesn't cost anything.
That's when someone mentioned "attaching a runner" in a standup, and I nodded like I understood. I didn't. Not really. I thought we were just... configuring something? It took seeing the bill spike during a high-merge period to make me actually learn what was happening under the hood.
The Illusion of Free Infrastructure
When I first used Jenkins years ago, I clicked buttons in a UI and code got deployed. I never thought about where those jobs were actually running. Octopus Deploy worked the same way, slick interface, zero visible infrastructure. I assumed there was some shared, communal machine handling all of this. Someone else's problem. Someone else's budget.
The reality is harder. Every CI/CD pipeline, whether it's GitHub Actions, GitLab CI, or Jenkins, needs a physical machine (or cluster of machines) sitting somewhere to actually execute your jobs. Jenkins runs on a server. GitHub Actions runs on runners. These are real machines with real compute costs. When your team is deploying constantly, those costs compound fast.
The article nails something I've experienced firsthand: most teams never talk about this until it becomes a crisis. You optimize code, you optimize queries, but infrastructure visibility? That's invisible until someone gets the bill.
Where Runners Actually Live (And What They Cost)
I've worked with runners in three different setups, and each taught me something different about the cost-to-benefit tradeoff.
Kubernetes clusters are the enterprise default. You spin up a pod to listen for jobs, it scales up when people are deploying, it (theoretically) scales to zero when idle. In practice? Many default setups don't scale to zero. I watched a team pay thousands per month because they had three listener pods running 24/7, and their actual job execution was maybe 20% of their monthly usage. The math didn't work out.
Cloud provider native offerings (AWS CodePipeline, Azure DevOps, GCP Cloud Build) handle the billing differently, you pay per job or per minute. This is cleaner for small teams, but again, if you're merging into main ten times a day, it adds up. At least the bill directly reflects your activity.
Self-hosted runners are where I've been experimenting lately. I set up a GitHub Actions runner on a Raspberry Pi in my home office, partly because I was curious, partly because I wanted to understand the mechanism. The setup took maybe five minutes: grab a token from GitHub, register the runner, let it authenticate back to GitHub's servers.
The part that surprised me most was the architecture. The runner on my Pi reaches out to GitHub and polls for jobs. GitHub doesn't reach in. That means no port forwarding, no inbound firewall rules, no exposing your infrastructure. The agent maintains a long-lived connection and checks periodically for work. It's elegant and it's free (beyond your electricity).
My Take: The Cost vs. Control Spectrum
I'm convinced that visibility into runner infrastructure should be a day-one conversation on any team, not a panicked discovery in month six. But I also think the approach depends on your context.
For startups and small teams, self-hosted runners or cloud provider native offerings make sense. You pay directly for what you use, and you don't have idle infrastructure sitting around. For enterprises with hundreds of deployments per day, Kubernetes runners with proper scaling policies can work, but only if someone's actually monitoring that scaling.
The thing I'd add to the original article: start by measuring. Add some observability to your runners. How much of your monthly runner time is actually executing jobs versus sitting idle? That one metric changed how I think about infrastructure costs entirely.
I've also learned that bringing this up early prevents resentment. When a junior developer sees a spike in cloud costs and nobody explained how CI/CD billing works, they feel blamed for deploying. That's unfair. It's an infrastructure conversation, not a deployment hygiene problem.
What I'm Curious About
I want to know: how many teams have actually calculated the real cost of their CI/CD infrastructure? Not the bill, the actual per-job, per-hour breakdown. I suspect most haven't, and that's exactly why runners catch people off guard.
Have you had a moment where CI/CD costs surprised you? What's your current setup, and how visible is it to your team?
Source: This post was inspired by "Attaching a Runner: The DevOps Term Nobody Explains Until It Costs You" by Dev.to. Read the original article
