Building Modules

How platform teams package schema + templates + guardrails + docs into versioned modules (golden paths).

This page describes the mental model of authoring modules in Argy.

The goal isn’t to hide tools. It’s to orchestrate them into a coherent, versioned product interface.

A module is more than IaC

An Argy module should be treated like a product capability:

  1. Interface: a configuration schema (typed parameters).
  2. Implementation: templates (IaC, CI/CD workflows, scripts).
  3. Guardrails: policies, validations, approval workflows.
  4. Documentation: what it does, how to use it, ownership.
  5. Run: runbooks + observability baselines.

If you only ship IaC, you ship complexity. If you ship the whole module, you ship a golden path.

1) Design the schema first

Write the schema as a contract:

  • keep it minimal,
  • make defaults safe,
  • express constraints (enums, ranges).

2) Keep templates boring

Prefer proven tools (Terraform/OpenTofu, Kubernetes, your CI/CD) and keep templates readable.

3) Put governance where it belongs

Policies should be evaluated in the flow, not after the fact.

See: Policies & Guardrails.

4) Version with intent

Treat modules as versioned products:

  • ship improvements without breaking existing consumers,
  • document breaking changes,
  • provide migration paths.

See: Versioning & Lifecycle.

Next steps