How to Install Terraform on Windows, Mac and Linux, and Verify It

To install Terraform, start at developer.hashicorp.com/terraform/install. On Windows, download the zip for your CPU, unzip terraform.exe and put its folder on your PATH. On macOS, run brew tap hashicorp/tap and then brew install hashicorp/tap/terraform. On Linux, add HashiCorp's signed apt or yum repository and install the terraform package.

The rest of this guide covers which build is official, how to check HashiCorp's PGP signature, what changed when HashiCorp rotated its Linux signing key in September 2026, version pinning, provider checks, patching and clean removal. Every command comes from HashiCorp, Microsoft, Homebrew, Debian or DNF documentation linked under Sources.

Key takeaways

• The only official download points are developer.hashicorp.com/terraform/install, releases.hashicorp.com, HashiCorp's apt and rpm repositories, and the hashicorp/tap Homebrew tap. HashiCorp says it does not maintain the Chocolatey package.
• Terraform 1.17.0 was the latest release on 23 October 2026.
• HashiCorp signs the SHA256SUMS file, not the zip itself. You verify the signature on the checksum file, then check the zip against the checksum.
• The release signing key is ID 72D7468F, fingerprint C874 011F 0AB4 0511 0D02 1055 3436 5D94 72D7 468F. HashiCorp extended its expiry to 1 March 2030.
• The Linux apt and rpm repositories use a separate key. HashiCorp rotated it on 10 September 2026 after a security incident in part of its software delivery pipeline. The new fingerprint is D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560.
• Terraform 1.6.0 and later ship under the Business Source License 1.1, not an open source license. Internal use is permitted.
• Pin the CLI with required_version and commit .terraform.lock.hcl so provider downloads are checked too.

Which Terraform should you install, and what license is it under?

There is one Terraform CLI, published by HashiCorp, whose license file names IBM as the licensor. It is a single executable named terraform. HashiCorp's install tutorial says "Any other files in the archive can be safely removed", which in practice means the LICENSE.txt file that ships beside the binary.

The install page lists every supported platform and the current version. When we fetched it on 23 October 2026 it offered 1.17.0 as latest, with the newest patch release of each older minor line (1.16.7, 1.15.9, 1.14.9 and so on) in a version picker.

The tutorial also documents building from source with git clone https://github.com/hashicorp/terraform and go install, for platforms with no prebuilt binary. Everyone else should use the signed release.

The license, in HashiCorp's own words

The LICENSE file in the hashicorp/terraform repository applies the Business Source License 1.1 to "Terraform Version 1.6.0 or later", with IBM as the licensor. Its main points:

• You may copy, modify, redistribute and make non production use of Terraform.
• An Additional Use Grant permits production use, as long as it does not involve offering Terraform to third parties "on a hosted or embedded basis" to compete with IBM's paid versions.
• Internal use within an organisation, including its affiliates, is "not considered a competitive offering."
• Each version converts to the Mozilla Public License 2.0 four years after it is published.

For teams running Terraform against their own infrastructure, that is permission to use it. If you build a product that hosts or embeds Terraform for paying customers, read the license and HashiCorp's license FAQ with your counsel.

How to avoid lookalike download sites and unofficial packages

Terraform runs with the cloud credentials on your laptop or CI runner. A tampered terraform binary sees every access key, every state file and every plan it touches. HashiCorp's own verification guide opens with that risk: attackers can gain access "by tricking you into running an executable that includes malicious code."

A few rules keep you on the official path:

1. Type the address. Use developer.hashicorp.com/terraform/install or releases.hashicorp.com/terraform/. Every zip link on the install page points to releases.hashicorp.com.
2. Ignore sponsored results for "terraform download". An ad can sit above the real result and copy its wording.
3. Do not trust a file name. Anyone can name a file terraform_1.17.0_windows_amd64.zip. Only the signed checksum tells you what you have.
4. Know who maintains each package. HashiCorp maintains its Homebrew tap and Linux repositories, and says it does not maintain Chocolatey or the Terraform package there.
5. Avoid "terraform installer" bundles, download managers and repack sites. HashiCorp ships a plain zip. A Terraform "setup.exe" did not come from HashiCorp.
6. For containers, use HashiCorp's official images on Docker Hub, or verify the binary while you build your own image as shown below.

