# m1-terraform-provider-helper: compiling Terraform providers for ARM Macs

> m1-terraform-provider-helper is a Go CLI that installs Terraform and OpenTofu providers on an Apple Silicon Mac, compiling from source when no pre-built binary exists for darwin_arm64 and keeping the dependency lock file in step. It fits engineers whose projects pin a provider version that never shipped a Mac binary, and it does not fit a provider whose upstream will not accept a build you made yourself.

**kreuzwerker/m1-terraform-provider-helper** — CLI to support with downloading and compiling terraform providers for Mac with M1 chip

- Repository: https://github.com/kreuzwerker/m1-terraform-provider-helper
- Stars: 541 · Forks: 29
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kreuzwerker-m1-terraform-provider-helper

## Providers that never shipped an ARM Mac binary

The motivation section of the README is a first person account of a specific and common failure. On a new MacBook with an M1 chip, the author kept hitting problems in client projects: some Terraform providers had not adapted to the darwin_arm64 architecture at all, and others were pinned to an older, incompatible version. In both cases there was no pre-built binary for darwin_arm64, so the only option was to compile the provider yourself. The pain that produced this tool was not the compilation itself, which is documented in a Terraform issue, but the constant switching between self-compiled and pre-built binaries across projects. The tool exists to manage that detail, and it is written in Go and published under the MIT licence. The audience is the engineer or consultant who runs Terraform on a Mac and keeps hitting a provider that was not built for it.

## A small command set with an activate step

The CLI's own help text lists the commands, and the shape tells you how it works. There is an activate command and a deactivate command, which is unusual and important: the helper has to be active before it can manage anything, so the first thing a user does is turn it on. The install command downloads and compiles a provider for an ARM based Mac, list enumerates the available providers and their versions, lockfile groups the commands that work with Terraform lock files, status shows the state of the installation, version prints the version, and completion generates a shell autocompletion script. The tool targets Terraform and OpenTofu together rather than Terraform alone. By default it auto-detects which of the two is present and prefers terraform when both are installed, and that choice can be forced with an iac-tool flag taking either terraform or tofu. When terraform is missing but tofu is present, the helper falls back to the OpenTofu defaults, which are the plugin directory under the OpenTofu configuration folder and the OpenTofu provider registry.

## Installing the helper and finding your Go

Installation is a Homebrew tap, and the README lists the dependency that catches people out:

```sh
brew install kreuzwerker/taps/m1-terraform-provider-helper
```

Since Go is used to build the providers, you need a working Go setup in the local directory where you run the helper's commands. The subtlety the README explains is that although Go is installed by Homebrew as a dependency of the helper, the Go binary will not necessarily be on your path. The example given is a version manager such as asdf, whose shim is likely to come before the Homebrew binary in the path. The instruction is blunt: make sure the command go version succeeds before using the tool. This is a per-shell check rather than a one time installation step, which is why it is worth doing it in the directory you will actually work in, since the README ties the requirement to the local directory where the helper commands run.

## Installing a provider version that has no binary

The worked example in the README is the case the tool exists for. You want version v2.10.0 of the Vault provider because a project uses it, and you assume there is no pre-built binary for an ARM based Mac. The helper is activated first if that has not happened yet, and then the install command takes the provider address and the version:

```sh
m1-terraform-provider-helper activate # (In case you have not activated the helper)
m1-terraform-provider-helper install hashicorp/vault -v v2.10.0 # Install and compile
```

Two details of the implementation matter when something goes wrong. The install command relies on an internal build commands map to find the correct build command for a provider, so when that map is wrong for a provider, the README's advice is to read the provider's own documentation for the right command and then pass it with the build-command flag. And the helper downloads the provider's source code into a directory under your home folder, which means the sources are sitting on disk and you can play with them or compile them yourself if the helper's attempt does not work. That is a deliberate design choice, since a compilation failure is usually a problem in the provider's build, not in the tool.

## The lockfile checksum problem and its fix

Installing a provider locally creates a second problem, and it is the one that makes teams give up on self-compiled providers. Most Terraform projects carry a dependency lock file that pins checksums, and once you replace a released provider with your own build, every later init fails:

```
Error: Failed to install provider

Error while installing hashicorp/azurerm v2.1.0: the current package for
registry.terraform.io/hashicorp/azurerm 2.1.0 doesn't match any of the
checksums previously recorded in the dependency lock file.
```

