If you are the platform lead or engineering manager who picked the CI/CD platform, you are the one who will stand in front of the CFO when the compute bill triples and explain why. CFOs do not buy “faster pipelines.” They buy a number they can predict and a payback they can defend. So here is the 60-second version.
The per-minute rate on the pricing page is the smallest cost in a CI/CD platform deal. The real bill is compute minutes that scale with every commit, the engineering time to run self-hosted runners, and the developer hours your team burns waiting on slow builds.
Pick the CI/CD platform on three-year all-in cost and developer wait time, not on the headline minute price.
The buying problem before the buying
Most teams choose a CI/CD platform by counting features and comparing per-minute rates. That is exactly the wrong frame, because the largest cost never shows up on the invoice. It shows up as developer idle time.
A 20-minute pre-merge pipeline across 100 engineers, each pushing three commits a day at a loaded rate of $75 an hour, burns roughly $7,500 of wait cost every working day . That is more than $1.5M a year in pure waiting, and it never appears in the CI/CD platform line item.
Your CFO is looking at a few thousand dollars of compute. The actual cost is sitting in your engineers’ calendars.
The usage motion is what makes CI/CD platforms uniquely dangerous to budget. You are not buying seats that stay flat. You are buying compute minutes that scale with commit volume, test suite size, and team headcount, all at once. Ship more code, the bill goes up. Hire more engineers, the bill goes up. Add integration tests, the bill goes up.
A 50-developer team commonly spends $3,000 to $8,000 a month on CI/CD compute alone , and that figure climbs every quarter without anyone signing a new contract.
The failure to define before you buy is this: how much will a CI/CD platform cost when our build volume doubles, and how much developer time are we paying to wait on it today. Get those two numbers first. Everything else is detail.
The weighted scorecard, what CI/CD platforms actually get scored on
Score every CI/CD platform on the same twelve criteria, weighted, with real evidence demanded for each. Do not let a vendor demo dictate the categories. The weights below reflect what actually decides whether a CI/CD platform survives a year in production and a budget review.
| Criterion | Weight | What to score, and the evidence to demand |
|---|---|---|
| Three-year total cost of ownership | 14 | Full TCO: included minutes, overage rate by OS, self-hosted runner labor, storage, and platform fees. Demand a written quote modeled at 2x your current build volume. |
| Build and pipeline speed | 13 | Median wall-clock time for your real pipeline, not a hello-world demo. Demand a timed run of your actual largest pipeline during the trial. |
| Compute and minute economics | 12 | What a minute costs by OS and runner size, included minutes, and the overage rate. Demand the exact per-minute rate for Linux, Windows, and macOS in writing. |
| Pipeline reliability and flaky-test handling | 11 | Native retry, test-result analytics, flaky-test detection. Demand a demo of automatic rerun and flaky-test quarantine on a real failing test. |
| Caching and parallelism | 10 | Dependency caching, Docker layer caching cost, test splitting, concurrency limits. Demand a cached vs uncached build time on your repo. |
| Security and supply-chain controls | 9 | OIDC keyless auth, secrets handling, SLSA provenance, audit logs. Demand proof of OIDC support and no long-lived stored secrets. |
| Self-hosted runner support | 8 | Ability to run on your own infra, the per-minute platform fee that still applies, and the ops burden. Demand the platform fee for self-hosted in writing. |
| Native integrations and ecosystem | 7 | Depth into your VCS, cloud, registry, and deploy targets. Demand a live connection to your real GitHub or GitLab org and cloud account. |
| Concurrency and queue behavior at peak | 6 | Concurrent job limits on your tier and queue wait at peak. Demand the concurrency cap on the plan you are quoting and a peak-time test. |
| Vendor stability and pricing history | 4 | Funding, ownership changes, and the last three pricing or free-tier changes. Demand the pricing changelog and any recent free-tier cuts. |
| Migration and lock-in cost | 3 | Pipeline config portability and the realistic cost to move off later. Demand an honest estimate of how many pipelines would need a rewrite. |
| Observability and build analytics | 3 | Per-step timing, cost attribution by team, and trend dashboards. Demand a real cost-by-pipeline breakdown view in the trial. |
Get the CI/CD Platforms Evaluation Toolkit
The weighted vendor scorecard (Excel, auto-scores your shortlist and ranks the winner) plus the 1-page checklist of questions to ask every vendor and the red flags to walk away from. Free.
The true multi-year cost of a CI/CD platform
The pricing page shows you a per-minute rate. What you actually sign up for is a compute bill that grows with your team, plus the engineering labor to keep runners alive, plus the developer hours lost to waiting. Model all three or you will be the one explaining the variance.
Start with the headline rates, because they are deceptively clean. GitHub Actions Linux runs about $0.008 per compute minute plus a $0.002 platform fee , so $0.010 all-in. GitLab CI sits around $0.008 to $0.010 a minute.
CircleCI’s medium Linux is roughly $0.06 a minute, six times GitHub’s rate, before you add Docker layer caching at 200 credits per job . macOS runners are the brutal line: GitHub charges around $0.08 a minute and CircleCI macOS is roughly $0.30 a minute.
If you build iOS apps, that one number can dominate the entire CI/CD platform bill.
Now the trap. The same 50-developer workload comes out to about $845 a month on GitHub Actions Team, $2,004 on GitLab Premium, and $3,711 on CircleCI Performance for identical builds.
Self-hosting looks like the escape hatch, but GitHub now applies its $0.002 per-minute platform fee to self-hosted runners too, effective March 2026 , which adds $200 a month at 100,000 minutes on top of the cloud VMs you already pay for.
Self-hosted runners only pay back consistently above roughly 50,000 build minutes a month, and only if you have the engineering time to babysit them.
The lines that bite are the ones nobody quotes you. Runner ops labor: a half to one full DevOps engineer to maintain self-hosted runners at scale, $80K to $160K a year fully loaded. Storage and artifacts: GitHub bills $0.25/GB/month beyond the included tier , and build caches balloon quietly. Migration cost if you ever switch: a mid-size team should plan 6 to 12 weeks of work for two engineers to move 10 to 20 pipelines off Jenkins . One team spent three months migrating, three weeks panic-optimizing, and $10K in surprise costs to end up roughly where they started . Lock-in is real. YAML does not port cleanly.
For our standard model, a 50-developer team running a typical pipeline volume lands around $110K to $290K all-in over three years once you fold in compute growth, runner ops, storage, and the developer wait time the compute line ignores. Bring that range to finance, not the per-minute rate.
The adoption and idle-time discount the CFO applies
Every ROI story a CI/CD platform vendor tells assumes your pipelines are fast and reliable. They are not, on day one, and the gap is where your real cost lives. Apply a discount to any productivity claim, because the platform alone does not deliver it.
Flaky tests are the first leak. They consume 15 to 30% of total CI time in reruns for teams with frequent CI, and engineering teams spend 5 to 10 hours a week chasing false failures . For a 50-person engineering org, flaky tests alone can cost around $400,000 a year once you add developer time, wasted compute, blocked PRs, and confused incident triage. A CI/CD platform with native flaky-test detection and quarantine claws some of that back. One without it just bills you for the reruns.
Slow builds are the second leak, and they are worse because they hide.
GitHub’s own experiment found a 2-core build took 310 minutes where a 64-core build took 27 , and at $75 an hour a single developer idling on the slow build cost $389 versus $40 on the fast one.
Spending $4 to $5 more on build compute saved about $40 per build per developer. That is the rare case where buying the bigger runner is obviously correct, yet most teams default to the cheapest tier and pay the difference in idle engineers.
For the ROI anchor you bring to finance, be conservative. Do not promise “elite” velocity. The DORA research found top performers deploy far more frequently with much faster lead times , but that is correlation with strong engineering practice, not a guarantee the platform buys you.
Anchor your case on concrete hours: minutes shaved off the median pipeline, multiplied by commit volume, multiplied by your loaded rate, discounted for the fact that flaky tests and a six-week ramp eat the first year of gains. A CI/CD platform that pays back on reclaimed developer wait time alone survives scrutiny. One that needs a velocity miracle does not.
The security and procurement gate
CI/CD platforms hold the keys to your entire software supply chain. They have your deploy credentials, your cloud access, your signing keys, and a direct line into production. This is the highest-trust system you will buy, so procurement treats it as pass/fail. Collect this evidence before cost even matters.
The CircleCI breach in January 2023 is the cautionary tale every security lead will raise. An attacker stole an engineer’s 2FA-backed session cookie, accessed production, and exfiltrated customer environment variables, tokens, and SSH keys. CircleCI had to tell every customer to rotate all secrets.
That is the blast radius of a CI/CD platform compromise. Treat the gate accordingly.
- Current SOC 2 Type II report, reviewed under NDA, proving controls actually operate over time, not a trust-badge.
- OIDC keyless authentication to your cloud, so the platform holds no long-lived AWS or GCP credentials.
- Secrets stored encrypted with scoped, short-lived tokens, never plaintext in pipeline config or logs.
- SSO and SAML support on the exact tier you are buying, not gated several tiers up.
- Signed DPA covering GDPR for any EU developer or customer data touched in builds.
- SLSA build provenance or signed attestations if you ship software others depend on.
- Self-hosted or VPC runner option for code or data that cannot leave your network.
- Full audit logging of who triggered what pipeline, with one-year retention exportable to your SIEM.
- Branch protection, required PR approvals, and CODEOWNERS enforced as merge gates, not optional.
- Organization-wide MFA enforced, with no exception for service accounts or bots.
If a CI/CD platform cannot produce a current SOC 2 Type II report and OIDC support, it does not advance. That is not a negotiation.
The buying committee, mapped
A CI/CD platform purchase touches more people than the platform team realizes. Map the committee before the first demo, because each person blocks for a different reason and each needs different evidence.
The CFO or finance lead cares about predictable spend. Bring the three-year all-in TCO modeled at 2x build volume, plus the developer wait-time cost the compute line hides. The VP of Engineering cares about velocity and developer experience. Bring timed pipeline runs from the trial and the wait-time reduction in concrete hours.
The platform or DevOps lead owns the runners and the bill. Bring the self-hosted ops estimate and the concurrency limits at peak.
The security lead cares about the supply-chain blast radius. Bring SOC 2 Type II, OIDC proof, and the secrets-handling model. Procurement cares about contract terms. Bring the overage rates by OS, the platform fee on self-hosted, and a renewal cap in writing. And the developers who live in it daily care whether builds are fast and reliable.
Bring them into the trial directly, because their adoption is what makes or breaks the investment.
Running the trial like a test
Do not run a CI/CD platform trial as a feature tour. Run it as a controlled test against your real workload, because that is the only thing that predicts production cost and speed.
Connect the trial to your actual largest repository, not a sample. Port your real pipeline, including the slow integration tests and the flaky ones you pretend you do not have. Time the median wall-clock run, cached and uncached, three times each, and record the numbers.
Trigger a peak-load scenario: have several engineers push at once and measure queue wait against the concurrency cap on the tier you would actually buy, not the demo tier.
Then break things on purpose. Push a known-flaky test and see whether the platform detects and quarantines it or just reruns blindly. Verify OIDC works end to end by deploying to a real cloud account with no stored long-lived credentials. Pull the cost-by-pipeline view and check it attributes spend by team.
A trial that only ever runs green on a toy repo tells you nothing. Run it like a load test and a security test at the same time.
The one-page summary you bring to the C-suite
The C-suite will not read your scorecard. They will read one page, so build it deliberately. Lead with the recommendation and the use case in one line: this CI/CD platform, for this team, because of this.
Then the three-year all-in cost as a range, with the assumptions visible, so finance can see you modeled compute growth and runner ops, not just the sticker.
Show the developer wait-time number next, because that is the cost they did not know they were already paying. Put the security gate result as a single pass or fail line: SOC 2 Type II current, OIDC supported, DPA signed. Add the trial evidence: median pipeline time before and after, and the flaky-test handling result.
Close with the renewal and lock-in risk in one sentence each. One page. Cost, speed, risk, recommendation. If it does not fit on a page, you have not finished thinking.
Red flags that should end an evaluation
Walk away if the vendor will not put the per-minute overage rate by OS and the self-hosted platform fee in writing, because that means the compute bill is engineered to surprise you and you will be the one explaining the variance.
End the evaluation if the CI/CD platform cannot demonstrate OIDC keyless auth and a current SOC 2 Type II report, the trial refuses to connect to your real repository and cloud account, or the only “trial” on offer is a sales-led demo on a toy project with no way to time your actual pipeline.
A CI/CD platform that hides its real speed and real cost during evaluation will not get more honest after you sign.
Questions buyers ask before they sign
For the tested ranking that pairs with this guide, see our tested ranking of CI/CD platforms , and read how we score every category at /about/methodology/ . If you are also weighing the engineering org’s broader tooling spend, our developer tools category hub covers the adjacent buys.
How much does a CI/CD platform really cost beyond the per-minute rate?
Plan on the all-in number being several times the compute line. A 50-developer team commonly spends $3,000 to $8,000 a month on compute alone, and that grows with every commit and hire. Add self-hosted runner ops labor at $80K to $160K a year if you go that route, storage at $0.25/GB/month, and the developer wait-time cost, which can dwarf everything else.
Budget on the three-year all-in figure modeled at twice your current build volume, not the pricing page.
What ROI number is safe to put in front of finance?
Anchor on reclaimed developer time, not vendor velocity claims. The defensible model is minutes shaved off your median pipeline, times commit volume, times a loaded hourly rate, then discounted heavily for flaky tests and a multi-month ramp. GitHub’s own experiment showed faster runners save roughly $40 per build per developer in idle time.
A case that pays back on wait-time reduction alone survives a CFO review. A case that needs an “elite performer” velocity jump does not.
Why do CI/CD platform investments underdeliver?
Two reasons: flaky tests and slow defaults. Flaky tests consume 15 to 30% of CI time in reruns and cost a 50-person org around $400,000 a year all-in.
Slow builds compound through context switching, where it takes around 23 minutes to refocus after each interruption . The platform does not fix either by itself.
If you buy the cheapest tier and skip flaky-test handling, you bought the bill without the benefit.
How dangerous is the compute and minute pricing model?
It is the line most likely to surprise you, because it scales with usage, not headcount. CircleCI’s medium Linux runs about $0.06 a minute, six times GitHub’s $0.010, and macOS runners hit $0.08 to $0.30 a minute. Docker layer caching costs 200 credits per job on CircleCI regardless of build length.
Get the exact per-minute rate by OS and the overage rate in writing, then model your real monthly minute volume against it before you sign.
What security evidence do I actually need to collect?
The non-negotiables are a current SOC 2 Type II report under NDA, OIDC keyless authentication so the platform holds no long-lived cloud credentials, SSO and SAML on your buying tier, and a signed DPA.
The CI/CD platform touches your entire supply chain, so add SLSA provenance if you ship dependencies, full audit logging exportable to your SIEM, and a self-hosted runner option for code that cannot leave your network. The CircleCI breach is why this gate is pass or fail.
Should we self-host runners to cut the bill?
Only above roughly 50,000 build minutes a month, and only if you have the engineering time. Self-hosted runners can cut compute cost by 60 to 70%, dropping a $3,800 bill toward $300, but GitHub now charges its $0.002 per-minute platform fee on self-hosted runners too, and you still pay for the cloud VMs and a DevOps engineer to maintain them.
Below 50,000 minutes a month, the ops labor rarely pays back. Model the runner ops headcount honestly before you commit.
How do I keep the pricing from spiking later?
Negotiate the overage rate and a renewal cap now, while you still have room to push, because CI/CD vendors change pricing often. GitLab cut its free CI tier from 2,000 minutes to 400, GitHub added a platform fee on self-hosted runners in 2026, and CircleCI has revised credit allowances repeatedly.
Put the per-minute overage by OS, the self-hosted platform fee, and an annual uplift cap in the contract, and confirm your quoted price at twice your current build volume before signing.