How to install Terraform on Windows, step by step

HashiCorp's install page lists only the binary download for Windows. The tutorial adds Chocolatey with a caveat. Here is the binary route, which you can verify end to end.

Step 1: download the right zip

Open https://developer.hashicorp.com/terraform/install and pick the Windows build:

• AMD64 for nearly every Windows 10 and 11 PC with an Intel or AMD processor.
• ARM64 for Windows on Arm devices.
• 386 only for 32 bit Windows.

Also download terraform_1.17.0_SHA256SUMS and terraform_1.17.0_SHA256SUMS.sig from https://releases.hashicorp.com/terraform/1.17.0/ . The install page links both.

Step 2: check the zip before you unzip it

In PowerShell, hash the zip with Microsoft's Get-FileHash cmdlet, which uses SHA256 by default:

Get-FileHash .\terraform_1.17.0_windows_amd64.zip

Open the SHA256SUMS file in a text editor and find the line for your file. For 1.17.0 on Windows AMD64 it reads:

2948dd7f77dec0f562ec29000103e0441d915be5e5f1a02c1ce23681951cfb19  terraform_1.17.0_windows_amd64.zip

The hashes must match exactly. That proves the zip matches the checksum file, not that the checksum file is HashiCorp's. For that, verify the .sig file with the gpg --verify command in the verification section below, on Windows if you have GnuPG, or on a Linux or macOS machine or in WSL.

Step 3: unzip it to a folder you control

Microsoft's Expand-Archive cmdlet unpacks the zip:

Expand-Archive -Path .\terraform_1.17.0_windows_amd64.zip -DestinationPath C:\Tools\terraform

Choose a folder that standard users cannot write to if the machine is shared. A binary on PATH that anyone can overwrite is a binary anyone can replace.

Step 4: check the Authenticode signature

HashiCorp Authenticode signs its Windows executables. Its security page gives this check:

(Get-AuthenticodeSignature -FilePath terraform.exe).SignerCertificate | Format-List

The Subject should read CN="HashiCorp, Inc.", O="HashiCorp, Inc.", issued by a DigiCert code signing CA, and Get-AuthenticodeSignature on its own should report a Status of Valid. When we inspected the 1.17.0 AMD64 build, the signing certificate was issued by DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 to HashiCorp, Inc., valid from 22 January 2026, with thumbprint 65B9DA802B1273FB147374C3C122DB21ABECDFC4. That thumbprint is newer than the three listed on the copy of HashiCorp's security page we could read, so treat the signed SHA256SUMS file as the primary check.

Step 5: add the folder to PATH

HashiCorp's tutorial has you print your PATH with path and move terraform.exe into a folder already on it. To use a dedicated folder such as C:\Tools\terraform instead, add that folder (not the exe) to Path under your user variables in Environment Variables, then open a new terminal.

Step 6: confirm it works

terraform -help
terraform version

terraform -help lists the subcommands; terraform version prints the version and platform.

Optional: Chocolatey

The tutorial lists choco install terraform, with a note: "HashiCorp does not maintain Chocolatey or the Terraform package." It may lag releases, and its integrity checks are Chocolatey's, not HashiCorp's signature.

How to install Terraform on macOS

Option 1: Homebrew with the HashiCorp tap

Homebrew is the route HashiCorp lists first for macOS. You install from HashiCorp's own tap, which the tutorial calls "Hashicorp's official repository of all our Homebrew packages":

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Use the fully qualified name hashicorp/tap/terraform, not plain terraform. The tap's formula downloads the zip from releases.hashicorp.com and pins its SHA-256 for each platform. We checked the 1.17.0 formula: its hashes for the Intel and Apple silicon builds match the lines in HashiCorp's signed SHA256SUMS file. Need Homebrew first? See our Homebrew install guide covers that first.

Option 2: the binary zip

Pick ARM64 on any Mac with an M series chip and AMD64 on an Intel Mac. If you are unsure, About This Mac in the Apple menu shows whether the chip is Apple or Intel. Download, verify (next section), unzip and move the binary, as the tutorial shows:

echo $PATH
mv ~/Downloads/terraform /usr/local/bin/

