From Clay to Legos | Dagger | Page 1

mild oyster Jan 7, 2026, 11:11 AM

#

I’ve been thinking about why Dagger feels like "Clay" to so many, and I think it comes down to a missing architectural layer: The Module-as-an-Interface.

Right now, Dagger is the "Inversion of Docker"—an incredible, imperative engine. But because it’s "just programming," we are all molding clay in our own silos. To move to a Lego System, we need to define the "studs"—the Standard Interfaces that allow for a true handover between DevOps and Developers.

Imagine this Handover:

The DevOps Engineer defines an interface (e.g., interface.Builder). This interface dictates the Usage, not the implementation. It says: "To ship your app on this platform, you must provide a module that has a .Build() and a .Scan() function."

The App Developer provides a Pluggable Module (the implementation) that satisfies that interface. Whether they write it in Go, Python, or Rust doesn't matter, as long as it "snaps" into the DevOps interface.

If we make Modules Pluginable via Interfaces, we solve the two biggest barriers to adoption:

Vendor Lock-in: I can swap a "Generic Go Build" for an "Optimized to my app Go Build" without touching any pipeline logic.

Cognitive Overload: Developers don't have to "learn Dagger" from a blank page; they just have to "implement the interface" required by their platform team. The platform team builds or uses pre-built community shared interfaces, the dev team offers the implementation to plug into the interface.

Right now, the Daggerverse is a collection of amazing, disparate tools. But without these "Standard Studs," it's just a pile of beautiful clay with different colors. We need a Standard Library of Interfaces so we can stop molding and start snapping.

🙂

#

From Clay to Legos

#

Dagger's GraphQL heart is what makes it a 'System' rather than a 'Tool.' It allows my Go-based governance (DevOps) layer to discover and run TypeScript-based (developer) logic without them ever having to see each other's source code. That is the Plug-and-Play reality the industry has been waiting for and the paradigm shift Dagger has to explain quickly and clearly to entice new users. 🙂

lament bison Jan 7, 2026, 11:33 AM

#

Plug-and-Play

I like that phrase a lot, Dagger is a plug-and-play system of language-agnostic components.

#

It's not just about writing in your language.

it's the fact that if I wander the daggerverse going:
"gee, I wonder if anyone's written a good module for interacting with foo?"

I don't end up going
"Oh this is a good one... popular, well maintained... and in the wrong language damn it."

I just have to find the best one, who care's what language!

white junco Jan 7, 2026, 1:38 PM

#

"Plug-and-play" is similar to "Portable" which is another term I like and associate with dagger.

mild oyster Jan 7, 2026, 2:25 PM

#

This is what we are attempting to build.

#

The above is the CI module development "mode" if you will.

mild oyster Jan 7, 2026, 2:48 PM

#

So, the ci-engine is our "interface". It allows for:

Dev development of their own modules via m8a ci run, without direct access to Dagger.
The CI processes to run, via webhooks from Github (or any other webhook generating API).

The ci-engine is the one and the same binary in both cases. Dagger is the true Engine. 🙂

#

It's all very POC like currently, but it's the goal we're setting.

#

The top image is built and being tested by devs developíng modules. The bottom image is also built, but we haven't gotten dev developed modules to run yet. Only rough tests to show we can listen for the webhooks and also get feedback back into Github via the Checks API, along with running test runs in Dagger via Temporal.

#From Clay to Legos