Most "best CI/CD tools" lists are twenty logos in a table, ranked by nothing in particular, with the author's product at the top. This is not that. It is a map of the categories, what each one exists to solve, and how to tell whether you need it yet.
I work at Latchkey, so I will say plainly where we sit: we are one option inside one of the six categories below, and I will tell you when we are the wrong answer. Read the rest as a map, not a pitch.
A note on what is missing here: I have not invented benchmark numbers or quoted prices for tools I do not operate. Vendor pricing changes often enough that any figure I write today is wrong by the time you read it. Where a number matters, go to the vendor's own pricing page.
The mistake most teams make
Teams usually shop for CI/CD tools by asking "which one is best." That question has no answer, because the tools are not competing with each other. They are stacked on top of each other.
A team that adopts a build accelerator to fix a slow pipeline, when the actual problem is that half their failures are flaky, has bought a faster way to fail. A team that adds pipeline observability before they have enough pipeline to observe has bought a dashboard nobody opens.
The useful question is narrower: which layer is currently your constraint? Answer that, and the tool choice inside the layer is usually obvious.
Here is the whole landscape in one view.
| Layer | What it solves | When it becomes your bottleneck |
|---|---|---|
| CI platform | Running the pipeline at all | Never; this is where everyone starts |
| Runners and compute | Where jobs run, and how fast they start | Queue time or runner cost is visible |
| Build acceleration | Doing less work per run | Full rebuilds dominate your wall clock |
| Supply chain security | What the pipeline is allowed to reach | You ship to production or touch customer data |
| Observability and cost | Where time and money actually go | You cannot answer why last week was slow |
| Artifacts and registries | Storing what the pipeline produces | You publish images or packages |
The rest of this post walks each row.
1. CI platforms
This is the layer everything else plugs into: the thing that watches your repository, decides what to run, and reports back.
The practical split in 2026 is between platforms that live where your code lives and platforms you bring to your code.
GitHub Actions is the default for most teams on GitHub, and the default is a real advantage: the trigger model, the permissions, and the marketplace of reusable actions are already wired to the repository. GitLab CI occupies the same position for GitLab teams. Jenkins remains the answer when you need to run somewhere no SaaS reaches, and the cost is that you now operate a Jenkins. CircleCI and Buildkite are the main "bring your own" options, with Buildkite in particular built around the idea that the control plane is hosted and the compute is yours.
The honest guidance for this layer is boring: use whatever your forge gives you until it stops working. Platform migrations are expensive, they rarely fix the problem you actually have, and the problem you actually have is usually in one of the five layers below.
If you are evaluating a platform switch to solve slow or flaky builds, check the next two categories first. The pipeline definition is rarely what is slow.
If you want the vocabulary before you evaluate anything, our CI/CD glossary defines the terms these vendors use inconsistently.
2. Runners and compute
This is where the jobs actually execute, and it is the layer most teams reach for second, usually because a build queue got long enough to notice.
Three models exist:
- Platform-hosted. GitHub-hosted runners, GitLab's shared runners. Zero operations, and you pay per minute at the platform's rate.
- Self-hosted. Your machines, your problem. Cheapest per minute on paper and the true cost is the engineer maintaining the fleet, patching the images, and answering why a runner is wedged.
- Managed third-party. A vendor operates ephemeral runners that register with your CI platform. You change a label, they handle the machines. This is where Depot, Blacksmith, WarpBuild, RunsOn, and Latchkey sit.
The tradeoff inside the third category is not really about price per minute, because those numbers are close enough that the difference rarely dominates a bill. It is about what else the runner does: some optimise cold start, some bundle caching, some focus on Docker builds specifically.
Where we sit, stated plainly. Latchkey runs ephemeral Linux runners that you switch to by changing one runs-on line:
jobs:
build:
runs-on: latchkey-small # was: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
Every job gets a fresh single-use machine that is destroyed afterwards, and the differentiator we actually build for is that the runner repairs its own transient failures mid-run rather than handing you a red X. That is described in full in our self-healing documentation.
When we are the wrong answer, and this is the useful part of the section:
- You need Windows, macOS, or arm64. Latchkey runners are Ubuntu x86_64 only. If your matrix spans operating systems, keep those jobs on platform-hosted runners. Mixed workflows are fine, but we cannot be your only runner.
- Your builds are dominated by Docker image builds specifically. That is a narrower problem with vendors built squarely around it.
- Your CI is already fast and cheap. If your pipeline finishes in three minutes and costs less than a coffee, this entire category is a solution to a problem you do not have.
For a category overview independent of any one vendor, we maintain a managed runners explainer, and per-vendor comparisons live under our comparison pages — which are, obviously, written by us.
3. Build acceleration
Everything in this category exists to avoid redoing work. It splits cleanly in two.
Caching restores artifacts from a previous run: dependency trees, compiled objects, Docker layers. It is the cheapest speedup available and the most commonly misconfigured thing in CI. The usual failure is a cache key that changes every run, which means you pay the cost of saving a cache you never restore.
We have written the details up separately rather than repeat them here:
- CI caching explained — the general model
- Cache key vs restore key — the single most common misconfiguration
-
GitHub Actions caching and its limits — where
actions/cachestops helping - Docker layer caching explained
- Dependency caching strategies
Build systems with caching built in are the heavier answer. Bazel, Nx, Turborepo, and Gradle with a build cache all model your build as a dependency graph, so they can skip any node whose inputs have not changed, and share those results across machines.
The adoption cost is real and worth stating: you are restructuring your build, not adding a step. The rule of thumb that holds up is monorepo size. In a single-package repository, a well-configured dependency cache gets you most of the win for a fraction of the effort. Once you have many packages where a one-line change triggers a full rebuild of everything, graph-aware tooling starts paying for itself.
The signal to watch is not build duration. It is the ratio between "how much changed" and "how much rebuilt." If a one-line change rebuilds the world, you have a graph problem, and no amount of faster compute fixes a graph problem.
Side-by-side breakdowns of the individual tools live in our tool comparisons.
4. Supply chain security
The pipeline is the most privileged thing most teams run. It holds credentials for production, it can push to your registry, and it executes third-party code on every run.
The categories worth knowing:
| Concern | What it means | Representative tooling |
|---|---|---|
| Runtime egress control | Restricting what the runner can reach mid-job | Harden-Runner |
| Dependency scanning | Finding known vulnerabilities in what you pull in | Dependabot, Renovate, Snyk |
| Artifact signing | Proving an artifact came from your pipeline | Sigstore, cosign |
| Provenance and SBOM | A verifiable record of what went in | SLSA provenance, syft |
| Secret hygiene | Keeping credentials out of logs and source | OIDC federation, gitleaks |
The highest-leverage item on that list for most teams is not a scanner. It is replacing long-lived cloud credentials with OIDC federation, so the pipeline exchanges a short-lived token per run instead of holding a static key that lives in your secrets forever.
The second is pinning third-party actions to a commit SHA rather than a mutable tag. uses: some/action@v3 means you run whatever that tag points at today, which is not necessarily what it pointed at when you reviewed it.
5. Observability and cost
This is the layer that barely existed as a category five years ago and is now the one teams ask about most, for a simple reason: the number of builds went up faster than the number of engineers.
There are two distinct questions here, and tools tend to answer one or the other:
"Why is the pipeline slow or unreliable?" Duration trends, failure rates, flaky test detection, mean time to recovery. Some CI platforms ship a version of this natively; dedicated tools go deeper, particularly on flake detection.
"Where is the money going?" Spend attributed to a repository, a workflow, a runner size. This is harder than it sounds, because the platform bill arrives as one number and the interesting question is which of your two hundred workflows caused it.
Latchkey does both, and I will be specific about the boundary so it is not oversold: we report on the jobs we can see. Cost analytics cover your GitHub Actions usage and your Latchkey runner usage, broken down by repository, workflow, and runner, with free-tier minutes tracked for both. If a large part of your build spend is somewhere else entirely, a separate cloud account doing container builds, say, we are not seeing it and will not pretend to.
If the general problem interests you more than our take on it, our GitHub Actions cost guide covers the mechanics without needing our product.
6. Artifacts and registries
The least glamorous layer, and the one that quietly breaks builds most often.
Container registries (GHCR, ECR, Docker Hub, Artifactory), package registries (npm, PyPI, Maven Central, and private mirrors), and build artifact storage all live here. Two failure modes account for most of the pain:
- Rate limits. Anonymous pulls from public registries are throttled, and CI is very good at looking like abuse. The fix is authenticating pulls or running a pull-through cache.
- Retention. Artifact storage accumulates until someone notices the bill. Retention policies are boring and worth setting on day one.
When these break they usually surface as an error message rather than a design decision, which is why most of our writing on this layer sits in our CI/CD error library rather than in a guide.
How to actually choose
A sequence that works, in order:
- Measure before you buy. Find your slowest and most frequent workflows and the failure rate of each. Any tool you evaluate should point at a number you already have.
- Fix caching first. It is the cheapest intervention in the entire landscape and it is misconfigured more often than not.
- Separate flaky from broken. If a meaningful share of your failures are environmental rather than real defects, faster compute makes them arrive faster. That is a reliability problem, not a speed problem.
- Only then buy compute. Once builds are doing the minimum necessary work and failing for real reasons, throwing faster machines at them produces a clean, measurable win.
- Add observability when you have more than one team. Before that, you already know what is slow.
The through-line: most CI problems are not solved by the layer people reach for first. Slow builds are usually a caching or graph problem, not a compute problem. Unreliable builds are usually an environment problem, not a test problem. The tool categories are easy; the diagnosis is the hard part.
The honest summary
The CI/CD tool landscape looks crowded because it is six distinct markets that share a name. Almost nobody needs all six. Most teams need their forge's default CI platform, working caching, and one thing fixed in the layer that is currently their constraint.
We build in the runners-and-compute row, with a reliability angle. If your constraint is elsewhere — and for plenty of teams it is caching, or a build graph, or nothing at all yet — then the right move is to fix that instead, and this post did its job either way.
If you take one thing from this: figure out which row you are in before you shop. The tools are not competing. The layers are stacked, and only one of them is your bottleneck today.
Check us out at https://latchkey.dev
Top comments (0)