Skip to content
Notifications
Clear all

Complete newbie here - how do I even estimate CI costs?

3 Posts
3 Users
0 Reactions
1 Views
(@harukik)
Estimable Member
Joined: 2 weeks ago
Posts: 116
Topic starter   [#22508]

Hi everyone! First post here 😅

I'm looking at setting up CI for my team's SaaS project. We're still small, maybe 50-100 builds a month right now? But I'm completely lost on how to even start estimating the cost.

Everyone talks about "compute minutes" and "concurrent jobs," but I don't know what a typical build actually uses. Is it like a small VM running for 10 minutes? What about the storage for artifacts?

Do you start by looking at your current local build times? And then just... multiply by the cloud provider's hourly rate? Feels like I'm missing something big.

Also, are there hidden costs with the managed platforms (like GitHub Actions, GitLab CI, CircleCI) that aren't obvious at first? Really appreciate any pointers from your own experiences!



   
Quote
(@davidm)
Estimable Member
Joined: 2 weeks ago
Posts: 109
 

Great question, and I feel the same confusion! Starting with your local build time is smart. For a rough guess, I timed a simple Docker build on my machine, then checked the comparable runner specs on GitHub.

A hidden cost I didn't expect was network egress. If your builds download a lot of dependencies each time, that can add up. Also, artifact storage often has a retention period before extra charges kick in.

Thanks for asking this - following to see what others say.



   
ReplyQuote
(@felixr47)
Trusted Member
Joined: 2 weeks ago
Posts: 45
 

Timing your local build is definitely a smart starting point, but you're right to feel that just multiplying by a cloud rate misses a lot. The hidden multiplier is often the "overhead" of a fresh CI environment versus your warmed-up local machine. Every run starts from zero, downloading dependencies, pulling images, setting up caches. For a 5-minute local build, I've seen it stretch to 15 in CI.

For a rough estimate at your scale, take that local time, double or triple it for the overhead, then think about the runner "size". A "small VM" is a good mental model. A 2-core runner is fine for linting, but a real build/test cycle might need 4 or 8 cores to finish in a reasonable time. The cost difference per minute between those sizes is significant.

On hidden costs, beyond network egress, watch for how platforms charge for "idle" time. Some round up to the next minute, some bill in 10-second increments. And artifact storage costs often sneak in once you keep them beyond a few weeks. My advice? Start with the free tier of a platform, run a dozen builds, and look at the usage metrics they provide. That's the most accurate forecast you'll get.



   
ReplyQuote