Terraform Module Version Pinning Advisor

The Terraform Module Version Pinning Advisor helps you choose a safe version constraint for every module you depend on. In Terraform, a module block can declare a version argument that controls which releases Terraform is allowed to select during init. Pinning that constraint correctly is one of the cheapest, highest-impact supply-chain and reproducibility controls available to an infrastructure team. An unpinned module can suddenly pull a new major version that renames arguments, deletes resources, or changes defaults, turning a routine terraform apply into an unexpected teardown. A pessimistic constraint such as ~> 3.14 lets you receive compatible minor and patch updates while still blocking breaking major changes. An exact pin such as 3.14.0 is maximally reproducible and is ideal for regulated production environments, but it also means you miss security fixes until you manually bump it. This advisor evaluates the constraint you provide, classifies it by risk, and explains the trade-off in plain language so you can make an informed decision. It never contacts the registry, never uploads your configuration, and never rewrites your files. Everything is computed locally in your browser the moment you click Advise pin. Whether you manage a single root module or hundreds of modules across many environments, a disciplined pinning policy keeps planned changes predictable and boring, which is exactly what good infrastructure as code should be.

• No version declared - rated HIGH because an unconstrained module can resolve to any published release, including a future major that breaks your configuration.
• Exact pin - rated MEDIUM: an exact version such as 3.14.0 is fully reproducible yet rigid, so you must bump it by hand to receive patches.
• Pessimistic ~> - rated LOW and recommended: ~> 3.14 admits 3.14.x and 3.x but never 4.0, balancing freshness with safety.
• Open >= or > - rated MEDIUM: these float upward and may silently adopt a breaking major version on the next init.
• Upper bound <= or < - rated LOW: useful only when combined with a lower bound so installs stay reproducible.
• Exclusion != - rated MEDIUM: excluding a single release is fragile for modules; prefer a concrete pin.
• Severity tags - each result is labelled HIGH, MEDIUM or LOW so you can triage quickly.
• Plain-language reasoning - the advisor explains the trade-off, not just the verdict.
• Source pairing - the constraint is shown next to the module source you enter for context.
• Exportable - copy or download the advice to paste into a pull request or runbook.

1. Open the form and locate the Module source field for the module you want to evaluate.
2. Enter the module source exactly as it appears in your configuration, for example terraform-aws-modules/vpc/aws. This is optional but adds useful context.
3. Enter the version constraint from your module block, such as ~> 3.14, 3.14.0, >= 3.0, or leave it blank to test the unpinned case.
4. Click Advise pin to run the local analysis. No network request is made at any point.
5. Read the severity-tagged findings. A HIGH means you must pin, a MEDIUM means reconsider the strategy, and a LOW means you are following best practice.
6. Review the explanation for each finding to understand the risk and the recommended alternative constraint.
7. Apply the suggested pin to your configuration, then re-run the advisor to confirm the severity drops to LOW.
8. Export the advice with Copy or Download for your change request or team wiki.

Example 1 - Pessimistic pin. Entering ~> 3.14 for the VPC module returns a LOW finding because it accepts safe minor and patch updates while blocking major breaks.

Example 2 - Unpinned. Leaving the version blank returns a HIGH finding urging you to pin, because Terraform could resolve any release.

Example 3 - Open range. Entering >= 3.0 returns a MEDIUM finding warning that a future major may be pulled in automatically on init.

Example 4 - Exact pin. Entering 3.14.0 returns a MEDIUM finding noting strong reproducibility at the cost of less flexibility.

• Safer supply chain - catch floating constraints before they break a plan.
• Reproducible builds - exact and pessimistic pins keep init deterministic across machines.
• Faster reviews - severity tags let reviewers triage module risk at a glance.
• Clear guidance - explanations teach the versioning trade-offs to the whole team.
• Private - nothing leaves the browser, so secrets in sources stay local.
• Portable - copy or download the advice into any runbook or ticket.