Tool

Terraform Module Scaffolder

Form-driven inputs that generate a ready-to-edit Terraform module skeleton.

Back to tools

Module inputs

Module name

Terraform version constraint

Module description

Providers

One per line. Format: name:source:version or name:version.

Variables

One per line. Use name:type:description:default (colon or pipe separator).

Outputs

One per line. Use name:description:value (value defaults to var.name).

Include outputs.tf

Include README.md

Include examples/basic

Generated files

main.tf

Core module resources.

# my-module
# Reusable Terraform module.

# Add your resources here.
# Keep providers configured in the root module, not inside this module.

variables.tf

Module inputs.

variable "environment" {
  type        = string
  description = "Deployment environment"
  default     = "dev"
}

variable "region" {
  type        = string
  description = "AWS region"
  default     = "us-east-1"
}

versions.tf

Terraform requirements.

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
    version = "~> 5.0"
    }
  }
}

locals.tf

Local values for reuse.

locals {
  module_name = "my-module"
  tags = {
    ManagedBy = "Terraform"
  }
}

providers.tf

Provider alias placeholders.

# Provider configurations should live in the root module.
# Use this file only for provider aliases if the module requires them.
# provider "aws" {
#   alias = "aws"
# }

outputs.tf

Module outputs.

output "module_id" {
  description = "Unique identifier"
  value       = var.environment
}

README.md

Module README.

# my-module

Reusable Terraform module.

## Usage
```hcl
module "my-module" {
  source = "../my-module"
  environment = ""
  region = ""
}
```

<!-- BEGIN_TF_DOCS -->

## Requirements
- Terraform >= 1.6.0

## Providers
| Name | Source | Version |
|------|--------|---------|
| aws | hashicorp/aws | ~> 5.0 |

## Inputs
| Name | Description | Type | Default | Required |
|------|-------------|------|---------|:--------:|
| environment | Deployment environment | string | "dev" | no |
| region | AWS region | string | "us-east-1" | no |

## Outputs
| Name | Description |
|------|-------------|
| module_id | Unique identifier |

<!-- END_TF_DOCS -->

## Notes
- Run `terraform fmt` after edits.
- Use `terraform-docs` to keep the README tables up to date.

Was this tool helpful?

About the Terraform Module Scaffolder

A Terraform module is a directory with a conventional shape rather than anything special: resources in one file, inputs in another, outputs in a third. The convention matters because it is what makes a module readable to someone who did not write it — they know where to look for the interface without reading the implementation.

The interface is the part worth thinking about. Every variable should have a type and a description, and defaults belong only on genuinely optional inputs. A variable with a default that callers are expected to override is a trap, because forgetting to set it produces a silently wrong resource rather than an error.

Outputs are how modules compose, and they are usually too sparse. If a caller has to construct an ARN by string concatenation, or reach into a resource the module owns, the module has not exposed enough. Output the identifiers other configurations will genuinely need, and keep them stable — an output rename is a breaking change to every consumer.

Frequently asked questions

Should every variable have a default?

No. Defaults belong on inputs that are genuinely optional. A required input with a default fails silently when someone forgets to set it, creating a resource with the wrong configuration instead of an error at plan time. Omitting the default makes Terraform demand a value, which is exactly what you want for anything that must be decided deliberately.

Where do provider configurations belong?

In the root module, not in child modules. A module that configures its own provider cannot be used more than once with different settings — for example in two regions — and produces confusing errors when composed. Declare required providers and their version constraints in the module; configure them at the root.

How should I version and publish a module?

Tag releases and have consumers pin to a version constraint rather than a branch. Consuming a branch means an upstream change alters someone else's plan with no action on their part, which is how a routine apply becomes an incident. Semantic versioning with a changelog is enough; the registry is optional.

How granular should modules be?

Coarse enough to be worth calling. A module wrapping a single resource with no added logic is indirection without benefit — callers can use the resource directly. Modules earn their existence when they encode a decision: naming, tagging, sensible defaults, or several resources that must be configured consistently together.

Should I use count or for_each?

for_each in nearly all cases. count indexes by position, so removing an item from the middle of a list shifts every subsequent resource's address and Terraform plans to destroy and recreate them. for_each keys by a stable identifier, so removing one item affects only that resource — which is the difference between a safe change and a surprise.

Need this managed for you, not just automated?

We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.

Explore Our Services