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.