Dagger Is Not a CI System Replacement
A common misconception is that adopting Dagger means replacing GitHub Actions, GitLab CI, or Jenkins. It does not. Dagger is a pipeline execution engine, not a CI orchestration platform. You still need a CI system to handle triggers (on push, on pull request, on schedule), secrets management at the platform level, and artifact storage.
The pattern is: your CI system becomes a thin trigger layer, and Dagger becomes the execution layer.
A GitHub Actions workflow migrated to Dagger keeps its usual triggers (push to main, pull requests) but its steps shrink to just checking out the code, setting up a Python runtime, installing the Dagger SDK, and running the pipeline script — with platform secrets passed in as environment variables for that script to consume.
The GitHub Actions file has no build logic. It checks out code, installs the SDK, and calls your pipeline script. All the logic — what to build, how to test, where to push — lives in ci/pipeline.py, which you can run identically on your laptop.
Passing Secrets Safely
Dagger has a first-class Secret type that prevents sensitive values from appearing in logs or being stored in cache layers — wrapping a plaintext environment variable into a secret handle, then attaching that handle to a container as a secret-typed variable rather than a plain one, so it's available to commands running inside the container without ever being written to the pipeline's own logs or cache metadata.
The set_secret() call tells the Dagger Engine to treat this value as sensitive. It is passed to the container as an environment variable but is never written to the cache, never appears in dagger run output, and never shows up in BuildKit layer metadata.