SDLC, DevOps & Developer Experience · Chapter 9 of 15
The CI/CD platform landscape
Six pricing models that cannot be compared, what each platform is genuinely best and worst at, and the arbitrage most teams miss.
Choosing a CI platform is usually done on feature lists and should be done on two things: where your code already lives, and what shape your workload is. The second one matters more than people expect, because the pricing models are structurally different rather than differently-priced.
The pricing models, and why they are not comparable
- Per minute, rounded up per job. The dominant model. The rounding is the trap: a matrix of two hundred short jobs averaging forty seconds bills two hundred minutes and uses about a hundred and thirty. That fifty percent overhead is not recoverable by tuning — the fix is to batch small jobs together.
- Cost factors. Duration multiplied by a per-runner-size factor. Sound in principle and opaque in practice: an engineer cannot predict a bill by reading a pipeline file, which means nobody manages the cost.
- Credits. Same objection, one more layer of indirection — and on at least one platform the Docker layer caching that makes builds fast is itself metered per job run, so the optimisation has a line item.
- Per parallel job, with unlimited minutes. This is the one worth knowing about, because it is structurally different: you buy concurrency rather than consumption. For any team that keeps a runner busy, it is dramatically cheaper — twenty thousand minutes a month costs one or two parallel jobs rather than a per-minute bill several times larger.
- Per vCPU-minute, which is at least honest about what you are buying.
- Control plane only — you pay for orchestration and run the compute yourself. This inverts the economics at scale and is why it appears at companies with large or specialised build fleets.
The arbitrage: ARM runners
On the largest hosted platform, ARM64 runners are roughly 40% cheaper per core-minute than x64 at the larger sizes, and about half the price on Windows.
For anything that cross-compiles cleanly — which is most modern language toolchains — that is a one-line change in a workflow file for a large fraction off the bill. It is the single biggest lever available on hosted CI cost and a surprising number of teams have not taken it.
The rollout is worth checking: ARM runners reached general availability for public repositories in 2025 and private repositories in early 2026, so material written before that will tell you they are unavailable.
What each platform is actually for
| Platform | Best at | Worst at |
|---|---|---|
| GitHub Actions | Anything already on GitHub. The action marketplace, OIDC federation to clouds, and built-in artifact attestations | Cost control at scale, and debugging — there is still no first-class local runner |
| GitLab CI | Being one product — source, CI, registry, scanning and packages under one licence. Strongest self-managed story | Cost predictability. And its top tier moved off published pricing, so budgeting is now a negotiation |
| Jenkins | Plugin coverage for legacy and physical infrastructure nothing else touches. Total control | The plugin ecosystem is also the liability, and the controller is a stateful single point of failure |
| CircleCI | Docker-native execution, genuinely good caching primitives, test splitting that works | The credit abstraction obscures cost further than most |
| Buildkite | Dynamic pipelines — a step emits the next steps at runtime, which is more expressive than a static graph — and owning your own compute | You operate the agents, so there is real operational cost |
| Argo Workflows | Long-running, fan-out-heavy batch and machine-learning work where a step is a container and you need thousands | Being CI. Pod-per-step startup is fine for a twenty-minute job and terrible for a three-second lint |
| Tekton | Being the substrate other CI products are built on — custom resources all the way down, composing with cluster policy | Raw Tekton is not a product. There is no usable interface without a layer on top |
| Azure DevOps | The concurrency pricing model, which is the best value in hosted CI for steady workloads | Being in maintenance-flavoured stewardship while investment goes elsewhere |
| Dagger | Killing the push-to-debug loop — pipelines as typed code that run identically locally and in CI | It adds a layer rather than removing one; you still need a trigger platform |
Jenkins has not collapsed, and the data says so.
Survey data reported in 2026 puts organisational use at roughly a third for the largest hosted platform, 28% for Jenkins, and 19% for the integrated alternative — with around a third of organisations running two CI tools and one in ten running three or more.
The genuinely surprising figure in the same data: about one organisation in five uses no CI/CD tool at all, and only around 55% of developers use one regularly.
Why this matters for a candidate: a great deal of writing assumes Jenkins is legacy and everyone is on modern hosted CI. A large share of real jobs involve Jenkins, a mixed estate, or a team that has not automated at all. Treating Jenkins knowledge as obsolete is a mistake, and being able to say ‘a third of organisations run two systems’ is more useful than a preference.
How to choose
Three questions, in order:
- Where does the code live? The integration tax of running CI on a different platform from your source is real and permanent, and it usually outweighs feature differences. This decides it in most cases.
- Is your load steady or bursty? Steady load favours concurrency-based or self-hosted models decisively; bursty load favours consumption pricing. Model your own workload against each shape rather than comparing rates.
- Do you have a constraint nothing hosted satisfies? Physical hardware, an air-gapped environment, an unusual architecture, a specialised device farm. That points at self-hosted runners regardless of platform — and note that most platforms support self-hosted runners, so this is not necessarily a platform choice at all.
Check yourself