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. The 10x multiplier ($0.08/min vs $0.008/min) reflects the real hardware cost difference at cloud scale. For teams running more than 5,000 macOS minutes per month, self-hosting Mac Minis via MacStadium or Scaleway is often cheaper. Depot offers macOS runners at 0.5x GitHub's macOS rate ($0.04/min).

In March 2026, GitHub introduced a $0.002 per minute platform fee on self-hosted runner minutes. This applies to every minute consumed by self-hosted runners connected to GitHub Actions workflows, in addition to whatever the runner infrastructure costs. For a team at 25,000 self-hosted minutes per month, this adds $50/month permanently. It materially shifted the break-even for self-hosted deployments.

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, BuildJet at $0.003/min is the cheapest paid option. CircleCI's free tier (6,000 credits) 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 thousands of teams including Shopify and Ramp.

Need macOS? Depot (only one that supports macOS at $0.04/min vs $0.08 GitHub-hosted). Need cheapest ARM Linux? BuildJet or Blacksmith ($0.002/min). Need AWS-native with SOC 2? Blacksmith. Need fastest cold boot (~3s)? Namespace. Need open-source stack? Ubicloud. For a general-purpose Linux + ARM workload, BuildJet is cheapest on pure rate. Depot is 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, BuildJet): 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 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) the March 2026 self-hosted platform fee if you have self-hosted runners. 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, 50% 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 50% on Linux CI cost. 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.