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