The tutorial notes that this "assumes that the executable is currently in your downloads folder and that your PATH includes /usr/local/bin". On some Macs that directory needs sudo to write.

Check Apple's code signature

HashiCorp code signs its macOS executables. The security page gives this check, and says to compare the TeamIdentifier:

codesign --verify -d --verbose=2 /usr/local/bin/terraform

The output should include Authority=Developer ID Application: Hashicorp, Inc. (D38WU7D763) and TeamIdentifier=D38WU7D763. We ran it against the 1.17.0 Apple silicon binary and got exactly that, chained to Developer ID Certification Authority and Apple Root CA.

How to install Terraform on Linux with HashiCorp's signed repositories

HashiCorp maintains and signs apt and rpm repositories, so updates arrive through your normal package manager and every package is checked against HashiCorp's key. On 23 October 2026, apt.releases.hashicorp.com listed these releases:

HashiCorp's packaging guide says it removes end of life distribution versions regularly. If yours is missing, upgrade the OS or use the verified binary.

Ubuntu and Debian

These steps follow HashiCorp's tutorial and the instructions on apt.releases.hashicorp.com.

1. Install the tools needed to handle the key:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

2. Download HashiCorp's repository key into a dedicated keyring:

wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

3. Check the key's fingerprint before you trust it:

gpg --no-default-keyring \
--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
--fingerprint

The output must show D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560 with the user ID HashiCorp Security (HashiCorp Package Signing). That is the fingerprint apt.releases.hashicorp.com and HashiCorp's bulletin HCSEC-2026-33 give. If you see a different fingerprint, stop. The section on the key rotation below explains the old ones.

4. Add the repository, scoped to that key only:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

The signed-by option matters. It tells apt to accept this repository's metadata only if HashiCorp's key signed it, and stops that key from vouching for any other repository on the system.

5. Install:

sudo apt update
sudo apt-get install terraform

RHEL and CentOS

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

The repository file HashiCorp publishes sets gpgcheck=1 and gpgkey=https://rpm.releases.hashicorp.com/gpg, so every package is checked against HashiCorp's key. On first install, yum or dnf shows the key's fingerprint and asks you to accept it. Compare it with D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560 before you type y. The same file also defines a hashicorp-test channel for prereleases, disabled by default. Leave it disabled on anything that runs real infrastructure.

Fedora

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager addrepo --from-repofile=https://rpm.releases.hashicorp.com/fedora/hashicorp.repo
sudo dnf -y install terraform

Amazon Linux

Amazon Linux 2:

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform

Amazon Linux 2023:

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo dnf -y install terraform

Other distributions and Alpine

For other distributions, including Alpine, which HashiCorp does not package, use the binary zip and verify it as described next.

What the September 2026 key rotation means for you

On 10 September 2026 HashiCorp published bulletin HCSEC-2026-33. It says the GPG key that signs its Linux packages "was rotated on September 10th, 2026" as a precaution after "a security incident affecting part of our internal software delivery pipeline". HashiCorp states it found no evidence that customer data was accessed and no evidence that any released artifact or package was modified. It re-signed the affected packages with the new key and asked customers to replace any cached or pinned copy of the old one.

The key history, from HashiCorp's security page and bulletins:

Two lessons. When the key at a repository URL changes, wait for the publisher to confirm it through a separate channel, as administrators did in a HashiCorp forum thread that morning before the bulletin appeared. And if you bake the key into images, playbooks or Dockerfiles, update every one. On 23 October 2026 we confirmed both repository key URLs serve the D55C key and that current repository metadata is signed with it.

How do you verify a Terraform download?

HashiCorp's security page is precise about what is signed: "only the SHA256SUM file is signed by the PGP key above. The archives themselves are not signed, but rather hashed." So verification is a chain with two links:

1. The PGP signature proves HashiCorp made the SHA256SUMS file and nobody changed it.
2. The SHA-256 hash proves your zip matches the line for it in that file.

Skip either link and the check proves much less. A hash taken from the same web page as the download only tells you the download was not corrupted in transit.

Step 1: get HashiCorp's release key and check its fingerprint

HashiCorp publishes the key at a well known URL, and also on Keybase:

