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.

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.

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.

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.

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. Its lightweight Go-based interpreter is designed to be embeddable directly in the engine — eliminating process overhead altogether. An entire module with multiple functions and types fits in under a hundred lines. Dang is already usable as a third-party SDK and is actively used in production.

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.

The old framework (Bubbletea) has been replaced with a new rendering engine built specifically for Dagger. 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.