Terraform versions.tf Generator

The versions.tf file is where a Terraform configuration declares the Terraform version it expects and the providers it depends on. Pinning these versions keeps plans reproducible across machines and CI runners, and it stops surprise upgrades from silently changing behaviour between a laptop and production. The Terraform versions.tf Generator writes this file from a simple form, so you get a correct terraform block without hand-writing source addresses, version constraints or the exact attribute ordering that terraform fmt expects.

You set an optional required_version constraint and add one or more required_providers entries, each with a local name, a source such as hashicorp/aws, and an optional version constraint. The tool validates names and sources before producing output, so a typo in a source address is caught locally instead of during terraform init. Everything runs locally in your browser; nothing is uploaded and no cloud connection is made.

The result is a clean, formatted versions.tf you can commit alongside your other files. Because the output matches terraform fmt, it needs no extra cleanup, and because the required_providers map is explicit, terraform init always resolves the same plugins. This prevents the frustrating "provider not found" and surprise-upgrade classes of bugs, and one-pass generation keeps a consistent style that makes reviews faster for new engineers.

• required_version - set an optional constraint such as >= 1.5.0 to pin the Terraform CLI version used by every teammate and CI runner.
• required_providers block - declare each provider with its local name and its source address in a single, readable map.
• Source addresses - enter hashicorp/aws, hashicorp/google, hashicorp/azurerm or any custom namespace registered in your private registry.
• Version constraints - attach an optional version pin to every provider entry, using exact, pessimistic (~>) or inequality syntax.
• Multiple providers - add as many rows as your module needs in a single pass, keeping the file consistent.
• Validation - provider names and sources are checked, and missing sources are flagged before any output is produced.
• No required_version needed - produce a providers-only file when you just want to pin plugins without constraining the CLI.
• Consistent output - attributes are ordered the same way for every generated file, which reviewers learn to scan quickly.
• Formatter friendly - the block matches terraform fmt so committed files stay clean and pre-commit hooks stay quiet.
• Live stats - a stat badge shows how many providers were emitted so you can confirm nothing was dropped.
• Copy and download - export versions.tf as text, a file or printed output in one click.

1. Set required_version - optionally type a constraint such as >= 1.5.0 to pin the CLI, or leave it blank for a providers-only file.
2. Add providers - click "Add provider" once for each provider your module depends on, such as aws and random.
3. Fill each row - type the local name, the source address and an optional version constraint for every provider.
4. Generate the file - press "Generate HCL" to validate names and sources before output.
5. Review the preview - read the HCL to confirm the terraform block and required_providers map are correct.
6. Export it - Copy, Download or Print the finished versions.tf from the actions row.
7. Commit the result - drop the file into your configuration so every clone inherits the same pins and the same provider resolution.
8. Re-run on change - whenever a provider bumps a major version, regenerate so the policy stays current.

Example - AWS only. required_version ">= 1.5.0" plus a provider aws with source "hashicorp/aws" and version "~> 5.0" yields a terraform block with both settings resolved correctly.

Example - multi-provider. Adding aws and random rows produces a required_providers map covering both, which is useful for modules that span services.

Example - providers only. Leaving required_version blank generates a terraform block that declares providers but imposes no CLI pin, ideal for reusable modules published to a registry.

Example - custom source. A private registry provider such as myco/vpc with its source emits a correct required_providers entry for internal tooling without touching public providers.

Example - strict pin. A provider entry with version "= 4.10.0" shows how exact pins are emitted verbatim for regulated environments.

• Reproducible builds - identical provider versions on every machine and in CI, removing "works on my laptop" drift.
• Fewer init errors - validated sources avoid "provider not found" failures during terraform init.
• Flexible - any provider source and any number of providers are supported.
• Private - everything runs in the browser with no upload and no network calls.
• Consistent style - one pass yields a uniform versions file your team can review quickly.
• Clean commits - formatted output needs no extra cleanup, keeping history readable.
• Onboarding - a clear version policy helps new engineers understand the setup at a glance.
• Instant export - copy, download or print the file in one click and reuse it anywhere.