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.

Every container operation delegated to BuildKit is being reimplemented natively in Dagger's DAG engine. Internally called 'Project Theseus' — after the Ship of Theseus — the team has spent over a year replacing BuildKit's internals one plank at a time, shipping continuously at every step. The key was a transitional facade layer called DagOp: each operation (git, HTTP, container exec, file and directory operations, exports) was individually lifted out of BuildKit and into Dagger's own engine. Over 50 PRs later, the facade has served its purpose and is being removed. In its place: a caching engine built on e-graphs — a data structure from compiler optimization research that tracks equivalences between operations, maximizing cache hit rates beyond what any conventional build cache can achieve. The new cache has a single, understandable code path for key calculation and lookup. A long-standing caching bug was fixed without anyone investigating it — the scenario that confused BuildKit's two intertwined caching systems is simply handled correctly by a system simple enough to reason about.

As an env variable: export DAGGER_X_RELEASE=<version>

Annotate any function that returns a Service with +up, and dagger up discovers it across your workspace — including services from your dependencies. Port collisions are caught before anything starts, and container health checks gate readiness automatically. No YAML, no separate orchestration layer — just functions in your modules, composed through the same engine that runs your builds and tests.

Traditional Dagger SDKs generate client code from the API schema before your module can run. Dang skips this entirely: it introspects the schema at runtime and makes every Dagger type a native language type. With the new native runtime, Dang modules run directly inside the engine without the usual module loading overhead — no container startup, no process coordination. An entire module with multiple functions and types fits in under a hundred lines.

The old framework (Bubbletea) has been replaced with a new rendering engine built on Tuist, a TUI framework designed for infinite scrollback. Each span in the trace tree is an independent component with its own render cache — only components whose data changed get repainted, using line-level diffs to minimize terminal I/O. The result: a TUI that feels like normal terminal output, but with the rich structure of a trace viewer. Mouse input is no longer captured, so scrolling always works.

Set per-call overrides for max used space, reserved space, minimum free space, and target space.

Great for generated clients, repo scaffolding, and config drift cleanup without stitching together shell scripts.

Checks are supported in Go, Python, and TypeScript, with Java support added in v0.19.11.

Now module developers can explicitly set cache policy per function. With explicit control in place, default caching can improve performance safely.

Together, these APIs make it much easier to resolve origins, enumerate refs, pick stable versions, and compute merge bases without shelling out.

It also made it easier to compose bigger workflows in one place: simple shell pipelines for day-to-day work, code when logic grows, all on the same system.