Deploying with Dagger
Programmable CI/CD engine running pipelines in containers with typed SDKs.
CI/CDAdvanced
Why
Dagger pipelines are typed code (Go/Python/TS) that run in containers — portable, testable, and locally reproducible. DORA's 2024 State of DevOps report shows elite teams deploy 973x more frequently than low performers.
CI/CD pipelines with automated testing reduce change failure rate to 5-15% versus 40-60% for manual deployments.
When
Teams wanting CI pipelines as code that run identically locally and in CI. Avoid complex pipeline orchestration for repos with fewer than 5 contributors — a pre-commit hook + GitHub Actions suffices.
Skip self-hosted runners unless you need GPU or VPN access.
How
# Dagger Go SDK pipeline
package main
import (
"context"
"dagger.io/dagger"
)
func main() {
ctx := context.Background()
client, _ := dagger.Connect(ctx)
defer client.Close()
src := client.Host().Directory(".")
builder := client.Container().
From("node:20").
WithMountedDirectory("/src", src).
WithWorkdir("/src").
WithExec([]string{"npm", "ci"}).
WithExec([]string{"npm", "run", "build"})
builder.Directory("/src/dist").Export(ctx, "./dist")
}
4. Verify deployment — curl -I https://your-app.example.com
5. Monitor logs — check for errors in first 5 minutes
6. Rollback if needed — revert to previous version
Example
# Run Dagger pipeline locally
dagger call build --source=. export --path=./dist
# Run in GitHub Actions
- uses: dagger/dagger-for-github@v6
with:
call: build
args: --source=.
Common Problems
- ⚠Build cache cold — use dagger cache volumes
- ⚠Module not found — run dagger mod init
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Use cache volumes — persist npm/pip caches across runs
- ✓Keep modules small and composable — reuse across projects
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit