TTerramantle
Get Started Free
Providers

A self-hosted provider registry, not just a module one.

You built an internal provider, or you need to mirror one privately, and you have hit the wall that most OSS registries and half the guides online are modules-only. Providers are the harder half of the protocol, and they are the half that gets skipped. This is how to host them properly.

Why providers are harder

Binaries, signing, and a stricter protocol.

A module is text you tar up. A provider is compiled binaries, one per platform, each checksummed, with the checksums GPG-signed by a key Terraform trusts. The registry serves the correct binary for the caller platform, the SHA256SUMS file, and its signature, and Terraform verifies the checksum and the signature before it installs. There is real cryptography in the path, and getting the signing wrong does not fail loudly, it fails at install time on someone else machine.

The DIY route

Static hosting works, until it does not.

Be fair to the simple option, because for a single provider it is genuinely fine. A filesystem mirror or an S3 bucket of binaries plus a discovery document will serve a provider, and if that is all you need, do that. What it does not give you is the stuff that starts mattering at the second team and the second provider.

Static hosting handles
  • Serving one provider to people who already trust the key.
  • A fixed set of platforms you build by hand.
  • The happy path, once, for one team.
Where it hurts
  • Signing-key management is now entirely your problem.
  • No access control on who can pull which provider.
  • No versioned discovery, so constraints do not resolve.
  • No audit of who published or consumed what.
OSS options

Which open-source registries actually do providers.

Not all of them. Several well-known OSS registries are modules-only, which is exactly the wall this page is about. Terralist and Terrakube both handle providers as well as modules, with different tradeoffs and different maintenance stories. If a supported product is not where you want to spend, the honest OSS review compares them on scope, auth, storage, and how alive each project is.

The full comparison, with GitHub activity and dates, is in the OSS registry review.

With Terramantle

Publish a signed provider, or mirror one.

Terramantle serves the provider protocol for providers you publish and for upstream providers you mirror behind your own registry: the per-platform binaries, the SHA256SUMS, the signature, versioned discovery, and access control, all behind your authentication. Publishing over OIDC means no long-lived registry token, the same keyless flow that works for modules. The build-and-sign-for-you pipeline, where you hand over source and get a signed provider back, is being rolled out carefully and is not generally available yet, so treat that part as coming soon rather than shipping.

Provider registry FAQ

Why is hosting a provider harder than hosting a module?

A module is a tarball of text. A provider is a set of compiled binaries, one per OS and architecture, each of which has to be checksummed, and the checksums have to be GPG-signed with a key Terraform will trust. The registry has to serve the right binary for the caller platform, plus the SHA256SUMS file and its signature, and Terraform verifies all of it before it installs anything. It is a stricter protocol with real cryptography in the path.

Can I just put provider binaries in an S3 bucket?

You can, and a filesystem or network mirror genuinely works for the simple case. Where it hurts is everything the registry protocol gives you for free: signing-key management becomes your problem, there is no access control on who pulls what, and there is no versioned discovery, so consumers cannot ask for a version constraint and get the right build. It is fine until you have more than one team or more than one provider.

Does Terramantle build providers for me?

Serving and mirroring providers is available today: publish a signed provider and Terramantle serves the protocol for it, or mirror upstream providers behind your own registry. The build-and-sign-it-for-you pipeline, where you hand over source and get a signed provider back, is being rolled out carefully and is not generally available yet. We would rather gate that than ship an unproven path for something that signs binaries.

Does it work with OpenTofu providers?

Yes. The provider protocol is shared, and Terramantle recognises both the Terraform and OpenTofu upstream registries, so an OpenTofu-first workspace resolves providers from the OpenTofu registry rather than being routed through the Terraform one. See the OpenTofu page for how the two engines are treated as equals.

Last reviewed