curl --remote-name https://www.hashicorp.com/.well-known/pgp-key.txt
gpg --import pgp-key.txt
gpg --fingerprint --list-signatures "HashiCorp Security"

The primary key fingerprint must be C874 011F 0AB4 0511 0D02 1055 3436 5D94 72D7 468F, key ID 34365D9472D7468F. HashiCorp's security page lists the same values. When we imported it on 23 October 2026 it showed an expiry of 1 March 2030. That matches bulletin HCSEC-2026-03, published 12 March 2026, which explains that the key was due to expire on 18 April 2026 and had been extended. If your copy shows a 2026 expiry, you imported an old copy. Fetch it again.

HashiCorp's tutorial runs these steps in a throwaway GnuPG home, so nothing touches your personal keyring:

mkdir verify-hashicorp-binary
cd verify-hashicorp-binary
export GNUPGHOME=./.gnupg
gpg --quick-generate-key --batch --passphrase "" human@example.com

It then signs HashiCorp's key with it (gpg --sign-key 34365D9472D7468F) so gpg reports full trust. As the tutorial warns, never use a blank passphrase for a key you keep.

Step 2: download the archive, checksums and signature

The tutorial uses variables so the same commands work for any version and platform:

export PRODUCT=terraform && \
  export VERSION=1.17.0 && \
  export OS_ARCH=darwin_arm64
curl --remote-name https://releases.hashicorp.com/"${PRODUCT}"/"${VERSION}"/"${PRODUCT}"_"${VERSION}"_"${OS_ARCH}".zip
curl --remote-name https://releases.hashicorp.com/"${PRODUCT}"/"${VERSION}"/"${PRODUCT}"_"${VERSION}"_SHA256SUMS
curl --remote-name https://releases.hashicorp.com/"${PRODUCT}"/"${VERSION}"/"${PRODUCT}"_"${VERSION}"_SHA256SUMS.sig

Set OS_ARCH to match the file you want, such as linux_amd64, linux_arm64 or windows_amd64. The release directory for 1.17.0 also contains terraform_1.17.0_SHA256SUMS.72D7468F.sig. The security page explains that "multiple .sig files may be present, named with the associated signing PGP key ID". Either signature file verifies against the same key.

Step 3: verify the signature on the checksum file

gpg --verify ${PRODUCT}_${VERSION}_SHA256SUMS.sig ${PRODUCT}_${VERSION}_SHA256SUMS

For 1.17.0 we got:

gpg: Signature made Wed Oct 21 2026
gpg:                using RSA key 374EC75B485913604A831CC7C820C6D5CD27AB87
gpg: Good signature from "HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>"

374E ... AB87 is a signing subkey of the key you imported. What matters is Good signature. Without the throwaway key step, gpg adds "WARNING: This key is not certified with a trusted signature!" That only means you have not certified the key yourself; your assurance comes from the fingerprint check in step 1. BAD signature means stop.

Step 4: verify the archive against the checksum

shasum --algorithm 256 --check ${PRODUCT}_${VERSION}_SHA256SUMS --ignore-missing

Without --ignore-missing, as in the tutorial, you also see "No such file or directory" for every platform you did not download. On Linux without shasum, the tutorial's Dockerfile uses:

grep ${PRODUCT}_${VERSION}_linux_amd64.zip ${PRODUCT}_${VERSION}_SHA256SUMS | sha256sum -c

You want OK next to your zip. Anything else means delete it and download again.

Verifying inside a container build

HashiCorp's guide includes an Alpine Dockerfile that imports the key, verifies the checksum signature, checks the zip and only then installs it. The core of its RUN step:

FROM alpine:latest
ARG PRODUCT
ARG VERSION
RUN apk add --update --virtual .deps --no-cache gnupg && \
  cd /tmp && \
  wget https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_linux_amd64.zip && \
  wget https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_SHA256SUMS && \
  wget https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_SHA256SUMS.sig && \
  wget -qO- https://www.hashicorp.com/.well-known/pgp-key.txt | gpg --import && \
  gpg --verify ${PRODUCT}_${VERSION}_SHA256SUMS.sig ${PRODUCT}_${VERSION}_SHA256SUMS && \
  grep ${PRODUCT}_${VERSION}_linux_amd64.zip ${PRODUCT}_${VERSION}_SHA256SUMS | sha256sum -c && \
  unzip /tmp/${PRODUCT}_${VERSION}_linux_amd64.zip -d /tmp && \
  mv /tmp/${PRODUCT} /usr/local/bin/${PRODUCT} && \
  apk del .deps

