Just got my hands on a batch of anonymized quotes for various CI/CD platforms after helping a client untangle their "digital transformation" mess. The sticker shock is real, and the pricing gymnastics these vendors perform would make a circus contortionist jealous. Let's pull back the curtain.
The common theme? Opaque per-user pricing that scales linearly while your actual compute needs don't, and hidden costs for "premium" runners or "enterprise" features that are table stakes elsewhere.
Here are some real numbers, scrubbed of course:
* **Vendor A (SaaS-only):** Quoted $45 per "active committer" per month. Their definition of "active"? Any user who triggers a pipeline, even via a PR comment. A 50-person engineering team ballooned to 45 "active users" in their model. Annual quote: **$24,300**. This doesn't include the cost for their "performance tier" runners, which are mandatory for builds over 25 minutes. That's another ~$1,200/month.
* **Vendor B (Self-hosted option):** Base license: $15,000/year for up to 100 users. Seems okay? Wait for it. Their "premium support and updates" pack, which you need unless you want to manually patch everything, is a mandatory 22% of license cost annually. Suddenly year two is **$18,300**. They also charge extra for their "artifacts" module. Hosting it yourself means you're now on the hook for the underlying EC2/VM costs, which they conveniently omit from the quote.
* **Vendor C (Cloud-native, per-minute):** They advertise "$0.10 per compute minute". Looks simple. The quote breakdown revealed the catch: their "standard" Linux runner is indeed $0.10/min, but their Windows runner (needed for half their projects) is $0.30/min. The median pipeline time was 18 minutes. Estimated monthly compute cost: **$8,500**. Their "volume discount" kicked in after $5,000/month, reducing it by a whopping 5%.
The takeaway? You're not just buying a CI/CD tool; you're buying into a billing model designed to obscure total cost. Always model:
- True user count under their definitions.
- Peak concurrent pipeline needs.
- Artifact storage and transfer fees.
- The support tax (usually 20-25% after year one).
Run your own numbers based on your actual usage patterns, not their marketing page. The gap between the "contact sales" price and the "here's what it actually costs to use it" price is where they make their margin.
-- cost first
-- cost first
Oh, it gets even better. Vendor B's "mandatory" support pack is classic. It's not just 22% of the base license, it's 22% of the *list price*, which mysteriously never goes down even if you negotiate a "discount" on the initial fee. So you're paying a premium on a fictional number.
And let's not forget the annual true-up for exceeding your user cap. It's never prorated, always a full-year charge. These contracts are engineered to be a ratchet that only turns one way.
—DW
Ugh, that "active committer" definition is such a classic trap. It completely divorces the cost from the actual value you're getting, which is compute time and pipeline orchestration. You're paying for organizational sprawl, not utilization.
We saw something similar where a "free" tier for open source projects counted any outside contributor who opened a PR as a "user" for the org's total, pushing us into a paid plan. The pricing model actively discourages community collaboration.
It makes you wonder if the linear per-user pricing is just a lazy holdover from the days of seat-based software, where every user was actually opening the GUI. It feels completely misapplied to an automated infrastructure service.
Try everything, keep what works.
You've hit on something really important. That exact scenario with the open source project is what makes "per-user" pricing feel punitive in these contexts. It's not just misapplied, it actively creates a conflict between the tool's function and healthy project governance.
I've seen teams resort to creating a single "CI bot" user account to run all automation, just to keep the headcount down. That introduces its own security and auditability problems, of course, but it shows the extreme lengths people go to when cost is tied to identity rather than usage.
I do wonder if part of the vendor logic is that more users equals more potential support tickets, so they're trying to price in support overhead. But it's a very blunt instrument for that. A usage-based model with clear support tiers would feel much more aligned.
—HR
You've nailed the security trade-off that this pricing model forces. That single "CI bot" account becomes a massive privileged credential and a single point of failure. It completely obscures who actually triggered a deployment or approved a promotion in the audit logs, which is a nightmare for compliance later.
The support overhead theory makes sense, but you're right, it's a blunt instrument. A team of 50 developers who are heavy, sophisticated users might generate fewer tickets than a team of 10 novices. Pricing the support separately, or at least basing it on actual consumption tiers, would be a lot fairer. It feels like they're using the user count as a simple proxy for company size and budget.
Wow, that pricing is brutal. Seeing the real numbers is shocking. I'm still learning about this stuff, so maybe this is a basic question, but how do you even start comparing these quotes? Like, if one charges per user and another charges for compute minutes, how do you know which ends up being more? Is there a standard way to model it?
CloudNewbie
That $24k number is eye-watering. I'm new to this, but that's way higher than I expected just for the user seats.
When you add the "performance tier" runner cost on top, how does that even compare to just running your own agents on EC2 or something? Like, is the premium for the orchestration layer *that* huge?
Feels like you'd need a full-time spreadsheet just to track all these variables.
Still learning