You already lock your npm packages, Go modules, and Rust crates. But every FROM alpine:latest, every git checkout main is still an unlocked, mutable dependency. A supply chain attack can swap what a tag points to overnight. .dagger/lock pins container image tags, git branches, and HTTP fetches to their resolved values, committed to version control like any other lockfile. Your pipeline either reproduces exactly or fails clearly.
…
Run --lock=live once to record what every lookup resolves to. Use --lock=pinned in CI to reuse pinned entries and resolve any new lookups. Use --lock=frozen for hardened pipelines: anything not already locked is a hard error, not a silent substitution.
dagger --lock=live call build # record resolved values
dagger --lock=pinned call build # reuse pins, resolve new lookups
dagger --lock=frozen call build # lockfile only, fail on miss
dagger lock update # refresh all locked entries
A major upgrade to how modules interact with your project. Modules get a typed API to your workspace, replacing rigid sandbox constraints with dynamic context — less complexity for developers, more control for platform engineers.
…
Today, modules can't see your project structure unless you thread it through manually with custom boilerplate code, wrapper shell scripts, and static path patterns. Modules v2 changes this with a typed Workspace argument that replaces +defaultPath and +ignore pragmas with real code — capable of parsing config files, efficiently traversing directory trees, and adapting to any project layout and scale. A new .dagger/config.toml file declares which modules your project uses and how to configure them, in human-editable TOML. The module author handles the complexity; you just install and configure. A lockfile pins module versions for reproducible resolution across teams.
cloud
Fully managed Dagger engines with auto-scaling and distributed caching. Run dagger --cloud and your pipelines execute in the cloud — with your local context preserved seamlessly. In early access.
…
No Kubernetes daemonsets, no handrolled load balancing, no cache distribution headaches. Compute and cache run in the cloud, but local secrets, service dependencies, configuration, files, and terminal are securely streamed — all available to your pipeline as if it were running on your machine. Run your full integration test suite with the compute and cache of your production CI, against your uncommitted changes, with secrets from your personal vault. We use Cloud Engines in production for our own CI and are onboarding our first customers.
cloud
A complete replacement for your CI platform. Cloud Checks connects to your Git provider and triggers dagger check on every change, auto-scaled on Cloud Engines — no YAML, no vendor syntax, no orchestration layer. In early access.
…
If your CI logic is in Dagger modules, and your CI infrastructure is on Cloud Engines — you don't need a third-party CI platform to glue them together. Cloud Checks processes Git events and runs your checks on managed infrastructure that scales with your team. Just your modules, your checks, and nothing else. We've already unplugged GitHub Actions for our own CI — join our Discord if you want in.
need for speed
Engine connection time is roughly cut in half. Every dagger command pays this cost, so the speedup is felt across the board, especially on remote Docker contexts.
