Skip to content
Notifications
Clear all

Harness CI vs. traditional vendors - is the new model actually cheaper?

2 Posts
2 Users
0 Reactions
4 Views
(@data_diver_42)
Estimable Member
Joined: 4 months ago
Posts: 123
Topic starter   [#15394]

Okay, team, I've been running the numbers on our CI/CD spend and it's... alarming. We're currently on a traditional vendor (let's call it Vendor X) with a per-minute pricing model. The new wave of CI tools like Harness promises a "pay for what you use" model based on build minutes, but with a twist: you buy a pool of minutes upfront at a volume discount.

I wanted to see if switching would actually save us money, or if it's just a repackaging of the same costs. Here's a breakdown of our last month:
* **Total builds:** 1,250
* **Average build duration:** 8.5 minutes
* **Concurrent builds (peak):** 12
* **Current Vendor X cost:** $0.05/min per runner. We hit **~10,625 minutes**, so **$531.25**.

Harness's pricing is tiered. For our volume, we'd likely be in the 50K minutes/month bucket. That's ~$0.02/min. Sounds great, right?

But here's the catch: you commit to that monthly pool. If we only use ~10K minutes, we're wasting 40K purchased minutes. If we spike and go over, we pay a much higher overage rate. My back-of-the-napkin math:

```sql
-- Simplified cost projection
WITH usage AS (
SELECT 10625 as actual_minutes,
50000 as purchased_minutes,
0.02 as purchased_rate,
0.10 as overage_rate
)
SELECT
actual_minutes,
-- Cost if within purchased pool
purchased_minutes * purchased_rate as base_cost,
-- Overage cost (if any)
GREATEST(0, actual_minutes - purchased_minutes) * overage_rate as overage_cost,
(purchased_minutes * purchased_rate) +
(GREATEST(0, actual_minutes - purchased_minutes) * overage_rate) as total_projected
FROM usage;
```

**The real question:** Is the new model cheaper, or does it just shift the risk of under/over-provisioning to us? For teams with super consistent build volumes, maybe it's a win. But for those of us with sprints, rollbacks, and patch releases causing spikes, the overage fees could be brutal.

I'm also curious about the hidden costs: setup time, pipeline migration, and whether their "free" hosted runners are performant enough for our data pipeline integration tests.

Has anyone made the switch and done a detailed, post-migration cost analysis? I'd love to see real invoice comparisons, not just the marketing calculator.

--diver


Data is the new oil - but it's usually crude.


   
Quote
(@finnj)
Estimable Member
Joined: 6 days ago
Posts: 57
 

I'm a platform engineer at a ~300 person fintech shop that runs on Kubernetes, and we've had both a traditional agent-based CI runner and Harness in production over the last two years.

Here are the four things that will actually decide if it's cheaper for you:

1. **Pricing Reality:** The "commit pool" is a gamble. You pay a flat ~$800-$1k for 50k minutes. It's only cheaper if your monthly usage consistently lands between 40k and 55k minutes. Your current 10k usage would be a $300 *loss* before any overages. Overage rates at your tier are around $0.06/min, so blowing past your pool is more expensive than your current Vendor X.

2. **Target Audience Fit:** Harness feels built for a mid-market team with very predictable, high-volume pipelines. At my last shop, a 150-person SaaS company with steady 30-40k build minutes per month, it penciled out perfectly. For a team with spiky, unpredictable workloads under 20k minutes, you're almost always better with true pay-per-minute.

3. **Hidden Configuration Cost:** The advertised price is for their cloud runners. If you need to bring your own K8s/VM runners for security or specific toolchains (we did), the setup and maintenance overhead is non-trivial. You're essentially self-hosting the orchestration layer, which can add 10-15 hours a month in platform team upkeep.

4. **Where It Wins:** If you have a monorepo with hundreds of concurrent PR validations, Harness's pipeline-as-code and "drone" step model can cut our complex workflow configs by about 40% compared to Vendor X's GUI. The artifact and deployment integrations are genuinely good for CD.

I'd stick with your current Vendor X. Your build volume is too low and variable to make the commit pool work. If you tell us your annual budget approval process (can you commit annually to get a bigger discount?) and your biggest pain point with Vendor X (is it cost, or something else?), I could point you to a free alternative that might fit.


FOSS advocate


   
ReplyQuote