Build it with docker build --build-arg PRODUCT=terraform --build-arg VERSION=1.17.0 -t terraform-alpine:test . and check with docker run -it terraform-alpine:test terraform version. Our addition: the example does not check the key's fingerprint, so copy in a key file you verified once, and pin the base image by digest.

Checking packages installed from the repositories

With the apt or rpm route, the package manager checks signatures for you. Your manual job is the fingerprint check when you install the key, and again whenever it changes.

Pin the Terraform version and run several versions side by side

Installing Terraform once is easy. Keeping a team, its CI and its modules on compatible versions takes a little configuration.

required_version in the terraform block

The terraform block's required_version setting "specifies which version of the Terraform CLI is allowed to run the configuration." Terraform prints an error and exits, taking no action, when the running CLI does not satisfy it.

terraform {
  required_version = "~> 1.17.0"
}

The ~> operator "allows only the right-most version component to increment". So ~> 1.17.0 accepts 1.17.1 and later patch releases but not 1.18.0, while ~> 1.17 would accept 1.18 and later minor versions but not 2.0. Child modules can set their own constraints, and Terraform requires the CLI to satisfy all of them. required_version applies only to the CLI, not to providers; providers have their own version arguments inside required_providers.

A sensible split: ~> 1.17.0 in root configurations so patches flow, and a minimum such as >= 1.6 in reusable modules.

Several versions on one machine

HashiCorp documents two tools for getting a specific version: the hashicorp/setup-terraform GitHub Action and hc-install, a Go module and CLI that downloads, verifies signatures and checksums, and asserts version constraints. In a workflow:

- uses: hashicorp/setup-terraform@v4
  with:
    terraform_version: "1.17.0"

For hc-install, the README describes the module as experimental. You can install its CLI from Homebrew with brew install hashicorp/tap/hc-install, from the same apt and rpm repositories (package name hc-install), or from a verified zip on releases.hashicorp.com. Its -path option sets where the binary lands, so you can keep, for example, a 1.14 and a 1.17 binary in separate folders and call each by its full path. The README also warns that go install "provides only minimal to no integrity checks", so do not install hc-install itself that way.

Community version switchers are not HashiCorp projects; check what they verify before relying on them.

Providers are downloads too

Every provider is a separate executable that terraform init downloads and runs with your credentials. Verifying the CLI and then trusting providers blindly leaves the bigger door open.

Commit the dependency lock file

From Terraform 0.14 onward, terraform init writes .terraform.lock.hcl with the exact provider versions it chose and a set of checksums for each. HashiCorp says to include this file in version control "so that you can discuss potential changes to your external dependencies via code review". On later runs, Terraform checks every provider package it installs against those recorded checksums and fails if none match.

HashiCorp describes this as a "trust on first use" model. The first time you add a provider, verify it however your policies require. After that, Terraform raises an error if a future download for the same version does not match.

Two hash formats appear in the file:

• zh: is the "zip hash", a SHA-256 of each official zip, taken from the registry protocol.
• h1: is a newer scheme that Terraform adds as it learns of it, after confirming the package matches an existing hash.

When a registry signs its checksums, terraform init prints the key that signed them, for example "signed by a HashiCorp partner, key ID DC9FC6B1FCE47986". HashiCorp suggests you confirm you trust that key holder before committing the lock file. Provider authors publishing to the public registry must ship a SHA256SUMS file and sign it with a GPG key they register, the same pattern HashiCorp uses for Terraform itself.

Useful flags

terraform providers lock \
  -platform=windows_amd64 \
  -platform=darwin_amd64 \
  -platform=linux_amd64

This records checksums for every platform your team uses, so a lock file created on a Mac still verifies on a Linux CI runner, including when providers come from a mirror.

In CI, terraform init -lockfile=readonly verifies checksums against the lock file without changing it, so a pipeline cannot silently accept a new provider build. terraform init -upgrade deliberately ignores the lock file to pick newer versions; run it on a branch and review the lock file diff like any dependency update.

