Custom Module Rendering

Use stackgen.yaml to control how custom Terraform modules render in the StackGen UI.

StackGen used to rely on two separate files, properties.json and metadata.json, for how the product interprets the module and how input fields appear. Those responsibilities are now combined into one YAML file (the product refers to stackgen.yaml / stackgen YAML).

Where it applies

• Building a custom module from an abstract (abstract own modules path).
• Working in the Module Editor path.

In those flows, an action such as Autogenerate stackgen.yaml creates or refreshes the file when the module is new or already populated. The shape of variables in YAML drives how the UI renders inputs (for example boolean values as a dropdown, map types as key/value lists), in line with what you declare.

Quick start

1. In your Terraform module root, create .stackgen/.
2. Add .stackgen/stackgen.yaml (or .stackgen/stackgen.yml).
3. Commit/push module changes.
4. Import/probe the module in StackGen.

What this config controls

• representation: side panel + topology node metadata.
• variables: form rendering metadata for module inputs.
• variable_groups: section layout for config panel.

Schema (v1)

version: string

representation:
  side_panel:
    label: string
    icon: string
  node:
    label:
      static: string
      template: string

variables:
  <variable_name>:
    label: string
    description: string
    ui_control: string
    options: [any, ...]
    value_type: string
    validation: { <key>: any, ... }
    attributes:
      <nested_attr_name>: # same shape as a variable
        label: string
        description: string
        ui_control: string
        options: [any, ...]
        value_type: string
        validation: { <key>: any, ... }
        attributes: {}
        default_editor: string
        variable_label: string
        type: string
    default_editor: string
    variable_label: string
    type: string

variable_groups:
  - label: string
    description: string
    variables: [string, ...]

Field guidance and values

• version

  • Use "1.0".

• variables.<name>.ui_control

  • Stored as string; recommended values:
  • text, password, select, dictionary, textarea, object, hcl, yaml, json, shell, markdown, text_list, textarea_list, dictionary_list, object_list.

• variables.<name>.type

  • Terraform-style type string, for example:
  • string, number, bool, list(string), map(string), object.

• variables.<name>.validation

  • Only required is consumed for schema generation.
  • Nested attributes also support required and maxObjects in generated property validation.

Minimal S3 example

version: "1.0"

representation:
  side_panel:
    label: "S3 Bucket"
    icon: "aws-s3-bucket"
  node:
    label:
      static: "S3 Bucket"
      template: "S3 Bucket - ${bucket_name}"

variables:
  bucket_name:
    label: "Bucket Name"
    description: "Globally unique S3 bucket name."
    type: "string"
    ui_control: "text"
    validation:
      required: true
  sse_algorithm:
    label: "SSE Algorithm"
    description: "Server-side encryption algorithm."
    type: "string"
    ui_control: "select"
    options: ["AES256", "aws:kms"]
  versioning:
    label: "Versioning"
    type: "object"
    attributes:
      enabled:
        label: "Enabled"
        type: "bool"
      mfa_delete:
        label: "MFA Delete"
        type: "bool"

variable_groups:
  - label: "Bucket Configuration"
    description: "Core S3 settings"
    variables: ["bucket_name", "sse_algorithm", "versioning"]

Not supported today

• Relying on stackgen.yaml for Terraform variable defaults (variables.tf remains source of truth).