Frequently asked questions about CI/CD cost

A typical team of 10 developers spends $150 to $800 per month on CI/CD depending on platform, OS mix, and caching discipline. A 3-person startup can run entirely on free tiers (GitHub Actions Free plan: 2,000 min/month; GitLab CI Free: 400 min/month). A 20-person team with active macOS builds pays $300-800/month on GitHub Actions. A 100-person org on GitHub Actions Enterprise with macOS builds can spend $5,000-15,000 per month. Use the interactive calculator on the homepage to model your specific workload.

GitHub leases Apple hardware to support macOS builds. Apple's licensing agreements and hardware constraints mean GitHub cannot offer macOS at Linux economics. macOS drains included minutes at a 10x multiplier and bills overage at $0.062/min versus $0.006 for Linux. External runner providers do not undercut this much: Depot, the main one offering macOS, lists it from about $0.08/min, no cheaper than GitHub-hosted. The reliable macOS saving is reducing macOS job frequency (build on macOS only for release branches) or self-hosting Mac Minis via MacStadium or Scaleway, often cheaper above 5,000 macOS minutes per month.

No. GitHub proposed a $0.002 per minute platform fee on self-hosted runner minutes for 1 March 2026, then postponed it indefinitely in December 2025 after community backlash. As of June 2026 it has not taken effect and self-hosted runner minutes remain free. The real 2026 change was a January price cut on GitHub-hosted runners (Linux to $0.006/min, up to 39% off), with the orchestration charge folded into those hosted rates.

CircleCI credits are not a trap, but they are opaque. The credit cost per minute varies by resource class: Docker medium at $0.006/min equivalent, large at ~$0.012/min, macOS large at ~$0.08/min. The 6,000-credit free tier covers approximately 1,000 minutes on Docker medium. The confusion arises because the credit system obscures the per-minute cost that competitors display directly. Use the calculator with CircleCI rates to compare apples to apples.

Buildkite's model: they charge $30/user/month for the platform (orchestration, UI, analytics) and you run your own agents on your own infrastructure. There is no per-minute charge from Buildkite itself. The cost model is therefore: Buildkite platform fee + your EC2/GKE infrastructure cost. For large teams (100+ users), the $3,000+/month platform fee is significant. For teams with massive workloads (200,000+ minutes/month), the total-cost comparison vs GitHub Actions can favour Buildkite.

For a startup under 3,000 minutes per month, GitHub Actions Free plan (2,000 min/month included) or GitLab CI Free (400 min/month, but free for public projects) cover most needs at zero cost. If you need more minutes and run Linux-only, the lowest paid per-minute rates come from Ubicloud (about $0.001/min for a 2-vCPU runner) and Namespace ($0.002/min prepaid); Depot and Blacksmith sit around $0.004/min. CircleCI's free tier (30,000 credits, about 6,000 build minutes) can be competitive for small Docker-heavy workloads.

Switch if your monthly CI cost is significant AND either an external runner saves you 40% or more, or you have a Windows-heavy workload Azure DevOps handles cheaper. For most teams under $200/month, the switching cost (migration time, testing, team retraining) outweighs the savings. Optimise your existing GitHub Actions workflows first using the 12 anti-patterns guide. Most teams recover 40-60% of waste without switching platforms.

Jenkins software is free. The infrastructure and maintenance are not. A 20-person team on self-hosted Jenkins typically pays: $50-150/month EC2 cost, $200-600/month engineer maintenance time (2-4 hours/month at $100-150/hour), storage and egress charges, and security patch overhead. Total real cost: $800-2,500/month. The software-is-free framing ignores 60-80% of the real cost.

For Linux-only workloads at moderate scale (3,000-20,000 min/month): GitLab Premium ($29/user) with 10,000 included minutes is often cheaper than GitHub Actions with overage. For macOS workloads: GitHub Actions is often cheaper because GitLab has no macOS shared runners on SaaS. For all-in-one (SCM + CI + registry + security): GitLab Premium is the better value proposition at 5-50 person scale. At 100+ person scale, the per-seat price of GitLab Enterprise or Ultimate changes the math significantly.

Depot is SOC 2 Type II certified, uses ephemeral runners isolated per job, supports OIDC federation for secrets, and offers an on-premises deployment option. Use OIDC instead of long-lived secrets, pin all workflow steps to verified action versions, and use Depot's on-prem option if your data-residency policy requires it. Depot is used in production by many engineering teams and publishes named customer case studies.

Need macOS? Depot (the only one here with macOS runners, from about $0.08/min, no cheaper than GitHub-hosted). Need the lowest per-minute rate? Ubicloud (about $0.001/min); Blacksmith for ARM ($0.0025/min). Need AWS-native with SOC 2? Blacksmith. Need fastest cold boot (~3s)? Namespace. Need open-source stack? Ubicloud. Depot and Blacksmith both bill around $0.004/min for Linux x86, so the choice turns on macOS support, cache and case-study evidence rather than headline rate. Depot is the most mature with the best case-study evidence base.