We cover the provider side in more depth in Terraform provider verification, how Terraform verifies a provider with trust on first use and what moves when you run terraform init -upgrade.

Modules are not locked

The lock file "tracks only provider dependencies." Terraform always picks the newest module version that meets your constraints, so use an exact version constraint to hold a module still.

How do you keep Terraform patched?

Know when a new version is out

terraform version checks for a newer release and prints "Your version of Terraform is out of date!" with the latest version when one exists. terraform version -json prints the version, platform and selected providers, but HashiCorp notes it includes no upgrade or security information, so do not rely on it for alerting.

Update commands by install method

Follow HashiCorp's security bulletins

HashiCorp publishes security bulletins, numbered HCSEC followed by the year and a sequence number, in the Security category of discuss.hashicorp.com. Each bulletin points back to hashicorp.com/security. Watch that category if you run any HashiCorp tool. Bulletins cover more than the CLI: 2026 brought ones for Terraform Enterprise (HCSEC-2026-17), the Terraform MCP Server (HCSEC-2026-23), the go-slug and go-getter libraries (HCSEC-2026-31, HCSEC-2026-39 and HCSEC-2026-44) and the signing key rotation (HCSEC-2026-33). Check each for affected products and versions.

How do you uninstall Terraform cleanly?

Windows

Delete terraform.exe and remove its folder from your user PATH under Environment Variables. If you used Chocolatey, uninstall through Chocolatey instead.

macOS with Homebrew

brew uninstall hashicorp/tap/terraform
brew untap hashicorp/tap

Only untap if you use no other HashiCorp tools from the tap. For a manual install, delete the binary you moved, for example /usr/local/bin/terraform.

Ubuntu and Debian

sudo apt remove terraform
sudo rm /etc/apt/sources.list.d/hashicorp.list
sudo rm /usr/share/keyrings/hashicorp-archive-keyring.gpg
sudo apt update

Remove the source list and the keyring together. A repository key left behind can still vouch for a repository someone adds later.

RHEL, Fedora and Amazon Linux

sudo dnf remove terraform
sudo rm /etc/yum.repos.d/hashicorp.repo

Use yum in place of dnf on systems that only have yum. Packages from other HashiCorp products also come from that repo file; keep it if you use them.

What to clean up on any OS

• Plugin cache. If you set plugin_cache_dir, delete that directory. HashiCorp's example location is $HOME/.terraform.d/plugin-cache.
• Implied local mirror directories. $HOME/.terraform.d/plugins on Linux and macOS, ~/Library/Application Support/io.terraform/plugins on macOS, and %APPDATA%/terraform.d/plugins or %APPDATA%/HashiCorp/Terraform/plugins on Windows.
• CLI configuration. .terraformrc in your home directory, or terraform.rc in %APPDATA% on Windows. It can hold credentials for HCP Terraform or Terraform Enterprise, so delete it deliberately rather than leaving it behind.
• Per project directories. Each working directory has a .terraform folder with downloaded providers and modules. Removing Terraform does not remove them.

Common errors and how to fix them

"'terraform' is not recognized as an internal or external command"

Windows cannot find terraform.exe on PATH. Check that you added the folder, not the file, that you opened a new terminal, and that the exe is not still inside the zip. On macOS or Linux the equivalent message is command not found, and echo $PATH shows where the shell looks.

"NO_PUBKEY" or "The following signatures couldn't be verified" on apt update

apt has no key matching the one that signed HashiCorp's repository metadata. Since 10 September 2026 the most common cause is an old copy of the repository key, fingerprint 798A EC65 4E5C 1542 8C8E 42EE AA16 FCBC A621 E701, saved before the rotation. The error names the key ID it wanted. For HashiCorp's repository it should be FC9CA96ACA026560. Fix it by downloading the key again with the step 2 command from the Ubuntu section, checking the fingerprint is D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560, then running sudo apt update. Never work around it with trusted=yes or by removing signed-by.

Apple silicon and other architecture mismatches

