TTerramantle
Get Started Free
OpenTofu

A private OpenTofu registry that treats OpenTofu as first class.

Most registry products lead with "Terraform" and treat OpenTofu as a checkbox. OpenTofu’s own documentation points teams needing a private registry towards community projects. If you moved to OpenTofu after the fork, you have probably felt both of those. This page is for you.

The gap

OpenTofu’s docs send you to community projects.

The registry protocol is identical between the two engines, but ecosystem attention is not. OpenTofu-specific capabilities like client-side state encryption and OCI-based distribution get treated as afterthoughts by tooling built Terraform-first. Terramantle is built to sit under an OpenTofu workflow as naturally as under a Terraform one, because to a registry they are the same protocol with different clients.

Same address, either engine

One source address, resolved identically under tofu and terraform.

There is no engine detection and no per-engine path. The same published module version resolves the same way whichever binary asks for it, which is exactly what you want when a team is mid-migration.

OpenTofu
# terraform block, OpenTofu binary
module "vpc" {
  source  = "registry.terramantle.dev/acme/vpc/aws"
  version = "~> 3.2"
}

# tofu init  -> resolves from Terramantle
Terraform
# identical block, Terraform binary
module "vpc" {
  source  = "registry.terramantle.dev/acme/vpc/aws"
  version = "~> 3.2"
}

# terraform init  -> resolves the same version
Moving in

Migrating from the public registry or HCP.

Republish your modules to Terramantle, then update the source address. Version constraints keep working because the registry protocol is the same one your CLI already speaks.

Before
module "vpc" {
  source  = "app.terraform.io/acme/vpc/aws"
  version = "~> 3.2"
}
After
module "vpc" {
  source  = "registry.terramantle.dev/acme/vpc/aws"
  version = "~> 3.2"
}

Publishing is keyless from CI over OIDC, so there are no long-lived registry tokens to rotate. If you run your own pipelines rather than a platform’s, see no runners, no agents for how that fits together.

FAQ

Does Terramantle work with OpenTofu without changes?

Yes. OpenTofu and Terraform share the same registry protocol. Point your module source at registry.terramantle.dev, add credentials, and tofu init works as expected. The http state backend configuration is identical between the two tools.

Is this an OpenTofu fork or a Terraform tool with OpenTofu bolted on?

Neither. Terramantle is a registry, not an engine. It implements the Terraform Registry Protocol v1, which OpenTofu and Terraform both speak. It does not ship or wrap either binary, so there is nothing to fork and nothing that treats one engine as the default.

Can the same module be consumed by both tofu and terraform?

Yes. The source address is identical and the protocol is identical, so the same published module version resolves the same way under both. Teams mid-migration can run both against one registry without maintaining two copies.

Do you support the OpenTofu registry for providers too?

Yes. When Terramantle mirrors or resolves upstream providers it recognises both registry.terraform.io and registry.opentofu.org as sources, so an OpenTofu-first workspace resolves providers from the OpenTofu registry rather than being quietly routed through the Terraform one.

What about OpenTofu-only features like state encryption?

State encryption is a client-side OpenTofu feature and stays entirely in your hands. Terramantle stores state as your backend sends it, so if you enable OpenTofu state encryption it works unchanged. Terramantle does not need to know your keys and never sees them.

Last reviewed