Eight SDKs make pipeline logic ordinary code
Dagger exposes its automation API through 8 SDKs: Go, Python, TypeScript, PHP, Java, .NET, Elixir, and Rust. A pipeline can orchestrate containers, files, secrets, Git repositories, services, and network tunnels with typed functions instead of provider-specific CI steps. The same function runs from a developer machine or a hosted runner, which is useful when teams are tired of debugging one workflow locally and a different one after push.
That model suits substantial delivery systems better than tiny repositories. Types and generated bindings make large workflows navigable in an editor, but they also add concepts that a three-command shell script does not need. Dagger's module catalog and reusable objects can reduce repetition across projects. They create another dependency surface too, so module versions and generated code belong in the same review process as the application.
One Linux container runtime is the portability contract
One Linux container runtime is the base requirement in the README. Dagger runs natively on Linux, while macOS and Windows use Docker Desktop or a similar product. Work executes in containers and operations are keyed by their inputs, allowing unchanged work to reuse content-addressed cache results. That makes local and CI behavior closer, provided both environments expose the same source, secrets, network access, and runtime capabilities.
The engine does not erase environmental differences. A deployment still needs registry credentials and access to its target. Private Git sources need authentication. Host files and sockets must be granted deliberately. Dagger provides typed ways to pass those inputs, but reproducibility still depends on pinning images, declaring files, and controlling network calls. A function that fetches an unpinned remote artifact can drift no matter how tidy its API looks.
What happened when we ran it
Our sandbox installed 743 packages in 102 seconds at commit 3617e2a, then completed the build in 333 seconds. The test command ran for 152 seconds and exited with code 1: 73 tests passed and 5 failed out of 78. The checkout contained 15,610 files, roughly 1,995,447 lines of source, and occupied 173 MB before the installed dependencies.
The supplied failure tail shows several Go packages passing, including version, filesystem, Git, lockfile, and pattern-matching utilities. It ends with only FAIL, without the failed test names or error messages. We therefore cannot say whether the 5 failures came from missing privileges, network access, a regression, or something else. The defensible finding is simple: this commit built, but its available suite did not pass in our fresh 3-CPU, 8 GB unprivileged container.
Cloud Checks trade workflow files for account setup
Cloud Checks can run after each push or pull request without a CI workflow file. The setup command reads the repository from the Git origin, then asks for a Dagger Cloud account, an organization, and GitHub repository access. Once connected, the same Checks run locally through dagger check and on Cloud Engines. That is appealing for teams that want one execution model and are comfortable adding a managed control plane.
Local use remains separate from that service. You can install the CLI, initialize dagger.toml, add recommended modules, change their settings, and run Checks on your own container runtime. The documentation is clear about Cloud Checks being optional. Keep that line visible in an adoption plan: local portability is a product strength, while managed checks introduce an account, repository authorization, and a vendor service into the path.
Secret values stay outside container layers and cache keys
Dagger's current secret guide accepts values from environment variables, files, command output, Vault, 1Password, AWS, Google Cloud, and the Linux Secret Service. The API passes references rather than plain values through a workflow. The documentation says secrets are redacted from logs, excluded from cache keys, and kept out of container layers. Those safeguards are much better than copying a token into an environment-building step.
Provider access still has to be configured on the host or runner. Vault needs its address and an authentication method; AWS and Google Cloud use their normal credential chains; command-backed secrets execute a host command. Review which process can invoke each provider and what the resulting token can do. Redaction protects output, while least-privilege credentials limit the damage if the workflow itself is wrong.
The self-hosting page is still one TODO
The current self-hosting page contains a heading and TODO, even though the main README says Dagger can run on dedicated cloud infrastructure. That documentation gap is a real purchasing problem for an operator deciding how engines are installed, upgraded, isolated, monitored, or recovered. Source code and reference pages can answer pieces of that question, but a platform team should not have to reverse-engineer its production runbook from a 1,995,447-line repository.
Dagger does include 9 CI workflow files, yet our scan found no Dockerfile or top-level tests directory. Those signals do not prove weak engineering, since a project centered on its own engine can build itself differently and tests may sit beside packages. Combined with the failed lab suite, they do argue for a proof of concept that covers engine lifecycle and recovery, not only a successful dagger check demo.
September pushes outweigh the August v0.21.9 tag
Release v0.21.9 was published on August 26, 2026, while the repository was pushed on September 20. GitHub listed 16,275 stars and 202 combined issues and pull requests when fetched. September activity included engine snapshots, remote cache work, workspace behavior, generated bindings, CLI changes, and MCP code. The project is plainly active; the combined open count is workload, not a count of confirmed defects.
Version 0.21.9 fixed session teardown, cache-metadata growth, registry authentication cache reuse, and several filesystem behaviors. Those fixes show attention to the operational seams that matter in a long-running engine. They also show the breadth a buyer inherits. Start with one expensive pipeline, compare local and CI results, and decide whether saved duplication pays for the engine, module, cache, and upgrade work before expanding it across the organization.