If the binary refuses to start with an error such as "bad CPU type in executable" on macOS or "exec format error" on Linux, you most likely downloaded the wrong architecture. On an Apple silicon Mac, an Intel (AMD64) build needs Rosetta; the native build is ARM64. On Linux, an ARM64 binary will not run on an x86_64 host, and the reverse. Download the matching zip, for example darwin_arm64 for Apple silicon, and verify it again. Homebrew picks the right build automatically, which is one reason to prefer it on a Mac.

"the current package ... doesn't match any of the checksums previously recorded in the dependency lock file"

This is the trust on first use check doing its job. The provider package Terraform just downloaded does not match any hash in .terraform.lock.hcl for that version. Innocent causes include a lock file made on another OS without terraform providers lock -platform=..., or a mirror serving a different build. Do not delete the lock file to silence the error until you know why the package changed. If the platform list is the cause, run terraform providers lock for every platform and commit the result.

Terraform refuses to run because of a version constraint

Your CLI does not satisfy a required_version constraint in the root module or a child module. Install the version the configuration expects with Homebrew, the repositories, setup-terraform or hc-install, or update the constraint on purpose in a reviewed change.

Common mistakes

• Checking the hash without the signature. A SHA-256 copied from the same page as the download catches corruption, not tampering. Verify SHA256SUMS.sig first.
• Ignoring the "not certified" gpg warning without checking the fingerprint. The warning is harmless only if you compared the fingerprint against HashiCorp's published one.
• Pinning a stale repository key. Images and playbooks that embedded the pre September 2026 key broke on 10 September. Store the fingerprint with the key and check it in the build.
• Installing plain terraform from Homebrew instead of hashicorp/tap/terraform. Use the fully qualified name the docs give.
• Leaving hashicorp-test enabled on production systems, which pulls prereleases.
• Not committing .terraform.lock.hcl. Without it, each machine trusts whatever provider build it downloads first.
• Running terraform init -upgrade in CI instead of on a reviewed branch.
• Leaving Terraform writable by non admin users on shared build hosts, or stale binaries in CI images.

Where Safeguard fits, honestly

Safeguard does not install Terraform, verify HashiCorp's signatures, check provider checksums or manage your .terraform.lock.hcl. Those are the steps in this guide, and they are yours to run. Safeguard also does not see the version of terraform on a laptop.

Where Safeguard helps is around the code Terraform lives next to. It connects to your Git hosting to inventory repositories and the open source dependencies declared in them, matches those components against vulnerability databases, and uses reachability analysis to rank the findings your code actually calls. The CLI scans a repository directory, a container image or an SBOM file (safeguard scan --dir ., --image, --sbom), so a CI image that bundles Terraform can be inventoried like any other. When a fixed version of a vulnerable dependency exists, autonomous remediation can open a fix pull request in the same Git host. Remediation ships switched off by default. For the Terraform side of your repositories, our Terraform IaC security scanning guide and securing Terraform state cover practices that apply whatever tools you use.

Fix it without waiting for upstream

A verified Terraform binary is the start of the chain, not the end. The infrastructure it deploys runs applications built from open source dependencies and container images, and those carry their own vulnerabilities. Terraform itself you patch with the commands above. For the code you ship on that infrastructure, there is a faster path than waiting.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

How do I install Terraform on Windows 11?

Download the AMD64 zip (or ARM64 on a Windows on Arm PC) from developer.hashicorp.com/terraform/install, along with the SHA256SUMS and SHA256SUMS.sig files. Check the zip with Get-FileHash against the SHA256SUMS line, unzip it with Expand-Archive, add the folder that holds terraform.exe to your user PATH, open a new terminal and run terraform -help.

How do I install Terraform on a Mac?

Run brew tap hashicorp/tap and then brew install hashicorp/tap/terraform. On Apple silicon, Homebrew picks the ARM64 build automatically. If you prefer the binary, download the darwin_arm64 zip for M series Macs or darwin_amd64 for Intel, verify it, and move terraform into a folder on your PATH such as /usr/local/bin.

How do I install Terraform on Ubuntu?

Install gnupg and software-properties-common, download HashiCorp's key into /usr/share/keyrings/hashicorp-archive-keyring.gpg, confirm the fingerprint is D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560, add the apt.releases.hashicorp.com repository with signed-by, then run sudo apt update and sudo apt-get install terraform.

How do I verify a Terraform download?

