Two concepts in Aiden for InfraOps look similar enough to confuse, and the confusion is expensive. Modules and appStacks are not two flavors of the same thing. They serve different people for different reasons.
Part 3 of 6 in the Aiden for InfraOps series. Start with the series overview »
The short version
If you only take one idea from how Aiden for InfraOps is designed, make it this one: there are two distinct objects, and they exist for two distinct people. A Module is the reusable building block. An appStack is the deployable application someone assembles from those blocks. Blur the line and you get a platform that frustrates both audiences. Hold the line and you get the producer-consumer model that makes everything else work.
The cleanest way to feel the difference is the Lego analogy, so let's start there and then get concrete.
A Module is a Lego block. A single brick, a wheel, a flat four-by-two. It's standardized, it's reusable, and on its own it isn't anything you'd hand a kid and call a present. Its whole purpose is to be combined with other blocks into something larger.
An appStack is the actual toy: the race car, the spaceship, the castle. It's what you build by assembling the blocks. It's specific, it's complete, and it's the thing that has a reason to exist on its own.
That mental image does a lot of work, because it immediately tells you who handles which object. You don't hand a toddler a vat of raw plastic and a mold. You hand them blocks designed so the only things they can build are safe and structurally sound. Same idea here. The platform team produces the blocks. Developers build the toys.
A Module is the primary concern of the DevOps or platform engineering persona, the power user who is trusted with the details.
Its purpose is to capture a reusable infrastructure pattern that encodes the organization's rules, security policies, and best practices. "An S3 bucket must have versioning enabled and these specific IAM roles attached" is exactly the kind of decision a Module exists to make once and enforce everywhere. The hard-won knowledge lives inside the block instead of in someone's head or a wiki nobody reads.
It is stateless. A Module doesn't exist in the cloud on its own and isn't tied to any particular deployment. It's a definition, a pattern, a template for a piece of infrastructure rather than a running instance of it. That's what makes it reusable across dozens of applications without dragging any one deployment along with it.
It is heavily variabilized. Good Modules expose their attributes as variables and actively avoid hardcoded values. Hardcoding is the enemy of reuse: the moment a region or a name or a size is baked in, the block only fits one situation. Variabilizing it means the same Module works across many contexts.
It is edited as code. This persona requires the utmost control, so Modules are authored as code, with the freedom and fine-grained detail that implies. This happens in the Module Editor. (More on the Module Editor.)
One subtlety worth flagging: a Module can be composed of other, smaller Modules. But that composition is still done in code, inside the Module Editor, not by dragging things around on a canvas. Composition is a producer activity. It belongs with the blocks, not with the toy.
An appStack is the instantiation of infrastructure. It represents a specific application or microservice: this service's compute, this storage, this networking, wired together into a deployable blueprint. It's the primary interface for the developer persona, the people who are not infrastructure experts and, frankly, shouldn't be trusted with low-level configuration.
That last point isn't a slight. It's a design principle. Most developers don't want to become Terraform experts to ship a feature, and the organization doesn't want them to have to. An appStack is a template builder for a specific microservice, assembled from the pre-approved Modules the platform team published.
It has state. Unlike a Module, an appStack is very tightly linked to its deployment in the cloud. An appStack definition that hasn't been deployed is, bluntly, useless. The whole point of it is to become real infrastructure.
Its variables must be resolved. Where a Module deliberately leaves things open as variables, an appStack has to nail everything down. Every variable must be resolved before an appStack can be created or deployed, because at this layer you're describing one specific, runnable thing, not a reusable pattern.
It is built in the UI. The appStack experience is primarily driven by the topology canvas, and that is a deliberate choice rather than a limitation. Developers aren't trusted to write arbitrary, potentially non-compliant code, so the platform doesn't ask them to. Instead they assemble pre-approved Modules visually, and the guardrails are enforced by the medium itself. (More on the appStack canvas.) A developer building an appStack on the canvas is composing infrastructure without ever being handed a blank text file, and that constraint is the feature.
Here's the design decision that ties this to everything else we build: keeping Modules and appStacks as separate objects is what makes guardrailed self-service possible at all. In Aiden for InfraOps, the Module is the unit the platform team controls and the appStack is the unit the developer composes, and that boundary between creating infrastructure and consuming it is what lets a developer move fast without being able to do real damage.
Collapse the two and the model breaks in predictable ways. If developers edit Modules directly, your carefully hardened blocks drift and the guarantees evaporate. If platform engineers are forced to express reusable patterns through the appStack canvas instead of as code, they lose the control and precision their job requires. The objects are separate because the jobs are separate.
This is the same separation-of-concerns idea that shows up across the platform. It's what lets two platform engineers support a large organization, because they're producing blocks once instead of fielding requests one at a time (The Force Multiplier). And it's the practical mechanism underneath both platform team archetypes, whether you want full developer self-service or just faster, safer ticket resolution (Enablers vs. Accelerators).
Because there are two objects, there are two places you work, and it helps to keep them straight.
The Module Editor is where you build Modules. It's a code-first environment for the power user who needs control, and it's where Module composition happens.
The appStack topology canvas is where you use Modules to build infrastructure. It's a visual environment for the consumer who needs guardrails, not a code editor.
A common mistake is expecting one surface to do both jobs, then being frustrated when it doesn't. The canvas isn't a worse code editor; it's a different tool for a different person. We get into why the editor deliberately stays a focused tool rather than trying to become a full IDE in Why Your Module Catalog Isn't an IDE.
If you're a platform engineer adopting Aiden for InfraOps, your real work is in the Module layer. The quality of your developers' experience is decided by how good your blocks are, not by how slick the canvas looks. Vague, over-exposed, hardcoded Modules produce a miserable building experience no matter what's on top of them. (We go deep on authoring good Modules in Authoring Modules for Developers, Not for DevOps.)
If you're a developer, the appStack canvas is your home, and the constraint that you can only assemble approved blocks is doing you a favor. It means the infrastructure you ship is compliant and sound by construction, not by your remembering forty rules you were never told.
And if you're evaluating the platform, the question to ask isn't "can it generate infrastructure code." It's "does it cleanly separate the people who build infrastructure from the people who consume it." That separation, expressed as Modules and appStacks, is the idea everything else rests on.
← Previous — Part 2: The Force Multiplier: How Two Engineers Support a Thousand Developers
Next — Part 4: Why Your Module Catalog Isn't an IDE (and Shouldn't Be) →
See all six parts in the series overview »