Nobody switches CI/CD platform because a competitor has nicer YAML. They switch because the build got slow enough that engineers started batching changes to avoid waiting, or because the invoice arrived and somebody in finance drew a circle around the line item.
Those two triggers are the same problem seen from opposite ends. A pipeline that takes too long is a pipeline consuming too much metered compute. Whether that surfaces as wall-clock pain or as money depends entirely on how your platform bills, and the billing models here are not variations on a theme. Per-minute, per-seat, per-concurrent-job and bring-your-own-compute are four different economic shapes, and each is cheap for one kind of pipeline and punishing for another.
That is what most CI/CD comparisons skip. They put twenty logos in a grid, tick “supports Docker” for all twenty, and leave you where you started. The features converged years ago. The meter did not.
So this is a map: the four jobs a CI/CD platform actually does, how each billing model interacts with pipeline shape, and where to go next for your specific situation.
Key takeaways
- Feature parity across mainstream CI/CD platforms is close enough that features rarely decide the choice. The billing unit does, because it interacts with pipeline shape.
- Per-minute billing punishes wide fan-out. Per-concurrent-job billing punishes bursty teams with idle periods. Per-seat billing punishes large orgs with small pipelines.
- Compute is now separable from control plane. Several platforms let you keep the orchestration and swap the machines underneath, which changes the calculation entirely.
- Migration cost lives in the surrounding ecosystem, not the pipeline file: secrets, runner images, deploy credentials, artifact stores, and every script reading a platform variable.
The four jobs hiding under one word
“CI/CD platform” bundles four responsibilities that used to be separate products, and every vendor is stronger at some than others.
Event handling and orchestration. Something happened in a repository. The platform decides which workflows that triggers, resolves job dependencies, applies concurrency limits and decides what runs in parallel. This is the control plane, where syntax, reuse and debugging ergonomics live.
Compute scheduling. A job needs a machine with a particular architecture, memory size and container runtime. The platform finds one, boots it, hands over the workspace and reclaims it. Boot latency and cache locality dominate, and this is the layer third-party CI runner providers have prised away from the incumbents.
State between runs. Dependency caches, compiled artifacts, container layers, test history. CI is nominally stateless and in practice entirely dependent on state carried forward, which is why build caching is usually the highest-leverage fix in a slow pipeline.
Delivery. Turning a green build into a running system: promotion, approvals, rollout, rollback. Many teams have moved this out of CI into GitOps tooling or a dedicated deployment orchestrator, which is often right because the failure modes are different.
A platform that is excellent at orchestration but mediocre at compute can be fixed without changing platforms. A platform that is weak at state carries that weakness everywhere.
How platforms bill, and what each model punishes
There are four meters in this market. Everything else is a variation.
Per build minute. You pay for wall-clock machine time, multiplied by a coefficient for larger machines and usually a further one for macOS or Windows. Simple to reason about, and the hosted default.
The trap is fan-out. A matrix testing four language versions across three operating systems is twelve jobs, each paying the full cost of checkout, dependency install and toolchain provisioning before a single test runs. Under per-minute billing that setup overhead multiplies by matrix width, and it is frequently larger than the tests. Teams see the matrix as free parallelism because it finishes in the time of the slowest cell. The meter sees twelve machines.
Per concurrent job. You buy the right to run N jobs at once and minutes are unmetered. This inverts the incentive completely: parallelism is no longer free, it is the thing you are purchasing, while a long build costs nothing extra, so nobody optimises test duration until a queue forms.
Good for steady, high-volume traffic and bad for bursty teams. If your engineers push hard for a few hours a day and nothing overnight, you are paying for idle concurrency the rest of the time. It is also the model where queue depth, not build duration, becomes the thing people complain about.
Per seat. You pay per developer with access, with compute bundled or metered separately. Common where CI is one component of a platform that also sells source hosting, registries and scanning. The economics favour small teams with heavy pipelines and work against large organisations where most engineers rarely trigger a build. Watch for the version where seats and minutes are both metered.
Bring your own compute. The platform orchestrates and you supply machines, either self-hosted runners in your cloud account or a third-party fleet. You pay your cloud provider instead, which is cheaper per unit and more expensive per hour of human attention. Autoscaling becomes your problem, and so does the security boundary around untrusted code. Self-hosted CI/CD covers what that costs in maintenance.
Needs first-hand data: Instrument one real pipeline run to record, per job, the seconds spent on runner acquisition, checkout, dependency restore, build and test. Publish the split as a share of total job time. That setup-to-test ratio tells you whether you have a compute problem, a caching problem or a test problem, and almost nobody measures it before buying.
Pipeline shape is the other half of the equation
Billing model alone decides nothing. It becomes a decision when multiplied by what you run.
Wide and short means large matrices and heavy fan-out. Every job pays a fixed startup tax, so cost tracks job count rather than test duration, and per-minute billing is expensive. Warm caches, prebuilt images and fast runner boot pay back immediately.
Narrow and long means one or two jobs that run a long time: a monolith suite, a large compilation, an image built from scratch. Per-concurrency is cheap here because you are not buying parallelism, and the leverage is caching and incremental builds. Monorepo build tools exist to convert this shape into the previous one by rebuilding only what changed.
Bursty means long quiet stretches then a flood. Reserved concurrency sits idle most of the day, and on-demand metering matches the demand curve better. Continuous is the inverse: a large organisation where the pipeline never goes quiet, reserved capacity wins, and queue management becomes the real work.
Heavy on non-Linux covers macOS for iOS builds, Windows for .NET, and anything needing GPUs. These carry premium multipliers on every platform, and that multiplier is often the largest single term in the bill. Check it first, because it can invert an otherwise clear comparison.
GitHub Actions
The default for anything already on GitHub, and defaults win. Workflows live beside the code, the event model covers essentially every repository action, and the marketplace of reusable actions turns most integrations into a few lines rather than a script. Compute is hosted and metered per minute with multipliers by machine size and operating system, and self-hosted runners are first-class.
Pros
- Zero integration work when code already lives on GitHub, including status checks and pull request gating
- The largest ecosystem of prebuilt steps in the category, which removes a lot of glue scripting
- The runner layer is genuinely pluggable, so you can keep the control plane and replace the machines
- Federated cloud credentials are well supported, removing long-lived deploy keys from the pipeline
Cons
- Reusable actions are third-party code running with access to your build, which is a real supply-chain surface
- Debugging is weak: reproducing a failing job locally is awkward, and re-running with extra logging is the usual workaround
- Per-minute metering with non-Linux multipliers makes wide matrices expensive quickly
Best for: Teams already on GitHub who want the shortest path from commit to green check and will govern which third-party actions are permitted.
Pricing: Metered per build minute on hosted runners, with multipliers for larger machines and for macOS and Windows, plus separate metering for artifact and cache storage.
GitLab CI/CD
GitLab sells CI as one component of a single application that also covers source hosting, package registry, security scanning and environments. That integration is the product. Pipelines are defined in one file with a mature include and extends system, and the same platform runs identically whether you use the hosted service or install it yourself.
Pros
- One system for repository, registry, CI, environments and scanning, which removes cross-tool wiring
- The self-managed edition is the same product as the hosted one, not a reduced legacy build
- Strong composition primitives: includes, extends, parent-child pipelines and templated jobs
- Environment and deployment tracking is built in rather than bolted on
Cons
- The single-application model means adopting opinions across several categories at once, and leaving is proportionally harder
- Capability tiering is aggressive, and features you assumed were core often sit in higher editions
- Self-managed operation is a real platform-team workload, not a weekend install
Best for: Organisations that want one vendor across source control, CI and security scanning, particularly where a self-managed install is a compliance requirement.
Pricing: Per-seat subscription tiers with an allowance of hosted compute minutes and metered overage, or unmetered when you attach your own runners.
CircleCI
CircleCI is an independent CI specialist rather than a source host with CI attached, and the product reflects that focus. Its configuration model, with orbs for reuse and explicit workspace, cache and test-splitting primitives, is aimed at teams who treat pipeline performance as an engineering problem rather than a background service.
Pros
- Caching, workspace and test-splitting primitives are explicit and well designed rather than implicit
- Resource classes let you match machine size to job instead of paying uniformly across the pipeline
- Source-host neutrality matters when your repositories are not all in one place
- Parallelism-aware test splitting shortens the critical path on large suites without manual sharding
Cons
- Another vendor to integrate, authenticate and pay for when your source host already ships CI
- Credit-based metering folds machine size and duration into one unit, which makes forecasting harder than raw minutes
- The reusable orb ecosystem is smaller than the GitHub marketplace, so more glue is yours to write
Best for: Teams with a genuinely expensive test suite who will invest in splitting and caching and want that tuning to be first-class.
Pricing: Credit-based metering where machine size and duration both draw from a shared pool, with plan tiers layering on concurrency and support.
Where to go next
The rest of this cluster splits by situation rather than by vendor.
Choosing a platform. Small and cost-sensitive: CI/CD for startups, on what free allowances actually buy. Procurement in the room: CI/CD for enterprise, which leads with the gates that eliminate vendors before features matter. Must run on your own hardware: self-hosted CI/CD. Down to the obvious three: GitHub Actions vs GitLab CI vs CircleCI. Escaping an existing installation: Jenkins alternatives, written for migration rather than greenfield.
Making builds faster. CI runner providers swaps the compute without swapping the platform. Build caching tools is usually the higher-leverage fix, and monorepo build tools is the structural version of the same idea.
Shipping what the build produced. Deployment orchestration and GitOps tools move artifacts into environments. Preview environments cover per-branch deployments. Feature flag platforms and LaunchDarkly alternatives decouple release from deploy. Database migration tools cover the part of a deploy that cannot be rolled back casually.
Infrastructure and artifacts. Infrastructure as code tools and Terraform alternatives cover provisioning from a pipeline, and container registries cover where images live.
Securing the pipeline. Secrets management for CI/CD covers credentials, and supply chain security and SBOM tools cover provenance and dependency risk. When a deploy goes wrong, incident management tools pick up where the pipeline stops.
How to choose
Work in this order. It eliminates faster than a feature comparison.
Classify your pipeline shape first. Count jobs per run, measure the setup-to-test ratio, note how much non-Linux compute you need. That narrows the billing model before you look at a vendor.
Check the hard constraints second. Air-gapped operation, data residency, or a rule that source code cannot leave your network eliminates most hosted options immediately.
Decide whether compute and control plane are one purchase. They no longer have to be, and keeping the control plane while replacing the runners is the cheapest meaningful change available to most teams.
Price the migration honestly. Pipeline syntax is the easy part. The cost is secrets, deploy credentials, runner images, artifact storage and every script reading a platform-specific variable.
| Platform | Control plane | Compute | Meter | Fits best when |
|---|---|---|---|---|
| GitHub Actions | Hosted | Hosted or self-hosted | Build minutes, size and OS multipliers | Code is on GitHub and matrices are modest |
| GitLab CI/CD | Hosted or self-managed | Hosted or self-hosted | Seats plus metered minutes | One vendor across source, CI and scanning |
| CircleCI | Hosted | Hosted | Credits combining size and duration | The test suite is expensive and worth tuning |
| Buildkite | Hosted | Yours only | Seats, compute on your cloud bill | Builds must run inside your own network |
| Jenkins | Self-managed | Yours only | No licence, infrastructure plus staff time | Legacy toolchains nothing hosted supports |
Needs first-hand data: Port one representative pipeline to each finalist and record wall-clock time from push to green plus the cost that run consumed under each vendor meter. Run it both warm and cold, because cache behaviour differs more between platforms than the marketing suggests, and the cold number is what you get after every dependency bump.
Frequently asked questions
Should CI and CD be the same tool?
Increasingly not. Continuous integration is a fast feedback loop triggered by commits. Delivery is a controlled state change to a running system with approvals, progressive rollout and rollback. Different failure modes, different audiences. Many teams keep CI in their source platform and move delivery to a GitOps controller, and that separation makes both halves easier to reason about.
Is per-minute or per-concurrency billing cheaper?
It depends on utilisation. Per-concurrency is a fixed cost that gets cheaper the more of the day you keep those slots busy, and wasteful for bursty teams. Per-minute tracks demand exactly and punishes wide fan-out, because every parallel job pays its own setup tax. Work out your actual busy hours per day before assuming reserved capacity is the saving.
Can I keep my CI platform and just make builds faster?
Usually yes, and it is the first thing to try. The two independent levers are caching, which reduces work done, and compute, which reduces time per unit of work. Both change without touching orchestration, and together they resolve most speed complaints without a migration.
Related reading
- Best CI/CD tools for startups — what free minute allowances actually buy, and where the free tier stops.
- Best CI/CD platforms for enterprise — the procurement gates that eliminate vendors before features are discussed.
- Best self-hosted CI/CD tools — maintenance hours per month and the runner autoscaling problem.
- Best CI runner and compute providers — replacing the machines without replacing the platform.
- Best build caching tools — the highest-leverage fix for a slow pipeline.
- Jenkins alternatives — written for the team with hundreds of existing jobs, not a greenfield choice.