Overview
Introduction
outputs.tf tends to be an afterthought, added one output at a time as something downstream (a CI pipeline, another module, a teammate) needs a value exposed, which is exactly how output blocks end up inconsistently formatted across a codebase.
This tool generates a clean outputs.tf from repeatable rows, keeping the name, value expression, description, and sensitivity formatting consistent across every output.
What Is Terraform Outputs Generator?
An outputs.tf generator that turns a list of output rows, name, value expression, description, sensitive flag, into properly formatted `output "name" { }` blocks.
Each row becomes one output block in the order you added it, with the `sensitive` line only appearing for outputs you've toggled on.
How Terraform Outputs Generator Works
For each row, you provide an output name, the HCL expression Terraform should evaluate (usually a resource or module attribute reference), an optional description, and whether the output is sensitive.
The tool validates that names are unique and syntactically valid Terraform identifiers, that every output has a non-empty value expression, then renders each as a standard output block.
When To Use Terraform Outputs Generator
Use it when finishing a module and you need to expose several resource attributes as outputs at once, consistently formatted.
It's also useful when a downstream consumer (a CI script, another Terraform module, a teammate) asks for a specific value to be exposed and you want to add it without breaking the file's existing formatting conventions.
Often used alongside Terraform Config Generator, Terraform Variables Generator and Terraform Module Generator.
Features
Advantages
- Keeps output formatting consistent across a file with many outputs, no more mixed styles from being added at different times.
- Only emits the `sensitive` line for outputs that need it, keeping non-sensitive outputs clean.
- Catches duplicate output names and missing value expressions before you paste the result anywhere.
Limitations
- Doesn't validate that the value expression you typed actually resolves against real resources in your configuration, that's still Terraform's job at plan time.
- Doesn't support Terraform's `depends_on` argument on outputs, which is rare but occasionally needed for explicit ordering.
Examples
Best Practices & Notes
Best Practices
- Write a description for every output; it's the primary way callers of a module discover what values are available without reading main.tf.
- Mark outputs sensitive whenever the underlying resource attribute is a secret, password, or private key, not just when policy explicitly requires it.
- Prefer exposing specific attributes (`.arn`, `.id`, `.public_ip`) over exposing an entire resource object as one output, since specific attributes give callers a stable, minimal interface.
Developer Notes
Output name uniqueness and identifier validity are checked before rendering, matching Terraform's own requirement that output names be unique within a module and follow standard HCL identifier rules (letters, digits, underscores, starting with a letter or underscore); the `sensitive` line is conditionally rendered rather than always present, since explicitly writing `sensitive = false` is redundant and most real-world outputs.tf files omit it entirely for non-sensitive outputs.
Terraform Outputs Generator Use Cases
- Finishing a module by exposing all the resource attributes downstream consumers need
- Standardizing outputs.tf formatting across a team's collection of modules
- Adding a newly requested output without disrupting an existing file's structure
Common Mistakes
- Typing a literal string instead of a resource attribute reference in the value field, producing an output that's always the same static text.
- Forgetting to mark a credential-bearing output sensitive, leaking it into terraform apply's console output and CI logs.
Tips
- Use the Terraform Variables Generator alongside this one so a module's variables.tf and outputs.tf stay consistently formatted.