The CI market has split into three
Runner vendors are winning today, but cheaper compute does not fix CI’s deeper problems. The next shift is toward programmable, agent-native build infrastructure.
48 CI providers is a lot. Although most people probably start with the build system provided by their source control (probably GitHub Actions, possibly GitLab CI) there are a lot of alternatives. From our recent analysis of all CI providers, what stood out is that CI is no longer one market. There are really three sub-categories:
- Commodity runner infrastructure. Basically faster or cheaper GitHub Actions.
- Orchestration platforms. They supply the control panel, you supply the compute.
- Code / build engineering layers. Sitting above CI to provide a more programmable build pipeline.
There’s something for everyone, but GitHub Actions sits at the heart. It’s the clear ecosystem winner because of all the community actions and integrations. GitHub Actions (and GitLab CI, to a much lesser extent) is chosen because it exists - fully integrated with PRs, notifications and tracking, not because they're best in class. But its moat is thinning due to fundamental problems around speed and debuggability, not to mention all the reliability issues GitHub has been experiencing in 2026.
Switching cost has protected GitHub from migration, but that is eroding by the first category of newer CI tools - drop-in GitHub Actions replacements. These are products like Blacksmith, WarpBuild, Depot and Namespace. They’re all the same pitch, at least to get started: keep your workflows, swap the runner. That's a sign the YAML format has become the standard and the runner has become a commodity. Bare metal (Blacksmith), NVMe caching (Namespace), per-second billing (Depot) - there is some differentiation, but this category is the most crowded.
Pre-2026 this was enough to compete, but now agents are revealing that the bottleneck is not just speed, but debuggability. This is another thing GitHub Actions falls down on, despite the existence of act. The usual approach to creating a new GitHub Actions is push based, then wait to see what GitHub does.
Push-to-CI-just-to-see-if-it-builds, flaky tests blocking pipelines, failed runs that are painful to debug. It's why the interesting features aren't raw speed - they're Buildkite's flake muting and Test Engine, Depot's debuggable instances, Nx's self-healing CI, Dagger and Nx running the same checks locally. With agents writing code, CI latency and flakiness are now agent idle time, and a failed build is consumed by a machine that needs structured context to fix it.
This is why I’m particularly interested in the approach taken by the likes of Buildkite, Dagger, and Nx, because they’re building real “build components”. Programmability and local runners so everything can be managed by the agent. CI needs to move from being a test runner to the final gate, double checking before the code goes to prod, because the agent already ran everything locally.
But this has to be coupled with runners. Blacksmith stands out because of its bare metal cloud - it’s still surprising how much power you can get from real hardware vs virtualized systems - but the modern pattern is a control plane / data plane split: vendors orchestrate, compute runs in the customer's cloud for spot pricing, VPC access, custom hardware, or capex-over-opex. This is WarpBuild (BYOC across AWS/Azure/GCP) and Depot (AWS-only).
Security also has to become a priority. GitHub Actions has many footguns - actions not pinned by default, too permissive permissions, poorly scoped secrets - which have already been exploited in some of the more famous of recent attacks e.g. Shai-Hulud using Actions to spread or the tj-actions/changed-files attack. As agents gain more access, CI security posture will become a buying criterion.
I’m seeing the most noise from the first category of tooling - Blacksmith and Depot seem to be everywhere in the dev community - and are also attracting significant venture funding. Were the likes of Dagger and Nx too early with their programmable build infrastructure? Or are we just at the beginning of the migration away from GitHub Actions after a tipping point of outages throughout 2026?
My bet: the runner vendors are currently winning and will continue to soak up the GitHub refugees, but they don’t solve the fundamental problems. It’s just a bit cheaper and/or faster. The real solution is agent-native CI, and that means the likes of Dagger, Nx, and Buildkite, if they can survive long enough. Or perhaps something new that hasn’t been created yet.