When Pipelines Become Code, Jenkins Becomes a Liability
Jenkins has dominated CI/CD infrastructure for nearly two decades, but its dominance was always built on a fragile foundation: XML-based configurations, brittle plugin ecosystems, and a maintenance overhead that grows faster than the teams managing it. For years, engineering organizations accepted this tradeoff because there was no clean alternative that offered the same flexibility without requiring a full platform rebuild. That calculation is starting to change.
Dagger is positioning its pipeline-as-code layer as that clean alternative – a way to define, run, and reuse CI/CD pipelines in actual programming languages rather than declarative YAML or XML syntax. The idea is straightforward: if your pipeline logic lives in real code, it can be tested, versioned, refactored, and shared like any other software artifact.
That is the wedge Jenkins never had an answer for.
What Dagger Actually Does Differently
The core of Dagger’s architecture is a containerized execution engine built on top of BuildKit, the same layer that powers Docker’s build system. Pipelines are written using Dagger’s SDK – available for Go, Python, TypeScript, and other languages – which means engineers are writing pipeline logic in the same language stack they already use for the rest of their codebase. There is no context switch into a domain-specific configuration language. A backend engineer writing Go does not have to become a Jenkins expert to contribute a pipeline fix.
This matters because Jenkins pipelines have always had a talent problem. Maintaining a Jenkinsfile at any real scale requires specialized knowledge – knowledge of Groovy scripting, of the plugin dependency chain, of which pipeline steps behave differently in declarative versus scripted modes. That knowledge tends to concentrate in a small number of people on a platform team, creating bottlenecks that slow down every other engineering team waiting for pipeline changes. Dagger dissolves that specialization by making pipelines a first-class software problem rather than an infrastructure administration problem.
The portability angle is equally significant. Because Dagger pipelines run inside containers, they execute identically whether the developer is running them on a local laptop, in GitHub Actions, in GitLab CI, or on a self-hosted runner cluster. Jenkins’ architecture was never designed for this kind of portability – its agent model and plugin dependencies create environment-specific behavior that makes “it works on my machine” a real and recurring problem for pipeline debugging.
Why Jenkins Users Are Paying Attention Now
Jenkins’ install base is enormous, and much of it is sticky for the worst possible reason: switching costs. Organizations that have spent years building out Jenkins plugin configurations, shared libraries, and custom Groovy scripting feel locked in not because Jenkins is good, but because migration looks expensive and risky. Dagger’s approach to this problem is to lower the migration floor rather than demand a rip-and-replace decision. Because Dagger pipelines can run inside existing CI environments – including Jenkins itself – teams can adopt Dagger incrementally, running Dagger-defined pipelines as a step within a Jenkinsfile before eventually replacing Jenkins entirely.
This incremental adoption path is a deliberate strategy, and it mirrors how other developer tools have successfully displaced entrenched incumbents. The pattern is consistent: meet users inside their existing workflow, deliver enough value that the new tool becomes load-bearing, then make the old tool feel redundant by comparison. The same displacement logic is playing out in adjacent developer tooling categories, where newer platforms are winning by reducing friction rather than demanding commitment upfront.
The timing also works in Dagger’s favor. Platform engineering has gone from a niche concept to a mainstream priority, and that shift has forced engineering leaders to think more seriously about the total cost of maintaining CI/CD infrastructure. Jenkins is often the most expensive line item in that audit – not in licensing, since Jenkins is open source, but in engineering hours spent on maintenance, debugging, plugin updates, and security patching. When those costs get properly accounted for, the case for staying on Jenkins weakens considerably.
The Competitive Landscape and What Comes Next
Dagger is not the only tool trying to modernize CI/CD pipeline logic. GitHub Actions has pulled significant workloads away from Jenkins by offering a hosted, YAML-based CI layer tightly integrated with the most popular code hosting platform in the industry. CircleCI, Buildkite, and Earthly each address different subsets of the same problem. What separates Dagger from most of these competitors is the explicit bet on code-native pipeline definitions rather than better-designed configuration languages. YAML is still configuration, no matter how well-structured it is. Code is composable, testable, and distributable in ways that YAML fundamentally cannot match.
The company behind Dagger was co-founded by Solomon Hykes, who previously co-founded Docker – a credential that carries real weight in infrastructure circles. The Docker comparison is not just biographical. Docker succeeded by making a complex infrastructure primitive (containerization) accessible to individual developers rather than just platform teams. Dagger is explicitly attempting the same move with pipelines: take something that lived in the infrastructure layer and hand it back to application developers.
Jenkins will not disappear quickly. Its install base is too large, its integrations too numerous, and its community too entrenched for a rapid collapse. But the organizations building new engineering platforms today are not choosing Jenkins – they are choosing GitHub Actions, Dagger, or some combination of both. Jenkins is winning on retention, not acquisition, and that is a position that tends to erode steadily rather than hold. The question for Dagger is whether it can convert enough of that retention base before Jenkins’ own community patches the gaps that make switching feel worth the effort.
