Argy
Request a demo

Consuming Modules

How developers use Argy modules (golden paths) via the portal/CLI to provision, deploy, and operate with guardrails.

In Argy, developers don’t “ask the platform team to do things”. They consume capabilities through a governed self‑service.

Those capabilities are delivered as versioned modules (golden paths): a clear configuration interface, templates (IaC/CI), policies/guardrails, docs, and operational baselines.

What you typically do as a developer

1) Pick a golden path (module)

Start from the module catalog and choose the path that matches your workload (e.g. secure microservice, data pipeline, ephemeral env).

When in doubt, prefer the path recommended by the platform team: it’s the one that is supported, observed, and compliant by design.

2) Configure it (schema-driven)

Modules expose a typed configuration schema. This is intentional:

  • it makes requirements explicit,
  • it reduces tribal knowledge,
  • it prevents “snowflake” setups.

In practice you provide parameters (runtime, region, size, SLO target, etc.) and Argy generates the underlying workflows.

3) Apply per environment

Most products have multiple environments (DEV/STG/PRD). With Argy, you can:

  • reuse the same golden path,
  • change only the parameters that differ,
  • keep policies consistent across environments.

4) Ship through the portal/CLI

Use the portal when you want visibility and guided flows. Use the CLI when you want automation (CI/CD, scripts) or when the terminal is your default UX.

The key idea: the platform team controls the path, developers control parameters.

5) Observe and operate (run automation)

Argy encourages a “run‑aware” delivery:

  • observability baselines (dashboards/alerts),
  • runbooks embedded with the module,
  • ownership signals (who owns what),
  • governance evidence (who changed what, when).

See: Run & Operations.

When you need changes

If the golden path is missing something, avoid forking it per team. Prefer:

  1. raising a request to the platform team,
  2. adding an extension point,
  3. releasing a new module version.

That way, improvements are shared and adoption doesn’t fragment.

Next steps