OpenTofu vs. Terraform: welches IaC-Tool wirklich trägt
Lizenzwechsel und IBM-Übernahme haben OpenTofu zum ernsten Terraform-Fork gemacht. Was beide Tools trennt und worauf es in DACH wirklich ankommt.
Seit Terraform unter eine restriktivere Lizenz gewechselt ist und HashiCorp zu IBM gehört, muss jedes Team mit Terraform-Code OpenTofu ernsthaft prüfen: quelloffen unter MPL 2.0, betrieben von der Linux Foundation. 2026 geht es deshalb nicht um ein pauschal besseres Tool, sondern um den passenden Abgleich von Betrieb, Compliance und Lieferkette.
Das Wichtigste in Kürze
- Die Lizenz ist der Auslöser, nicht ein Feature: Terraform liegt seit Version 1.6 unter der Business Source License, OpenTofu unter MPL 2.0 bei der Linux Foundation. Für die große Mehrheit bestehender Konfigurationen ist der Wechsel ein Binary-Swap.
- 2026 laufen die Tools auseinander: OpenTofu hat native State-Verschlüsselung und provider-definierte Funktionen, Terraform hat ephemere Werte und HCP Stacks. Bei HCL-Syntax und State-Format bleibt die Parität.
- Die DACH-Entscheidung ist Governance, nicht CLI: NIS2-Lieferkette, DORA-Drittparteienrisiko und Vendor-Konzentration wiegen für viele schwerer als eine einzelne Kommandozeilen-Funktion.
Verwandt:KI-Souveränität beginnt bei der Infrastruktur / Cloud-native reift mit Kubernetes 1.34
Warum aus einer Lizenz eine Architekturfrage wurde
Im August 2023 hat HashiCorp die Lizenz von Terraform von der Mozilla Public License auf die Business Source License umgestellt. Die BSL untersagt den Einsatz in direktem Wettbewerb zu HashiCorps eigenen Produkten und wird erst vier Jahre nach jedem Release wieder zu echtem Open Source. Für reine Endanwender wirkt das zunächst wie eine Fußnote. Für jeden, der Terraform in ein Produkt, eine Plattform oder einen Managed Service einbettet, entsteht damit ein rechtliches Risiko.
Die Reaktion kam schnell. Ein Bündnis aus Anbietern und Community hat Terraform 1.5, die letzte MPL-Version, geforkt. Aus OpenTF wurde OpenTofu, im September 2023 unter dem Dach der Linux Foundation, seit April 2025 zusätzlich in der CNCF. Parallel hat IBM HashiCorp übernommen, für umgerechnet rund 5,9 Milliarden Euro, abgeschlossen Ende 2024. Damit steht hinter Terraform heute ein einzelner großer Anbieter und hinter OpenTofu eine Stiftung mit Mehrparteien-Steuerung. Für Teams mit Governance-Auflagen ist diese Trägerstruktur ein zentrales Entscheidungskriterium.
Was ist OpenTofu? OpenTofu ist ein quelloffener Fork von Terraform unter der MPL 2.0, abgespalten von der letzten frei lizenzierten Terraform-Version. Das Projekt wird von einem Technical Steering Committee unter der Linux Foundation gesteuert, kein einzelnes Unternehmen kontrolliert die Roadmap. Die Kommandozeile, die HCL-Sprache und das State-Format sind weitgehend kompatibel zu Terraform.
Wo OpenTofu und Terraform auseinanderlaufen
Bis 2025 ließ sich OpenTofu vor allem als lizenzsaubere Terraform-Alternative beschreiben. Seitdem haben sich die Projekte funktional getrennt. Beide Projekte veröffentlichen eigene Releases in eigenem Takt, die Funktionsprofile entfernen sich. OpenTofu steht aktuell bei Version 1.9, Terraform bei 1.14. Wer eine Entscheidung trifft, sollte sie an konkreten Funktionen, Lizenzfolgen und Betriebsabhängigkeiten festmachen.
Der wichtigste Unterschied ist die State-Verschlüsselung. OpenTofu verschlüsselt State- und Plan-Dateien clientseitig, bevor sie die Maschine verlassen, optional gegen einen KMS-Provider. Terraform überlässt das traditionell dem Backend, etwa der serverseitigen Verschlüsselung eines S3-Buckets. Wer regulierte Daten im State führt, bekommt mit OpenTofu eine zusätzliche Schutzschicht. Das ist relevant, weil Secrets dort in der Praxis öfter landen als geplant. Dazu kommen provider-definierte Funktionen und eine frühere Variablen-Auswertung auf OpenTofu-Seite. Terraform setzt auf ephemere Werte und die enge Integration in HCP Stacks.
| Kriterium | OpenTofu | Terraform |
|---|---|---|
| Lizenz | MPL 2.0, OSI-anerkannt | BSL 1.1, nicht OSI-anerkannt |
| Steuerung | Linux Foundation, Mehrparteien | IBM / HashiCorp, Single-Vendor |
| State-Verschlüsselung | nativ, clientseitig | über Backend |
| Eigene Stärken | provider-definierte Funktionen, frühe Variablen-Auswertung | ephemere Werte, HCP Stacks |
| HCL und State-Format | kompatibel | Referenz |
Die Tabelle markiert die Trennlinie: OpenTofu ist stärker bei Offenheit und State-Sicherheit, Terraform bei der eigenen Cloud-Plattform. Eine pauschale Empfehlung ergibt sich daraus nicht. Wer kein HCP Stacks nutzt, verliert mit dem Wechsel nichts an Funktion. Wer es nutzt, hat eine Abhängigkeit, die zuerst abgelöst werden muss.
Migration: was der Wechsel praktisch kostet
Der Wechsel ist technisch meist überschaubar. State-Format, HCL und das Provider-Protokoll sind kompatibel, in vielen bestehenden Konfigurationen genügt der Austausch des Binaries. Aus terraform init wird tofu init; viele Abläufe bleiben unverändert. Das Risiko liegt nicht im Code, sondern an den Rändern: in Abhängigkeiten von Terraform Cloud, HCP Stacks oder hauseigenen Wrappern, die auf den HashiCorp-Stack zugeschnitten sind.
Wer migriert, sollte nicht das ganze Estate auf einmal umstellen. Erst ein Modul, dann ein State, anschließend ein sauberer Plan-Diff vor und nach dem Swap. Diese Reihenfolge senkt das Risiko, dass ein eigentlich kleiner Toolwechsel zum Betriebsproblem wird. Die Kostenseite ist dabei selten der Treiber, beide Tools sind kostenlos verfügbar; Kosten entstehen vor allem durch die Plattformen und Integrationen darum herum.
Was für den Wechsel spricht
- Lizenzklarheit für Produkte und Managed Services
- Native State-Verschlüsselung ohne Backend-Umweg
- Mehrparteien-Governance statt Single-Vendor-Roadmap
Was dagegen spricht
- HCP-Stacks-Bindung muss zuerst abgelöst werden
- Beschaffung, die HashiCorp als Vendor vorschreibt
- Tooling-Kette mit fest verdrahteten Terraform-Annahmen
Die DACH-Entscheidung: NIS2, DORA und die Lieferkette
In der DACH-Region verschiebt sich die Frage von der Technik zur Governance. NIS2 verlangt eine dokumentierte Sorgfaltspflicht über die Software-Lieferkette, DORA adressiert für den Finanzsektor das Drittparteienrisiko und ausdrücklich das Konzentrationsrisiko bei IKT-Dienstleistern. Ein Infrastruktur-Werkzeug unter Stiftungssteuerung, quelloffen und ohne einzelnen kommerziellen Eigentümer, ist in dieser Logik leichter zu verteidigen als ein Produkt, dessen Lizenz und Roadmap an einem Vendor hängen.
Das heißt nicht, dass OpenTofu automatisch die compliance-konforme Wahl ist. Es heißt, dass die Lizenz- und Steuerungsfrage in einem NIS2- oder DORA-Audit auf den Tisch kommt und beantwortet sein will. Die Marktbewegung ist dabei noch verhalten: Rund 12 Prozent der IaC-Praktiker setzen OpenTofu bereits ein, etwa ein Viertel prüft oder erweitert den Einsatz. Das ist kein Erdrutsch, aber ein stetiger Zug in eine Richtung.
Umgekehrt gibt es klare Gründe, bei Terraform zu bleiben. Wer auf HCP Stacks aufbaut, in einer IBM-Cloud-Pak-Umgebung arbeitet oder eine Beschaffung hat, die HashiCorp als Vendor ausdrücklich verlangt, fährt mit Terraform geradliniger. Die Entscheidung ist keine Glaubensfrage. Sie ist eine Abwägung zwischen Lizenzrisiko, Lieferketten-Governance und konkreten Plattform-Abhängigkeiten, und die fällt je nach Haus unterschiedlich aus.
Häufige Fragen
Lässt sich Terraform ohne Umbau durch OpenTofu ersetzen?
Für die große Mehrheit der Konfigurationen ja. State-Format, HCL-Syntax und das Provider-Protokoll sind kompatibel, in der Praxis genügt meist der Austausch des Binaries. Reibung entsteht an Abhängigkeiten von Terraform Cloud, HCP Stacks oder hauseigenen Wrappern. Eine modulweise Migration mit Plan-Diff vor und nach dem Wechsel fängt die Randfälle ab.
Was genau ist mit der Terraform-Lizenz passiert?
HashiCorp hat Terraform im August 2023 von der MPL 2.0 auf die Business Source License 1.1 umgestellt. Die BSL schränkt den Einsatz in Konkurrenz zu HashiCorps Produkten ein und wird erst vier Jahre nach jedem Release wieder zu freiem Open Source. Das war der Auslöser für den OpenTofu-Fork.
Welche Funktionen hat OpenTofu, die Terraform fehlen?
Am sichtbarsten ist die native, clientseitige Verschlüsselung von State- und Plan-Dateien. Dazu kommen provider-definierte Funktionen und eine frühere Auswertung von Variablen. Terraform hat im Gegenzug eigene Funktionen wie ephemere Werte und die enge Anbindung an HCP Stacks. Die Kernsyntax bleibt auf beiden Seiten gleich.
Wann ist Terraform die bessere Wahl?
Wenn der Betrieb auf HCP Stacks aufbaut, in einer IBM-Cloud-Pak-Umgebung läuft oder die Beschaffung HashiCorp als Vendor vorschreibt. In diesen Fällen erzeugt ein Wechsel mehr Aufwand, als er an Lizenz- und Governance-Vorteil zurückgibt.
Was bedeutet die Wahl für NIS2- und DORA-Compliance?
NIS2 verlangt eine dokumentierte Sorgfalt über die Software-Lieferkette, DORA adressiert Drittparteien- und Konzentrationsrisiko bei IKT-Dienstleistern. Ein quelloffenes Werkzeug unter Stiftungssteuerung ist in einem Audit einfacher zu begründen als ein Single-Vendor-Produkt. Die Frage muss in beiden Fällen beantwortet sein, unabhängig vom gewählten Tool.
Bildquelle: Titelbild KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt
