Wer liefert deine Provider? Der Vertriebsweg von Terraform und OpenTofu

25.07.2026

Bei Terraform und OpenTofu ist die Provider-Binary oft identisch, der Vertriebsweg aber nicht. Warum die Registry der eigentliche Lock-in ist.

Inhaltsverzeichnis

Derselbe Provider, zwei Registries

Wenn du von Terraform auf OpenTofu wechselst, passiert etwas Unscheinbares, das kaum jemand genauer ansieht: Dein Provider kommt danach aus einer anderen Registry. Vorher aus registry.terraform.io, nachher aus registry.opentofu.org. Die heruntergeladene Binary ist dabei oft byte-identisch.

Genau das macht die Sache interessant. Wenn das Artefakt dasselbe ist, worin liegt dann überhaupt der Unterschied? Die Antwort ist der Kern dieses Beitrags: Der Unterschied liegt nicht im Code, sondern im Vertriebsweg, also darin, wer dir diesen Provider liefert und zu welchen Bedingungen. Und das ist die subtilste Form von Vendor-Lock-in, die es gibt.

Was eine Provider-Registry wirklich ist

Ein verbreitetes Missverständnis: Eine Registry sei ein Code-Repository. Ist sie nicht. Eine Provider-Registry ist ein Vertriebsindex. Sie beantwortet nur zwei Fragen: Welche Versionen eines Providers gibt es, und wo liegt die Binary samt gültiger Prüfsummen und Signatur.

Deshalb ist die Registry-Adresse auch Teil der Provider-Identität. In der .terraform.lock.hcl heißt der Schlüssel nicht hcloud, sondern voll qualifiziert:

provider "registry.opentofu.org/hetznercloud/hcloud" {
  version = "1.66.0"
  ...
}

Der Provider-Name allein ist nicht eindeutig. Erst die Registry davor macht ihn es.

Der Beweis: gleicher Code, anderer Kanal

Das lässt sich zeigen, statt behaupten. Zieht man denselben Provider einmal über Terraform und einmal über OpenTofu, stehen anschließend beide Einträge im selben Lock-File, mit identischem Hash:

provider "registry.opentofu.org/hetznercloud/hcloud" {
  version = "1.66.0"
  hashes  = ["h1:EtYB/KjPN2cIJa6hpEaVc8q/3yf6e9IT6/uAybUGqps=", ...]
}

provider "registry.terraform.io/hetznercloud/hcloud" {
  version = "1.66.0"
  hashes  = ["h1:EtYB/KjPN2cIJa6hpEaVc8q/3yf6e9IT6/uAybUGqps=", ...]
}

Der h1:-Hash ist in beiden Blöcken derselbe. Und auf der Platte sind die heruntergeladenen Binaries bitgleich:

sha256sum \
  .terraform/providers/registry.terraform.io/hetznercloud/hcloud/1.66.0/linux_amd64/terraform-provider-hcloud_v1.66.0 \
  .terraform/providers/registry.opentofu.org/hetznercloud/hcloud/1.66.0/linux_amd64/terraform-provider-hcloud_v1.66.0

Beide Zeilen liefern dieselbe Prüfsumme:

63d2c1089b77db4f8009e1787b041fd9ae14687da25f50945b6be9cfc4daa00d
63d2c1089b77db4f8009e1787b041fd9ae14687da25f50945b6be9cfc4daa00d

Technisch identisches Artefakt, zwei verschiedene Bezugswege. Der Unterschied liegt also eine Ebene höher als der Code.

Wer den Kanal betreibt

Genau hier trennen sich Terraform und OpenTofu, und zwar nicht zufällig.

registry.terraform.io gehört HashiCorp, seit 2025 Teil von IBM. registry.opentofu.org gehört dem OpenTofu-Projekt unter dem Dach der Linux Foundation. Das ist derselbe Governance-Test wie bei der Lizenz, nur eine Ebene tiefer: Hält ein einzelnes Unternehmen den Stift, oder eine neutrale Stiftung?

Dass OpenTofu überhaupt eine eigene Registry brauchte, ist kein Feature-Wunsch, sondern eine Notwendigkeit. Im Zuge des Lizenzwechsels wurde die Terraform-Registry für fremde Software geschlossen. Das OpenTofu-Team beschreibt es in Building the OpenTofu Registry unmissverständlich:

Alongside the Terraform license change, HashiCorp closed the Terraform Registry for software that isn’t Terraform, so using it as a source of data for the OpenTofu Registry was out of the question.

Der Bezugsweg für die Werkzeuge wurde also aktiv verschlossen. Nicht der Code, nicht das Datenformat, sondern der Kanal.

Wie die OpenTofu-Registry aufgebaut ist