Change runs-on: ubuntu-latest to runs-on: depot-ubuntu-24.04 in your workflow files. That is the full migration for most workflows. Depot's images are compatible with GitHub-hosted images. The typical migration takes 30-60 minutes and requires no changes to your actual build scripts. Test on a branch, verify cache behaviour, then roll out across your workflows.

RunsOn is a managed control plane for GitHub Actions on your own AWS. You provide the AWS account; RunsOn handles runner lifecycle, spot instance management, and GitHub integration. It makes sense for teams that want EC2 economics without building their own Actions Runner Controller deployment. Setup is 1-2 hours vs 1-2 weeks for DIY ARC. The trade-off vs pure managed (Depot, Namespace): slightly slower cold starts, lower per-minute cost at high volume.

Self-hosted makes sense when: (1) you consume more than 80,000-100,000 minutes/month AND have a dedicated platform engineer, (2) GPU or specialised hardware requirements (ML training, CUDA), (3) compliance requires on-premises or VPC-isolated build infrastructure, (4) macOS builds at scale above 5,000 macOS min/month where self-hosted Mac Minis are cheaper. Below these thresholds, external runners win on total cost including engineer time.

A dedicated CI/platform engineer in the US costs $130,000-180,000/year in salary plus 30-40% benefits (total compensation $170,000-250,000). Even 0.1 FTE of a senior engineer's time dedicated to runner maintenance is $17,000-25,000/year. This is the hidden cost the self-hosted runner vendors do not include in their ROI calculators. For most teams, an external runner eliminates this overhead entirely.

Actions Runner Controller (ARC) is the official Kubernetes-native solution for self-hosted GitHub Actions runners. It uses KEDA for auto-scaling and runs ephemeral runner pods that terminate after each job. ARC is the highest-quality self-hosted option but requires Kubernetes operational expertise. Setup takes approximately one FTE-week. Ongoing maintenance is roughly 0.1 FTE per month. If you lack Kubernetes expertise, RunsOn or philips-labs/terraform-aws-github-runner are lower-barrier alternatives.

Yes, with caveats. Spot interruptions cause workflow failures. Mitigate by: (a) diversifying instance families in your pool (request c6i + c5 + m6i rather than just c6i), (b) implementing graceful interruption handling in your runner configuration, (c) labelling jobs with spot-ok: true for jobs that are safe to retry and spot-sensitive: false for jobs that cannot tolerate interruption. Expect 3-7% of builds to need re-runs due to spot interruption on a well-configured pool.

Most common causes in frequency order: (1) a new macOS workflow added (10x included-minute multiplier hits on first billing cycle), (2) E2E tests moved to run on every PR commit, (3) matrix strategy expanded (adding a third OS multiplies jobs 3x), (4) a new Docker build job without layer caching configured, (5) blowing past your included-minute allowance into overage rates. Go to Settings > Billing > Actions usage, sort by minutes consumed, and find the workflow that tripled.

In order of effort-to-payback ratio: (1) Add concurrency gate: 30 minutes, 20-40% saving. (2) Add paths filter: 60 minutes, 20-40% saving. (3) Cache dependencies: 2 hours, 30-60% of install time. (4) Switch to ARM Linux: 1 hour, ~17% on Linux cost. (5) Add Docker layer cache: half day, 60-80% of Docker build time. Most teams recover 40-60% of waste from steps 1-3 alone.

Start with the GitHub Actions usage API to identify the top 3 workflows by minutes consumed. Check each against the 12 anti-patterns list: paths filter, concurrency gate, dependency caching, Docker layer caching, test scope, OS selection. Fix the top anti-pattern in each workflow. This typically recovers 40-60% of waste in one week. For a comprehensive audit with a structured output, Digital Signet runs two-week pipeline cost audits.

Yes, for all Linux workloads where your dependencies support ARM64. The migration for a standard Node.js, Python, Go, Rust, or Ruby workload takes 1 hour and saves roughly 17% on Linux CI cost ($0.005/min ARM vs $0.006 x86 since the January 2026 repricing). Benchmark first on a branch. Failure cases: legacy C++ with x86 intrinsics, proprietary x86-only binaries, some ML frameworks, Chromium-based E2E testing. For most web and backend workloads, the switch is safe and the saving is immediate.

Prefix all workflow names with the owning team (team-backend/build-api). Pull the GitHub Actions usage API daily and group by team prefix. Calculate cost at current rates. This gives you a showback model in 2-3 hours. For a more sophisticated solution with dashboards, Vantage ($750-3,500/month) or CloudZero integrate GitHub Actions cost into broader cloud spend attribution.

Vantage is worth it if you are managing $20,000+/month of cloud spend and want CI costs alongside infrastructure costs in one dashboard. At that scale, the $750/month starting price is less than 4% of the spend it manages. For pure CI cost attribution under $5,000/month, a DIY script pulling the GitHub Actions usage API is sufficient and free.

The FinOps Foundation framework (finops.org) defines a process for managing cloud costs: Inform (visibility into spend), Optimise (identify reduction opportunities), Operate (continuous governance and accountability). Applied to CI: Inform means per-team/per-workflow cost visibility; Optimise means the anti-patterns playbook; Operate means monthly cost reviews and attribution reports. CI is often the missing piece in engineering FinOps programs because it is not cloud infrastructure in the traditional sense.