Import HashiCorp's key from https://www.hashicorp.com/.well-known/pgp-key.txt and confirm the fingerprint C874 011F 0AB4 0511 0D02 1055 3436 5D94 72D7 468F. Run gpg --verify on the SHA256SUMS.sig file and look for "Good signature". Then run shasum -a 256 -c on the SHA256SUMS file with --ignore-missing and look for OK next to your zip.

Why does apt say NO_PUBKEY for the HashiCorp repository?

Most likely you have the repository key from before HashiCorp rotated it on 10 September 2026. Download the key again from apt.releases.hashicorp.com/gpg, confirm the new fingerprint D55C 0D1A C78A 8D81 26CB 631C FC9C A96A CA02 6560, and run sudo apt update. HashiCorp's bulletin HCSEC-2026-33 explains the change.

Is Terraform still free to use?

Terraform 1.6.0 and later use the Business Source License 1.1. It permits production use, treats internal use as non competitive, and restricts offering Terraform to third parties on a hosted or embedded basis in competition with IBM's paid versions.

How do I check which version of Terraform I have?

Run terraform version. It prints the version and platform, any providers selected in the current directory, and a notice if a newer release is out. Compare the result with the version shown on the install page.

How do I run two versions of Terraform on one machine?

Use hc-install install -version <version> terraform with a different -path for each version, then call each binary by its full path. In GitHub Actions, set terraform_version on hashicorp/setup-terraform. Add required_version to each configuration so the wrong binary fails fast instead of running.

Is the Chocolatey Terraform package official?

No. HashiCorp's tutorial lists choco install terraform but says "HashiCorp does not maintain Chocolatey or the Terraform package." It may lag releases. For the latest version, or when you need to verify HashiCorp's signature yourself, use the zip from the install page.

See how Safeguard would help

None of these demos install or verify Terraform. They show what happens around it once your infrastructure code and the applications it deploys are in Git. If you want to try the CLI yourself, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same ask before every command pattern is what you want on a machine that holds cloud credentials: nothing runs in the repository next to your Terraform code without your say so.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. Platform teams that build their own Terraform CI images can use the same local flow to scan those images and the application repositories they deploy from their own machines.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If you use an assistant to help write infrastructure code, this shows how to let it look up findings and safe versions while keeping its access to exactly the tools you pick.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• HashiCorp: Install Terraform
• HashiCorp tutorial: Install Terraform
• HashiCorp Well-Architected Framework: Verify HashiCorp binaries
• HashiCorp security page (PGP key, checksum and code signing verification)
• HashiCorp PGP public key
• HashiCorp official packaging guide
• HashiCorp Linux package indexes (apt.releases.hashicorp.com)
• HashiCorp RHEL repository file
• HashiCorp releases: Terraform
• HashiCorp releases: Terraform 1.17.0
• Terraform 1.17.0 SHA256SUMS
• Terraform 1.17.0 release notes on GitHub
• HCSEC-2026-33: HashiCorp Linux Signing GPG Key Update (CA026560)
• HCSEC-2026-03: HashiCorp GPG Key (72D7468F) Update
• HCSEC-2026-44: Go-getter path traversal in S3/GCS directory download handling
• HashiCorp Discuss: community thread on the new apt signing key
• HashiCorp Discuss: Security bulletins category
• Terraform LICENSE (Business Source License 1.1)
• Terraform docs: Dependency lock file
• Terraform docs: terraform providers lock
• Terraform docs: terraform init
• Terraform docs: terraform version
• Terraform docs: terraform block reference
• Terraform docs: Version constraints
• Terraform docs: CLI configuration file
• Terraform docs: Upgrade guides
• Terraform Registry docs: Publishing providers
• hashicorp/hc-install README
• hashicorp/setup-terraform README
• hashicorp/homebrew-tap: Terraform formula
• Microsoft Learn: Get-FileHash
• Microsoft Learn: Expand-Archive
• Microsoft Learn: Get-AuthenticodeSignature
• Homebrew manpage
• Debian manpage: apt(8)
• DNF command reference

Last reviewed: 23 October 2026. HashiCorp ships Terraform releases and signing key updates on its own schedule; check the install page and the HashiCorp security bulletins for the current version and fingerprints.