The Pipeline Tool Nobody Talked About Is Now the One Developers Won’t Stop Using
Jenkins has run CI/CD pipelines for over a decade, so long that many engineering teams treat it the way they treat legacy databases – something inherited, tolerated, and quietly resented. Dagger, a pipeline SDK built around containerized execution and a portable-by-design architecture, is now giving those teams a reason to look up. It does not market itself as a Jenkins killer. It does not need to.
What Dagger offers is deceptively simple on paper: write your pipeline once in code, run it anywhere – locally, on GitHub Actions, on CircleCI, on whatever comes next. The actual engineering underneath that promise is what has been pulling senior developers out of Jenkins configurations they have been maintaining since before Kubernetes was a household word. The migration is not always deliberate. Sometimes it starts as a side project. Then it becomes the new standard.
What Dagger Actually Does Differently
Jenkins pipelines live in Jenkinsfiles, which are essentially Groovy scripts that run on a Jenkins server. That architecture made sense when CI was centralized and servers were permanent fixtures. The problem is that the Jenkinsfile is inseparable from Jenkins itself. You cannot run it locally without significant configuration gymnastics, and you cannot port it to another platform without rewriting it from scratch. Every time an engineering team wants to test a pipeline change, they push a commit and wait. That feedback loop is slow, and slow feedback loops compound into hours of wasted engineering time every week.
Dagger sidesteps that entirely. Pipelines are written using its SDK – available in Go, Python, TypeScript, and PHP – and execute inside containers managed by the Dagger Engine. Because everything runs in containers, a pipeline that works on a developer’s laptop works identically in any CI environment. There is no special runner configuration, no environment variable drift, no “it works on CI but not locally” debugging spirals. The container is the contract.
That portability is what gives Dagger its real leverage against Jenkins. Engineering teams are not locked into a specific execution environment. If GitHub Actions raises prices or CircleCI has an outage, the pipeline itself does not need to change – only where it runs. Jenkins cannot offer that. A Jenkins pipeline is, by design, a Jenkins artifact.
The Hidden Cost Jenkins Teams Are Finally Counting
Running Jenkins at any meaningful scale requires infrastructure management that rarely appears in headcount justifications. Someone has to maintain the Jenkins server. Someone has to manage plugins – and Jenkins has hundreds of plugins, many of them community-maintained, some of them years behind on updates. When a plugin breaks a pipeline, that someone has to diagnose it, find a workaround, and file an issue that may or may not get addressed. This is not a hypothetical maintenance burden. It is the standing operational cost of running Jenkins in production.
Dagger does not eliminate CI infrastructure costs, but it concentrates them differently. The SDK is the dependency. Pipelines written in TypeScript or Go can be tested, versioned, and reviewed like any other code. When something breaks, the debugging surface is code, not plugin configuration. For teams already operating in a code-review-driven culture, that shift in where problems live makes them significantly easier to solve.
Why Jenkins Is Harder to Displace Than It Looks
Jenkins has survived this long partly because of sheer installed base. A large portion of enterprise engineering organizations have Jenkins pipelines that have been running, without major incident, for years. The pipelines work. The team knows how they work. Migrating them is a project with real cost, real risk, and an unclear ROI unless something has already broken badly enough to justify the disruption. That friction is what keeps Jenkins installed long after teams have stopped choosing it for new projects.
But that is exactly where Dagger is making its move. It is not asking teams to migrate. It is positioning itself as the tool for new pipelines, greenfield projects, and the CI setup for teams that have never run Jenkins at all. The fastest-growing segment of software teams – startups, scale-ups, and the internal platform teams inside larger organizations – are all making their initial CI choices right now. Jenkins is rarely winning those decisions. The tools that are winning often integrate with or are informed by what Dagger is building.
There is also a generational dynamic at play. Developers who started their careers after containers became standard do not have the same relationship with Jenkins that senior engineers do. To them, Jenkins looks like a server that requires a manual. Dagger looks like a library. Those two framings lead to very different adoption curves, and the developers making tool recommendations in 2025 are increasingly from the first group.
The tension Dagger has not fully resolved is enterprise adoption. Large organizations with compliance requirements, auditing needs, and dedicated platform teams have built significant process around Jenkins. Those processes are not just technical – they are organizational. Change management at that scale is slow by design, and Dagger’s relatively young ecosystem means it lacks some of the enterprise-specific integrations that Jenkins has accumulated over a decade. That gap is closing, but it is not closed. The teams most eager to adopt Dagger are often not the teams with the authority to mandate it, and the teams with that authority are often the most conservative about swapping foundational infrastructure. That mismatch is the actual obstacle – not the technology.
