Wer liefert deine Provider? Der Vertriebsweg von Terraform und OpenTofu

25.07.2026

Thema: alle Beiträge zu OpenTofu

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.67.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. Ein Hinweis vorweg, weil es oft falsch dargestellt wird: Aktuelle OpenTofu-Versionen ersetzen den Eintrag beim Wechsel, sie stellen keinen zweiten daneben. Aus dem Schlüssel mit registry.terraform.io wird der Schlüssel mit registry.opentofu.org, der alte verschwindet. Genau deshalb fällt der Wechsel des Bezugswegs kaum jemandem auf.

Für den Vergleich hebst du dir also die Fassung vor dem Wechsel auf, etwa als Kopie oder direkt aus der Git-Historie. Legt man beide nebeneinander, steht dort derselbe Hash:

# vorher, erzeugt von Terraform
provider "registry.terraform.io/hetznercloud/hcloud" {
  version = "1.67.0"
  hashes  = ["h1:lNalP0KjmQmLybj4lRUuvnsNasLdCWz18tCwrz8IKOI=", ...]
}

# nachher, erzeugt von OpenTofu
provider "registry.opentofu.org/hetznercloud/hcloud" {
  version = "1.67.0"
  hashes  = ["h1:lNalP0KjmQmLybj4lRUuvnsNasLdCWz18tCwrz8IKOI=", ...]
}

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

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

Beide Zeilen liefern dieselbe Prüfsumme:

598a090eb8fbf5a29109005a8a701e3074497bf5c26ca94506bc1c46d24f420f
598a090eb8fbf5a29109005a8a701e3074497bf5c26ca94506bc1c46d24f420f

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

Ein Nebeneffekt: OpenTofus Lock-File ist plattformübergreifend

Wer die beiden Fassungen genauer vergleicht, entdeckt einen zweiten, sehr praktischen Unterschied. Nimm denselben Provider, hier in Version 1.67.0, und zähl die Hashes in beiden Lock-Files. Terraform schreibt genau einen h1:-Hash, OpenTofu dreizehn. Die zh:-Hashes dagegen sind bei beiden identisch.

# Terraform: 1x h1, 13x zh
provider "registry.terraform.io/hetznercloud/hcloud" {
  hashes = [
    "h1:lNalP0KjmQmLybj4lRUuvnsNasLdCWz18tCwrz8IKOI=",
    "zh:0435a27d...",  # plus 12 weitere zh
  ]
}

# OpenTofu: 13x h1, 13x zh
provider "registry.opentofu.org/hetznercloud/hcloud" {
  hashes = [
    "h1:1RpfvF8u...", "h1:7gV0NahM...",  # 13 h1, einer pro Plattform
    "h1:lNalP0Kj...",                     # derselbe wie bei Terraform
    "zh:0435a27d...",  # dieselben 13 zh
  ]
}

Der Grund liegt in den zwei Hash-Typen:

Und jetzt der Unterschied: Terraforms Registry liefert keine h1:-Hashes. Terraform berechnet einen h1: nur, indem es eine Plattform selbst herunterlädt und entpackt, standardmäßig also genau eine, für dein System. Die OpenTofu-Registry liefert die h1:-Hashes für alle Plattformen gleich mit.

Das Ergebnis ist handfest: OpenTofus Lock-File verifiziert von Haus aus auf jeder Plattform. Der klassische Terraform-Schmerz, dass eine auf dem Mac erzeugte .terraform.lock.hcl in der Linux-CI mit „checksums recorded in the dependency lock file” bricht, entfällt. Kein Nachziehen per terraform providers lock -platform=... nötig.

Auch das passt genau zum Thema: Der Vorteil steckt nicht im Code, sondern in dem, was die Registry liefert. Und der eine Hash, den Terraform hat, steht auch in OpenTofus Liste, was den Beweis von oben ein zweites Mal bestätigt.

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

Und du bist diesem Kanal nicht ausgeliefert. OpenTofu erlaubt, wie Terraform, einen lokalen Provider-Mirror als Rückfallebene. 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.

Ein wichtiger Vorbehalt gegen die naheliegende Fehlschlussfolgerung: Der Mirror ist eine Rückversicherung, keine tägliche Arbeitsweise. Und es gibt ihn für Terraform genauso, er ist also kein Alleinstellungsmerkmal von OpenTofu. Der eigentliche Unterschied liegt nicht im Werkzeug, sondern in der Wahrscheinlichkeit, es je zu brauchen.

Und genau die ist bei OpenTofu deutlich kleiner. Der OpenTofu-Kanal gehört keiner einzelnen Firma, die ihn schließen oder verengen kann: die Governance liegt bei der Linux Foundation, die Binaries kommen aus den signierten Upstream-Releases. Der Terraform-Kanal gehört IBM und wurde für fremde Software bereits einmal geschlossen. Der Mirror ist bei beiden der Feuerlöscher. Bei OpenTofu ist nur die Brandgefahr kleiner.

Das ist Souveränität im Wortsinn, und sie besteht aus beidem: Die offene Governance senkt die Wahrscheinlichkeit, dass es überhaupt brennt, und das technische Können hält den Feuerlöscher bereit, falls es doch passiert.

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. OpenTofu liefert im Lock-File sogar die Hashes für alle Plattformen mit, Terraform nur für deine. Das macht OpenTofus Lock-File von Haus aus plattformübergreifend.
  4. 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.
  5. Der lokale Mirror ist die Rückversicherung für den Ernstfall, nachweisbar per Offline-Init. Ihn gibt es für beide Tools. Entscheidend ist die Wahrscheinlichkeit: Bei OpenTofu brauchst du ihn seltener, weil der Kanal keiner einzelnen Firma gehört.

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.

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

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.