The explanation in the README is precise about the cause. The checksums already in the lockfile belong to the previously installed darwin_amd64 provider, while the helper produces a locally compiled darwin_arm64 provider with a different checksum, so the two can never match. The fix is to add the checksum of the local provider to the lockfile, and the lockfile upgrade command does that, adding the checksum of all used local providers to the project's lock file, with flags to specify the input and output directories. The consequence for your repository is that the lock file changes and has to be committed, and a reviewer looking at the diff will see a new checksum for the affected providers.

## What the tool is built from

The Go module gives the shape of the implementation. The module path matches the repository, and the dependencies are a short list of well known pieces: cobra for the command line interface, go-git for the source download, the HCL library and go-cty for reading Terraform configuration and lock files, go-version for version comparison, and httpmock for testing HTTP interactions without touching the network. The Makefile is a self documenting one, in the marmelab style, and it pins the version information into the binary through linker flags, so a built binary can report its version, commit hash and build date. It also carries a Go version check as its own target, and the release tooling versions are pinned in the file, including the test summary tool, the linter, the changelog generator and the semantic version utility. The repository also has a changelog configuration, a lint configuration, a Renovate configuration and a testdata directory, which is the standard layout for a Go command that is released rather than merely built.

## A Homebrew tap, an MIT licence, and a release every few months

The distribution story is narrow and deliberate. There is a Homebrew tap, the kreuzwerker tap, and the README links the Terraform and Kreuzwerker logos into the header, so the tool is presented as part of a consultancy's public tooling. The licence is MIT, the default branch is main, and the repository has no homepage field. The release history is the most recent thing in the repository: v0.10.1 on 2026-08-24, 0.10.0 on 2026-06-03 and v0.9.1 on 2026-04-25. The last push was on 2026-10-16 and the repository is not archived, so the tool is being worked on even between releases. The project topics include hacktoberfest, which explains the presence of a contribution workflow, and the m1-mac and terraform tags place it in the narrow band of problems it solves. The documentation covers more than the README shows, with sections on debugging installation problems, lockfile handling, custom build commands, custom provider repositories, logging, timeouts and the plugin directory, so the questions that come up after the first install are written down rather than left to the issue tracker.

## Conclusion

m1-terraform-provider-helper fits a team working on Apple Silicon Macs against a provider version that has no darwin_arm64 release, and who already have Go on the machine. It does not fit a project pinned to a provider whose build fails on that architecture, or a policy that forbids running a locally compiled binary. Verify first that go version succeeds in the directory where you run the commands, because the helper installs Go as a Homebrew dependency but a version manager can shadow it, then run the lockfile upgrade command and commit the result, since a locally compiled provider has a different checksum from the released one.

## FAQ

### How do I install m1-terraform-provider-helper on a Mac?

The README gives one command: brew install kreuzwerker/taps/m1-terraform-provider-helper. It also warns that Go must be usable in the directory where you run the commands, and that a version manager such as asdf can shadow the Go binary that Homebrew installs.

### How do I install a provider that has no ARM Mac binary?

You activate the helper and run the install command with the provider address and the version, for example m1-terraform-provider-helper install hashicorp/vault -v v2.10.0. If the built-in build command for that provider is wrong, you supply your own with the build-command flag.

### Why does terraform init fail after installing a provider locally?

The checksums in the existing lock file belong to the previously installed darwin_amd64 provider, while the locally compiled darwin_arm64 provider has a different checksum. The README says to use the lockfile upgrade command to add the checksum of the local provider to the lock file.

### Does the helper work with OpenTofu as well as Terraform?

Yes. The tool manages installation and compilation for Terraform and OpenTofu providers, it prefers terraform when both are installed and can be forced with the iac-tool flag, and it falls back to the OpenTofu plugin directory and registry when only tofu is present.

## Sources

- [Issues](https://github.com/kreuzwerker/m1-terraform-provider-helper/issues)
- [kreuzwerker/m1-terraform-provider-helper on GitHub](https://github.com/kreuzwerker/m1-terraform-provider-helper)
- [License: MIT](https://github.com/kreuzwerker/m1-terraform-provider-helper/blob/main/LICENSE)
- [README](https://github.com/kreuzwerker/m1-terraform-provider-helper/blob/main/README.md)
- [Releases](https://github.com/kreuzwerker/m1-terraform-provider-helper/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kreuzwerker-m1-terraform-provider-helper