Tools for CI and CD: The Layers, and What Decides Each Choice
A CI/CD toolchain is five separate decisions that get discussed as one. Most teams only genuinely choose two of them, and the two that matter are rarely the ones the comparison articles are about.
Search for CI/CD tools and you get a ranked list of platforms, as though the choice were one product. In practice a pipeline is assembled from five layers, and they are chosen at different times, by different people, for different reasons.
Naming the layers separately is what makes the decision tractable, because it turns "which CI/CD tool" into five questions with much clearer answers, several of which are already made for you.
The five layers
| Layer | Responsible for | What decides it |
|---|---|---|
| Orchestrator | Reacting to a commit, running jobs in order, reporting status | Where your code lives. Almost always already decided. |
| Compute | The machines the jobs run on | Cost, queue time, and how much of the machine you want to own. |
| Build and test | Compiling, testing, linting your code | Your language ecosystem, not your CI vendor. |
| Artifacts and registry | Storing what the build produced | Where you deploy to. |
| Deploy and release | Getting the artifact to production safely | Your runtime and your risk appetite. |
The orchestrator is mostly not a choice
GitHub Actions, GitLab CI, Bitbucket Pipelines and Azure Pipelines are each the default for the git host of the same name, and the integration is the point: the pipeline is triggered by a push and writes status back to the pull request without you wiring anything. Choosing an orchestrator that does not live beside your repository buys you a webhook and a permissions problem. The teams who genuinely choose here are ones with a specific need the default cannot meet, usually enormous scale or an unusual compliance boundary.
Compute is the layer with real headroom
This is where the money and the waiting are, and it is the layer the orchestrator does not force. GitHub-hosted runners cost $0.006 a minute for a 2-core Linux machine and are free without limit on public repositories. Self-hosted runners have no per-minute charge and transfer the whole operational cost to you: patching, autoscaling, idle capacity, and the security review of machines that check out your source. Managed runners keep the orchestrator and swap the machines underneath, usually via one line of YAML.
Build and test tools are chosen by your ecosystem
- Node: npm, pnpm or yarn for installs; Vitest or Jest for tests; Playwright or Cypress for browsers.
- Python: pip or uv for installs; pytest for tests.
- Go and Rust: the toolchain ships with the language, which is most of why their CI is simple.
- Containers: Docker with BuildKit, and buildx when you need multi-architecture images.
The tools people actually mean
| Layer | What you will see named | Notes |
|---|---|---|
| Orchestrator | GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure Pipelines, CircleCI, Jenkins, Buildkite, Drone | The first four follow a git host. Jenkins is the one people inherit rather than choose; Buildkite and Drone are picked deliberately, usually to run the compute themselves. |
| Compute | GitHub-hosted runners, self-hosted runners, Latchkey, Blacksmith, WarpBuild, Depot, BuildJet, Namespace | Independent of the orchestrator, and the only layer you can swap without editing pipeline logic. |
| Build and test | npm, pnpm, uv, Maven, Gradle, Bazel, Vitest, pytest, Playwright | Determined by your language, not by your CI vendor. Nobody picks a CI platform to get a test runner. |
| Artifacts and registry | GitHub Packages, Docker Hub, Amazon ECR, Artifactory, Harbor | Usually follows wherever you deploy, so this is decided by your cloud. |
| Deploy and release | Argo CD, Flux, Helm, Terraform, Kubernetes, Ansible, plain scripts | Determined by your runtime. A pipeline calls these; it does not replace them. |
What to actually evaluate
- Queue time, not just run time. A three-minute job that waits four minutes for a machine is a seven-minute pipeline.
- What happens to a transient failure. Most CI failures are not bugs, and a toolchain that fails the build and waits for a human is charging you twice.
- Whether the cost is legible. If nobody can say which workflow is expensive, nothing will be optimised.
- How much you can change without rewriting the pipeline. Swapping compute should be a line; swapping orchestrator is a migration.
Migrating between CI platforms: what actually costs time
- Pipeline syntax is the easy part and the part every comparison focuses on. Budget for it, then expect it to be the smallest line item.
- Secrets, OIDC trust relationships, and deploy credentials have to be recreated and re-approved, usually by a different team.
- Caching semantics differ enough that a naive port produces a pipeline that is correct and much slower.
- Required status checks and branch protection reference check names. Renaming them mid-migration blocks merges until the rules are updated.
- Run both in parallel on the same commits until the new one has been green for a full sprint. Cutting over on a green first run is how migrations get rolled back.