Platform engineering

Your DevOps platform's real bill is not on the invoice

Your DevOps platform's real bill is not on the invoice

The first time I watched a finance partner cross-reference our CI/CD invoice with actual minutes burned, I felt my stomach drop for the platform team. We had negotiated the seat price down to the cent. We had not really priced the six-minute pipeline that ran a hundred and fifty times a day across three environments, or the four engineers who quietly kept the runner fleet from wandering off. GitLab put out a blog post this week that names this whole shadow bill directly, and it is worth reading with a spreadsheet open.

The framing is simple. Subscription fees and license costs, GitLab writes, "only tell one part of the story." The total cost of ownership for a DevOps platform also includes variable costs like CI/CD compute and AI usage, plus the infrastructure, tools, and employee time required to keep software delivery moving. There is nothing revolutionary in that sentence, but I have watched enough platform reviews go sideways on exactly this point to be glad someone is writing it down as a checklist.

The line items nobody prices at signup

When you buy a CI/CD platform you buy a promise about seats. What you consume, month after month, is closer to a utility bill.

Start with compute. Every hosted-runner minute has a rate card, and the rate goes up sharply once you leave the free tier or step onto a bigger machine class. If you have not looked at your own numbers lately, pull the last three months of runner minutes by workflow and sort descending. Usually one or two workflows dominate. Then look at how many of those runs were retries, PR churn, or scheduled jobs that nobody remembers scheduling. That is real money.

Then AI usage. Any platform now shipping agent features or in-editor assistants prices those on tokens or requests, and the meter runs whether the suggestion shipped or not. In my own team we saw the AI line item move from a rounding error to a real budget conversation in about a quarter, and we were not doing anything unusual with it. If you have not yet, ask your vendor for a per-user, per-day breakdown before signing a bigger tier.

Then the human line. Engineer time to build custom actions, to babysit self-hosted runners, to chase flaky tests, to onboard a new team onto the pipeline template. This is the cost that never appears on any invoice and often outweighs everything else. GitLab's post lumps this in with "the infrastructure, tools, and employee time required to keep software delivery moving," which I think is exactly right, if a little polite about how large that number can get.

A back-of-the-envelope that will not embarrass you

If your finance partner wants a defensible number, four buckets get you most of the way:

  1. Subscription and seats. Sticker price times headcount, minus whatever multi-year discount you actually secured. This is the easy row.
  2. Variable platform usage. Hosted-runner minutes, storage for artifacts and caches, network egress if your platform meters it, and AI or agent tokens. Pull last quarter, annualise it, and add a growth factor honest to your hiring plan.
  3. Adjacent infrastructure. Self-hosted runner fleet (VMs, container hosts, the load balancer in front of them), the secrets manager, the artifact registry, and whatever observability you point at CI. Some of this may already be on a cloud bill; count it anyway.
  4. People time. Platform engineers dedicated to the pipeline, plus a fraction of every other engineer's week that goes to pipeline maintenance instead of shipping. A conservative one day per engineer per month is a starting point; measure it if you can.

Add the four. That is your TCO. It will be a bigger number than the invoice, and that is the point.

Where the platforms actually differ

The comparison worth having is not "which one has the lowest seat price." It is which one moves cost from the invoice into your engineering-hours column, or the other way around. A few honest observations, based on running or watching each of these in production:

  • GitHub Actions is where most teams already are, so the marginal seat cost is often zero. The bill quietly grows through Actions minutes on hosted runners and, more recently, Copilot and agent tokens. If you host your own runners you inherit the whole babysitting workload, and it is not trivial.
  • GitLab CI/CD couples the pipeline to the SCM, the registry, the security scanners and now agent features in one subscription. That collapses several line items, which is the pitch the linked post is implicitly making. The trade-off is a heavier product surface to run, especially self-managed, and a real migration cost if you are not already there.
  • CircleCI is a strong pick when your bottleneck is orchestration on hosted infra and you want to stop thinking about runner ops. It bills on credits, which makes forecasting straightforward, and its parallelism controls can genuinely bring wall-clock time and cost down at the same time. If you are heavy on custom Docker workflows across many services, it deserves a real look before anything else on this list.
  • Buildkite flips the model: hosted control plane, your compute. If you already have a good Kubernetes or bare-metal fleet, the compute line collapses into an existing cloud bill and the platform bill stays small. If you do not, you are back to babysitting runners.
  • Jenkins has no license line, which is what makes it deceptively cheap. The people-time bucket is where the money lives, and it lives there permanently. I still like Jenkins on teams with a real platform crew and an unusual pipeline shape; I would not pick it fresh today for a small team optimising for TCO.
  • Buddy (buddy.works) is one option worth weighing when the human-time bucket is your worst one and you would rather build pipelines by dragging actions than by writing YAML. The pipeline editor collapses a lot of the setup work into visual configuration, which can lower the engineer-hours side of TCO for smaller teams. It is not the right answer if you want deep programmatic control of every step, or if your team already has a fluent YAML-first workflow that they like; CircleCI or Buildkite will fit better there.

None of these is universally cheapest. Cost lives in the shape of your team and your workload, not in the sticker price.

The rough edge

A TCO worksheet is only as honest as your telemetry. If you cannot tell me which workflow burned the most runner minutes last month, or how many AI calls your agents made and for what, you are not calculating TCO, you are guessing at it. Before you compare vendors, spend a week getting those two numbers out of your current platform. The comparison gets much shorter after that.

What I am watching next

I want to see whether platforms start publishing their AI and agent usage in the same shape as their compute usage: per user, per project, per pipeline, exportable. The compute meter got readable over the last few years, mostly because customers demanded it. The AI meter is where the compute meter was in 2019, and finance will be back with the same questions soon enough. If your vendor cannot show you a clean per-project AI breakdown yet, put it on the next QBR agenda. Mine did.

Source: GitLab (about.gitlab.com)

Related
Platform engineering

GitLab's Co-Create recap lands W3C trace context and merge-train limits in CI/CD

GitLab's half-year Co-Create program recap flags three shipped CI/CD changes: new W3C Trace Context variables in pipeline jobs, configurable merge-train pipeline limits, and a REST API for Terraform state protection rules.

September 13, 2026
Platform engineering

Preview environments were built for humans. The traffic changed.

A new essay reframes preview and staging environments as a traffic-shaped workload rather than a ticket queue, now that coding agents open pull requests in bursts. Platform teams facing agent-speed demand have to treat environment provisioning as capacity planning.

July 19, 2026
Platform engineering

Google puts Cloud Run sandboxes into preview for AI-generated code

Google Cloud has moved Cloud Run sandboxes to public preview, positioning them as a runtime for AI-generated code and untrusted binaries that a pipeline would otherwise be asked to trust with host access and cloud credentials.

July 10, 2026

Turn this into your pipeline. Build it on Buddy.

Start free