Die Antwort des Projekts darauf ist bemerkenswert souverän konstruiert, und der Aufbau wurde offen in mehreren RFCs diskutiert, unter anderem RFC #741 zum Homebrew-artigen Design und RFC #724 zur umgesetzten Variante.

Die OpenTofu-Registry ist bewusst dünn gebaut:

  1. Sie ist im Kern ein Metadaten-Katalog auf GitHub, ähnlich der Idee hinter Homebrew.
  2. Die Antworten werden als statische Dateien vorgeneriert und liegen auf einem Cloudflare-R2-Bucket. Keine Datenbank, kaum Ausfallfläche.
  3. Die eigentlichen Provider-Binaries zieht sie direkt von den GitHub-Releases der Provider-Autoren und prüft dabei Prüfsumme und Signatur.

Das Projekt formuliert es so:

OpenTofu then downloads the provider from the supplied GitHub releases URL and verifies the checksum and signature.

Der entscheidende Effekt: Die Registry schiebt sich nicht als kontrollierender Mittelsmann zwischen dich und den Hersteller. Sie verweist auf die signierte Original-Quelle, statt sie zu besitzen.

Der eigentliche Lock-in liegt im Vertriebsweg

Fassen wir zusammen, warum das mehr ist als eine URL-Kosmetik.

Ein einzelner Betreiber, dem die Registry gehört, kann die Bedingungen ändern, den Zugriff drosseln, geoblocken, eine Authentifizierung verlangen oder einen Provider entfernen. Genau das ist bei der Terraform-Registry passiert: Der Zugang für fremde Software wurde geschlossen. Bei einem stiftungsgetragenen, quelloffen betriebenen Index fehlt dieser einzelne Hebel.

Das ist Vendor-Lock-in in seiner leisesten Form. Nicht das Dateiformat sperrt dich ein, nicht die API und nicht einmal die Lizenz des Codes. Sondern der Weg, über den du die Werkzeuge überhaupt beziehst. Selbst wenn die Binary frei und identisch ist: Wenn der einzige Bezugsweg einem Unternehmen gehört, das die Regeln jederzeit neu schreiben kann, ist deine Lieferkette nicht souverän.

Den Kanal selbst in die Hand nehmen

Der beste Teil: Du bist diesem Kanal nicht ausgeliefert. OpenTofu (wie Terraform) erlaubt einen lokalen Provider-Mirror. Damit hältst du die Artefakte selbst und wirst von jeder Registry unabhängig.

Zuerst den Mirror befüllen, bei Bedarf für mehrere Zielplattformen:

tofu providers mirror -platform=linux_amd64 -platform=darwin_arm64 ./mirror

Dann OpenTofu in der CLI-Konfiguration (.tofurc) anweisen, ausschließlich aus diesem Mirror zu installieren:

provider_installation {
  filesystem_mirror {
    path    = "/pfad/zum/mirror"
    include = ["*/*/*"]
  }
  direct {
    exclude = ["*/*/*"]
  }
}

Die Probe aufs Exempel: ein init ganz ohne Netz. Im Container lässt sich das erzwingen:

docker run --rm --network none -v "$(pwd):/app" \
  ghcr.io/opentofu/opentofu:latest -chdir=/app init

Wenn das durchläuft, hast du bewiesen, dass dein Stack betreibbar bleibt, auch wenn morgen eine Registry ihre Bedingungen ändert oder ganz verschwindet. Das ist Souveränität im Wortsinn: nicht die Lizenz allein, sondern die technische Fähigkeit, unabhängig zu bleiben.

Fazit

Bei Terraform und OpenTofu ist der Provider-Code oft identisch. Der Unterschied liegt im Vertriebsweg:

  1. Die Registry ist kein Code-Repo, sondern ein Vertriebsindex, und ihre Adresse ist Teil der Provider-Identität.
  2. Derselbe Provider aus beiden Registries hat denselben Hash und dieselbe Binary. Der Unterschied ist Governance, nicht Technik.
  3. Die Terraform-Registry gehört einem Unternehmen und wurde für fremde Software geschlossen. Die OpenTofu-Registry gehört der Linux Foundation und verweist auf die signierten Upstream-Releases.
  4. Mit einem lokalen Mirror machst du dich von jeder Registry unabhängig, nachweisbar per Offline-Init.

Das ist genau die Zwei-Säulen-Idee in der Praxis: tiefes technisches Verständnis (der Mirror, das Offline-Init) im Dienst von echter Unabhängigkeit (eine offene, stiftungsgetragene Lieferkette). Wer nur auf die Lizenz schaut, übersieht den Kanal. Wer nur auf den Befehl schaut, hinterfragt ihn nicht.

Die begriffliche Grundlage dazu steht im Beitrag Open Source ist mehr als sichtbarer Quellcode, und wie der Umstieg praktisch abläuft, zeigt Terraform nach OpenTofu migrieren.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.