Terraform Version Manager (tfenv) Helper

tfenv is a Terraform version manager inspired by rbenv and pyenv. It reads a .terraform-version file in your project to decide which Terraform binary to install and use, so every developer and every CI runner works with the exact same version. The tfenv Helper writes that file plus the matching install, use, list and environment commands so your team never argues about which release is current.

You enter a version, optionally include a .terraformrc plugin-cache snippet to keep downloads local, and get a copy-paste-ready workflow. The tool validates the version string before producing anything, rejecting anything that is not a clean semantic version. Everything runs locally in your browser; nothing is uploaded and no cloud connection is made.

Because the output is plain shell text, you stay in full control and can drop it into a Makefile, a CI step or a README without modification. The helper is especially useful when onboarding new engineers who need a deterministic environment. Under the hood, tfenv stores installed binaries in its own directory and symlinks the active one into your path based on the .terraform-version file. The Helper mirrors that model so the generated artifacts match what tfenv actually consumes. Teams that adopt a single generated .terraform-version file report fewer environment bugs and faster onboarding because the version is fixed in source control rather than documented in a wiki that nobody reads.

• .terraform-version file - produces the exact single-line version string tfenv expects at the root of a project.
• Install and use commands - emits tfenv install and tfenv use for the chosen version.
• Inspection commands - adds tfenv list and tfenv list-remote so you can see what is available.
• CI pinning - exports TFENV_TERRAFORM_VERSION so pipelines select the version automatically.
• Optional .terraformrc - includes a plugin_cache_dir snippet to cache provider downloads locally.
• Version validation - rejects versions that are not digits and dots with at least one dot.
• Reproducible setup - the same generated file works on macOS, Linux and CI containers.
• list-remote awareness - the list-remote command helps you discover newer versions to upgrade to later.
• No external calls - unlike installing tfenv itself, this helper needs no network access to produce the file.
• Copy and download - export the bundle as text or a file you can commit.
• Documentation friendly - the generated text is easy to paste into a README or runbook as the canonical setup step.

1. Enter a version - type a semantic version such as 1.5.7 into the version field.
2. Check the plugin cache - toggle the .terraformrc snippet if you want to cache provider downloads on disk.
3. Generate the bundle - press "Generate" to validate the version and assemble the file and commands.
4. Review the output - read the preview to confirm the version and the tfenv commands look correct.
5. Save .terraform-version - copy the first line into a file named .terraform-version at your project root.
6. Run the commands - execute the tfenv install and tfenv use lines on a fresh machine to set up the environment.
7. Pin CI - export TFENV_TERRAFORM_VERSION from the generated line in your pipeline configuration.
8. Share with the team - commit .terraform-version to the repository so every clone inherits the pinned release.

Example - version 1.5.7. With the .terraformrc snippet off, the tool emits .terraform-version containing 1.5.7, followed by tfenv install 1.5.7, tfenv use 1.5.7, tfenv list and tfenv list-remote, plus export TFENV_TERRAFORM_VERSION=1.5.7.

Example - with cache. Toggling the snippet adds a .terraformrc block with plugin_cache_dir so repeated runs avoid re-downloading providers.

Example - upgrade path. Changing the version to 1.6.0 regenerates the same structure with the new number, making upgrades a single-file diff in version control.

• Consistent versions - everyone runs the same Terraform, ending "works on my machine" issues.
• Reproducible CI - the version is pinned through an environment variable, not a manual step.
• Clean cache - an optional plugin-cache keeps provider downloads local and fast.
• Validated input - malformed versions are rejected before you trust the file.
• Private - the whole workflow is built in your browser.
• Portable output - the text drops into any shell, Makefile or pipeline.
• Onboarding speed - new team members get a working environment from one generated file.
• Fewer environment bugs - pinning the version removes a whole class of subtle, version-related failures.