Dagger: Programmable CI Engine for Any Codebase

What Dagger is

Dagger is an Apache-2.0 licensed platform, written in Go, for automating software delivery. Its README describes it as a way to build, test and ship any codebase, reliably and at scale, running locally, in a CI server, or directly in the cloud. The current documentation frames it more pointedly as "third-generation CI, after Jenkins and GitHub Actions", built to match the speed and scale of coding agents and to give them the guardrails and context they need.

The problem it targets is the usual state of delivery automation: a pile of shell scripts plus vendor-specific YAML that only really runs on the CI provider. The README is blunt that shell scripts and proprietary YAML "are no longer acceptable" for this job. Dagger replaces them with code and typed modules, and runs every code change, whether machine-generated or handwritten, through the same build and test pipelines before or after push. Once a task is automated with Dagger, the project says it runs the same way on a laptop, an AI sandbox, a CI server or dedicated cloud infrastructure.

It is aimed at platform and application teams who want CI logic they can run and debug locally, and at teams letting coding agents open changes that need to pass the same gates as human ones.

How it works

At the centre is the Dagger Engine. The docs call Dagger vertically integrated: the sandbox, scheduler, container runtime, build cache and tracing share one execution and data model. The only host dependency is a Linux container runtime. Dagger runs natively on Linux, and through Docker Desktop or similar products on macOS and Windows.

Work is organised into modules. When you initialise a project, Dagger detects your toolchains and recommends official modules for them, or you write your own. Modules read your native configuration (a .golangci.yml, a Prettier setup, a Go module) instead of a separate pipeline file, and discover the project as typed artifacts: source code, containers, binaries, generated files and individual tests. Workspace settings live in a dagger.toml file committed to the repository alongside a dagger.lock.

Artifacts are computed lazily as an incremental DAG of sandboxed functions, either on your machine or on a shared remote engine. Every operation is keyed by its inputs, so changing one file only re-runs the affected operations, and caching is content-addressed across local runs and CI.

On top of this sit three everyday verbs: dagger check, dagger generate and dagger start. The docs describe them as conveniences over the underlying primitive, calling a module's functions, which you can also do directly with dagger api call and chain into pipelines. Functions that discover units of a project, such as Go packages or test files, return collections that share the same keys, list, get, subset and batch functions.

Key features

• System API: a cross-language API for orchestrating containers, filesystems, secrets, git repositories and network tunnels, with every operation typed and composable.
• SDKs in 8 languages: Go, Python, TypeScript, PHP, Java, .NET, Elixir and Rust, each generated from the API schema for type safety and editor support.
• Typed artifacts: custom object types with encapsulated state that can be passed across SDK language and module boundaries without serialization.
• Incremental execution: content-addressed caching that works automatically across local and CI runs, with advanced cache control.
• Checks and generators: checks run in parallel and exit non-zero on failure; each generator returns a changeset whose stale check passes only when generated files are up to date.
• Fine-grained selection: filter checks by module, name, collection key or dag:// link, for example a single Go test in one package.
• Built-in tracing: every operation emits OpenTelemetry spans, shown in a live terminal UI or exported to Jaeger, Honeycomb or any OTel-compatible backend.
• Interactive tooling: an interactive REPL and Dagger Shell for exploring modules and intermediate results.

Getting started

The README's install command for macOS is Homebrew:

brew install dagger/tap/dagger

The docs also provide version-pinned install scripts for macOS, Linux and Windows; afterwards dagger version confirms the installed release. The "Try Dagger" guide then walks through an example project:

git clone --depth 1 https://github.com/dagger/hello-dagger.git
cd hello-dagger
dagger module install dagger.io/js/prettier
dagger check

The check fails on unformatted files. Running the module's formatter applies the fix, and a second dagger check passes:

dagger api call -y prettier project --path=. format

For your own repository, the quickstart starts from the project root:

dagger init
dagger module recommend
dagger check -l
dagger check

In CI the docs show a single GitHub Actions step, - run: dagger check, because the pipeline logic lives in the modules rather than in the workflow file.

Use cases

• Replacing CI YAML: move lint, test and build steps into modules so the same dagger check runs on a laptop and in CI with identical results.
• Gating agent-written code: put coding-agent changes through the same checks as human changes, before or after push.
• Targeted test runs in large repos: select one package or test with flags such as --go-package=store instead of running everything.
• Keeping generated code honest: generator staleness checks fail when someone forgets to re-run code generation.
• Self-hosted CI engines: run engines on Kubernetes with the official Helm chart and point existing CI runners at them through the DAGGER_ENGINE variable.

How it compares

The docs position Dagger against Jenkins and GitHub Actions, which they call first- and second-generation CI. In practice it does not have to replace those platforms outright: the self-hosting guide describes a setup where a GitHub Actions or GitLab CI job simply runs dagger check and connects to a team-operated engine, so the CI provider becomes a trigger while the build logic stays portable. Compared with Makefiles and shell scripts, the difference is containerised, typed and cached execution with tracing, at the cost of requiring a container runtime and learning the module model. Dagger's own hosted product, Dagger Cloud, adds Cloud Checks triggered by Git events and Cloud Engines; the docs say checks on Cloud Engines are usually faster because Dagger Cloud assigns work using engine telemetry.

Things to know before adopting

• Licence and hosted split: the engine and CLI are Apache-2.0. Cloud Checks and Cloud Engines are part of Dagger Cloud, need an account and, for Cloud Checks, a GitHub repository.
• Pre-1.0: the latest release is v0.21.11 (October 21, 2026). The quickstart includes a dagger workspace migrate path for legacy workspaces, so expect configuration changes between minor versions.
• Cache-centric scaling: the self-hosting guide warns against running engines on pools of ephemeral machines because each new machine starts with an empty cache; give engines persistent disks and scale up before scaling out.
• Engine security: a tcp:// engine address has no authentication, and any system that can reach the port can run containers on the engine. Keep it on a private network.
• Version pinning: install the CLI in CI at the same version as the engine.
• Telemetry: the v0.20 FAQ states the CLI sends anonymized telemetry to dagger.io by default (version, platform, command run and an anonymous device ID); setting DO_NOT_TRACK=1 disables it.

Project activity

As of October 2026 the repository has about 16,500 stars and 940 forks. It was created in November 2019, is written in Go and is licensed under Apache-2.0. Releases are tagged for the engine and each SDK together; v0.21.11 shipped on October 21, 2026 alongside matching TypeScript and Rust SDK tags. Source is at github.com/dagger/dagger and documentation at docs.dagger.io.