OpenTofu erklärt: der Terraform-Fork, die Migration und ob sich der Wechsel lohnt

Öffnen Sie heute ein Terraform-Modul, und Sie stehen vor einer Frage, die es vor drei Jahren noch nicht gab: Ist die Binärdatei, die diesen Code ausführt, terraform, oder ist es tofu? IBM hat die HashiCorp-Übernahme am 27. Februar 2025 für 6,4 Milliarden Dollar abgeschlossen. OpenTofu wurde ein CNCF-Sandbox-Projekt am 23. April 2025, und der Migrationspfad zwischen den beiden Tools ist inzwischen offiziell dokumentiert. Die Entscheidung ist nicht mehr hypothetisch.

Dieser Artikel ist aus der Perspektive des Infrastrukturbetriebs geschrieben, nicht aus der einer verwalteten Terraform-Plattform. Ziel ist es, die tatsächlichen Migrationskosten vom Lizenz- und Governance-Lärm zu trennen. Das heißt, ich kann offen sagen, was bei der Migration kaputtgeht, welche Governance-Fragen berechtigt sind und in welchen Fällen Terraform die richtige Wahl bleibt.

Dieser Artikel behandelt vier Dinge: was OpenTofu 2026 ist, welche Funktionen Terraform fehlen, wie die Migration in der Praxis aussieht, und eine klare Empfehlung für die gängigen Entscheidungssituationen.

Die Kurzfassung

• OpenTofu ist ein Open-Source-Fork von Terraform unter MPL-2.0-Lizenz, gehostet von der Linux Foundation, und seit dem 23. April 2025 ein CNCF-Sandbox-Projekt. Es wurde von Terraform 1.5.x abgespalten, nachdem HashiCorp Terraform im August 2023 auf die Business Source License umgestellt hatte.
• Stand 26. Juli 2026 ist das aktuelle Wartungsrelease v1.12.5; das GitHub-Repository hat mehr als 29.000 Sterne, und die offizielle Projektseite von OpenTofu listet mehr als 3.900 Provider und mehr als 23.600 Module auf.
• Es bietet Funktionen, die nur OpenTofu hat oder bei denen OpenTofu führend ist und die Terraform derzeit nicht auf gleiche Weise bietet: clientseitige State- und Plan-Verschlüsselung, provider for_each, die frühe Variablenauswertung, das Meta-Argument enabled und dynamisches prevent_destroy. Ephemere Ressourcen sind nicht exklusiv für OpenTofu; Terraform unterstützt sie seit 1.10.
• Für ein kleines Terraform-1.5.x-Projekt mit lokalem oder S3-State kann der einfache Weg eine kurze, reversible Migration sein. CI/CD-Referenzen, HCP-spezifische Workflows und Änderungen an der Abhängigkeits-Lock-Datei sind die Stellen, an denen der Aufwand wächst.
• Für ein neues IaC-Projekt 2026 beginnen Sie mit OpenTofu. Bei einer bestehenden Terraform-Bereitstellung wechseln Sie, wenn die BSL einschränkt, wenn Sie eine Funktion brauchen, die OpenTofu hat und Terraform nicht, oder wenn die von IBM kontrollierte Roadmap ein echtes Anliegen ist. Andernfalls ist das Kosten-Nutzen-Verhältnis dünn.

Was OpenTofu 2026 ist

OpenTofu ist ein Open-Source-Fork von Terraform, gehostet von der Linux Foundation, am 23. April 2025 als Sandbox-Projekt in die CNCF aufgenommen und unter der Mozilla Public License 2.0 lizenziert. Die Binärdatei heißt tofu. Die Konfigurationssprache ist HCL, dasselbe HCL, das Terraform verwendet. Bei den meisten einfachen bis mittelgroßen Projekten läuft eine bestehende Terraform-Codebasis unverändert auf OpenTofu.

Der Fork begann im August 2023, nachdem HashiCorp Terraform von MPL 2.0 auf die Business Source License 1.1 am 10. August 2023 umstellte. Die BSL ist "source-available" statt OSI-zertifiziert und schränkt den Produktiveinsatz ein, der "mit HashiCorps kommerziellen Angeboten konkurriert". Innerhalb von fünf Tagen wurde das OpenTF Manifesto veröffentlicht und ein Fork angekündigt. Die Ankündigung der Linux Foundation stellte OpenTofu am 20. September 2023 offiziell vor.

Die Ankündigung der Linux Foundation nannte Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver und Terramate als Gründungsunterstützer, mit mindestens 18 Ingenieuren, die sich für mindestens fünf Jahre in Vollzeit verpflichteten. OpenTofu wurde von Terraform 1.5.x abgespalten, der letzten MPL-2.0-Version.

Wo das Projekt heute steht: v1.12.5 ist das aktuelle Wartungsrelease, und die offizielle Website listet mehr als 3.900 Provider und mehr als 23.600 Module. Die Akzeptanzsignale beschränken sich nicht mehr nur auf den anfänglichen Protest-Fork-Schwung: Eine Fidelity-Migrations-Fallstudie beschreibt ein Programm mit mehr als 50.000 State-Dateien und vier Millionen Ressourcen.

Der relevante geschäftliche Kontext: IBM hat die Übernahme von HashiCorp am 27. Februar 2025 für 6,4 Milliarden Dollar abgeschlossen. Die Roadmap von Terraform wird nun innerhalb eines viel größeren Unternehmensanbieters festgelegt. Das ist für Nutzer nicht automatisch gut oder schlecht, aber es ist Teil der Überlegungen, die Teams 2026 anstellen.

Wo sich OpenTofu von Terraform unterscheidet

Seit dem Fork haben die beiden Projekte unterschiedliche Funktionswege eingeschlagen. Die folgende Tabelle ist die Kurzfassung; die anschließenden Hinweise erklären, was jeder Unterschied für die Praxis bedeutet.

Clientseitige State-Verschlüsselung (v1.7.0, 30. April 2024). OpenTofu kann State- und Plan-Dateien direkt im Tool mit PBKDF2, AWS KMS, GCP KMS oder OpenBao verschlüsseln. Terraform überlässt die Verschlüsselung im Ruhezustand meist dem gewählten Backend, während der lokale State im Klartext bleibt. Die clientseitige Verschlüsselung von OpenTofu kann ein gestohlenes State-Objekt oder einen zwischengespeicherten Plan schützen, sofern der Entschlüsselungscode nicht mit ihm zusammen offengelegt wird. Sie ersetzt weder TLS noch Backend-Zugriffskontrollen noch Disziplin bei der Geheimnisverwaltung.

Die Konfiguration sieht ungefähr so aus:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

Anbieter for_each (v1.9). Sie können Provider-Konfigurationen genauso iterieren wie Ressourcen. Bei Multi-Region- oder Multi-Account-Setups entfällt damit eine ganze Klasse langjähriger Workarounds. Sie müssen nicht mehr für jede Region manuell einen aliasierten Provider anlegen; ein einziger, aus einer Map gespeister Block genügt.

Frühe Variablenauswertung (v1.8). Auf Variablen kann jetzt an Stellen verwiesen werden, die zuvor eingeschränkt waren, einschließlich Backend- und Modul-Source-Argumenten. Das ist nützlich, wenn ein einziges Root-Modul mehrere Umgebungen steuert, die sich nur durch einen kleinen Satz von Variablen unterscheiden.

Ephemere Ressourcen und das enabled Meta-Argument (v1.11.0, 9. Dezember 2025). OpenTofu 1.11 hat ephemere Ressourcen und das Meta-Argument enabled . Ephemere Ressourcen existieren nur innerhalb eines einzigen Plan/Apply-Zyklus und werden nicht im State gespeichert, was für kurzlebige Zugangsdaten nützlich ist. Sie sind nicht exklusiv für OpenTofu: Terraform hat sie in 1.10 eingeführt und in 1.11 Write-Only-Argumente hinzugefügt. Die OpenTofu-spezifische Fähigkeit ist hier enabled, das einen Ressourcenblock über einen Ausdruck umschaltet, ohne die Klimmzüge mit count count-basierten Bedingungen.

Dynamisches prevent_destroy (v1.12). Terraforms prevent_destroy akzeptiert nur literale Werte. OpenTofu 1.12 lässt Sie ihn berechnen, sodass ein Modul Staging löschbar halten und gleichzeitig Produktion schützen kann.

Die Lizenzzeile ist der strukturelle Unterschied, der nicht als Funktion auftaucht. MPL 2.0 ist OSI-zertifiziert und Copyleft auf Dateiebene. Terraforms BSL-1.1-Lizenz ist "source-available", enthält eine zusätzliche Nutzungsbeschränkung und wechselt vier Jahre nach Veröffentlichung jedes lizenzierten Werks zu MPL 2.0. Für die meisten Teams ist der praktische Effekt gering; für Anbieter, die etwas nah an HashiCorps kommerziellen Angeboten bauen, ist genau das der Grund, warum es den Fork gibt.

Migration: Was wirklich kaputtgeht

Der offizielle Migrationsleitfaden ist bewusst kurz und reversibel gehalten: State und Code sichern, OpenTofu installieren, führen Sie tofu init aus, vergleichen Sie tofu plan und testen eine kleine Änderung. Die schwierigen Teile sind nicht die Befehle. Es sind die umgebenden CI/CD-Referenzen, HCP-spezifischen Workflows, Änderungen an der Abhängigkeits-Lock-Datei und die organisatorische Prüfung, die mit der Einführung eines Forks einhergeht.

Der einfache Weg

Für ein Projekt, das kein HCP Terraform verwendet und nicht Tausende Pipeline-Referenzen auf terraform hat, ist die Migration unkompliziert.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan sollte mit dem von Terraform erstellten Plan übereinstimmen. Bei einem unerwarteten Unterschied prüfen Sie Provider-Versionen, Backend-Einstellungen und alle Terraform-Funktionen nach 1.5.x, bevor Sie anwenden.

Zwei Feinheiten sind wichtig, bevor Sie irgendetwas ausführen. Erstens ist OpenTofu für die in diesem Leitfaden beschriebenen Fälle weitgehend konfigurationskompatibel mit Terraform-artigem HCL, aber Funktionen, die nach Terraform 1.5.x hinzugefügt wurden, brauchen trotzdem eine Kompatibilitätsprüfung. Zweitens tofu init -upgrade kann .terraform.lock.hcl aktualisieren, einschließlich Provider-Quelladressen und Prüfsummeneinträgen. Prüfen Sie diese Metadaten getrennt von der Infrastruktur-Drift.

Die echten Hürden

Drei Dinge können aus einer schnellen CLI-Migration ein umfassenderes Plattformprojekt machen. Keines davon ist ein Bug.

HCP-Terraform-Workspaces. OpenTofu enthält Cloud- und Remote-Integrationen für kompatible Remote-Dienste, einschließlich HCP Terraform in Szenarien mit lokaler Ausführung und State-Speicherung. Der schwierigere Teil ist die HCP-spezifische Remote-Ausführung und Plattformfunktionen: Sentinel, Run Triggers, dynamische Zugangsdaten, Stacks und jedes Dienstverhalten, das OpenTofu nicht vollständig testen oder unterstützen kann. Wenn diese zentral sind, testen Sie zuerst einen Workspace; wenn Sie HCP verlassen, migrieren Sie den State und bauen diese Plattformkontrollen neu auf.

Profi-Tipp: Der Abschied von HCP Terraform kann die größten versteckten Kosten verursachen, wenn der Bestand auf HCP-spezifischen Workflows beruht. Bevor Sie sich entscheiden, führen Sie terraform state pull > state.json aus und prüfen Sie Größe und Ressourcenanzahl. Ein Workspace mit 200 Ressourcen ist ein anderes Projekt als eine Flotte von 50 Workspaces mit Run Triggers und Policy Sets. Letzteres ist eine Platform-Engineering-Migration, kein bloßer Tool-Wechsel.

CI/CD-Pipelines, die fest auf terraform. eingestellt sind. Jeder Verweis auf terraform plan, terraform apply den Binärpfad, das Docker-Image und den GitHub-Actions- oder GitLab-CI-Schritt muss überprüft werden. Bei GitHub Actions sieht der Austausch ungefähr so aus:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

Das ist der triviale Fall: ein Workflow, ein Repository. In einem Monorepo mit gemeinsam genutzten Composite Actions, mehreren Pipelines und einer wiederverwendbaren Workflow-Bibliothek ist die Prüfungsfläche deutlich größer. Die Arbeit ist mechanisch, kann aber länger dauern als der bloße CLI-Austausch.

Überprüfung der Abhängigkeits-Lock-Datei. tofu init kann .terraform.lock.hcl, einschließlich Provider-Quelladressen und Prüfsummeneinträgen. OpenTofu 1.12 kann außerdem vollständige h1: -Prüfsummensätze hinzufügen. Behandeln Sie den Diff als Abhängigkeits-Metadaten, die separat geprüft und committet werden, nicht als Infrastruktur-Drift.

Profi-Tipp: Der Diff der Lock-Datei kann beim ersten Commit unübersichtlich wirken. Führen Sie tofu init -upgrade auf einem sauberen Branch, committen Sie nur die Lock-Datei mit einer klaren Nachricht wie "review OpenTofu lock-file changes", und rebasen Sie die Feature-Arbeit anschließend darauf. Abhängigkeitsmetadaten mit einem Feature-PR zu vermischen macht beide Änderungen schwerer zu überprüfen.

Widerstand der Stakeholder. "Wir betreiben jetzt einen Fork" kommt in verschiedenen Organisationen unterschiedlich an. Die ehrliche Antwort ist, dass OpenTofu für die in diesem Leitfaden beschriebenen Fälle weitgehend konfigurationskompatibel mit Terraform-artigem HCL bleibt, sodass der Wechsel meist reversibel ist. Würde OpenTofu morgen verschwinden, könnten viele Teams Terraform neu installieren, die Lock-Datei prüfen und dieselben .tf .tf-Dateien weiterverwenden. Prüfen Sie zuerst Post-Fork-Funktionen; dieser Vorbehalt ist glaubwürdiger als das Versprechen perfekter Austauschbarkeit.

Wann die Migration wirklich schwer ist

Dieser einfache Weg gilt nicht für jeden Terraform-Bestand.

Die Migration wird deutlich schwieriger, wenn:

• der State groß ist (Tausende Ressourcen, Dutzende Workspaces) und in HCP Terraform liegt.
• die Codebasis tief HCP-exklusive Funktionen nutzt: Sentinel-Policies, die in Workspaces eingebunden sind, Run Triggers, von HCP verwaltete dynamische Provider-Zugangsdaten. Terraform Stacks ist HCP-exklusiv und hat kein OpenTofu-Äquivalent, das hier außen vor bleibt.
• ein Unternehmens-Audit oder Compliance-Rahmenwerk "Terraform" ausdrücklich als das maßgebliche IaC-Tool nennt, was zusätzlich zum technischen ein Beschaffungs- und Dokumentationsproblem schafft.
• eine große Modulbibliothek interne Versionsbeschränkungen hat, die sich auf ein Terraform-spezifisches Registry-Verhalten verließen.

Nicht jedes Team sollte migrieren. Das Kosten-Nutzen-Verhältnis ergibt nur Sinn, wenn die BSL-Beschränkungen Ihren Anwendungsfall tatsächlich betreffen, wenn eine bestimmte OpenTofu-Funktion etwas Konkretes freischaltet oder wenn die von IBM kontrollierte Roadmap für Ihre Organisation eine echte Sorge ist. Trifft nichts davon zu, ist das Bleiben bei Terraform eine völlig vertretbare Entscheidung.

Sollten Sie wechseln?

Es gibt hier keine einzig richtige Antwort. Wenn ich für ein Team den Entscheidungsbaum zeichne, tauchen vier typische Szenarien auf, und der richtige Schritt hängt davon ab, in welchem Sie sich befinden.

Neue IaC-Einführung (Greenfield). Beginnen Sie mit OpenTofu. Die Lizenz ist MPL 2.0, die Governance liegt bei der Linux Foundation und der CNCF, und das Projekt hat einen aktiven Release-Rhythmus. Zu seinen Unterscheidungsmerkmalen zählen clientseitige State-Verschlüsselung, provider for_each, enabled, und dynamisches prevent_destroy. Es gibt keine BSL-Reibung, die man einplanen müsste. Das ist die stärkste Empfehlung in diesem Artikel.

Bestehender Terraform-Nutzer, kleines bis mittleres Projekt. Wechseln Sie, wenn einer von drei Auslösern eintritt. Erstens: Sie verkaufen oder könnten ein Produkt verkaufen, das an die BSL-Ausnahme "konkurriert mit HashiCorp" streift; die rechtliche Lage ist bei MPL 2.0 klarer. Zweitens: Sie brauchen clientseitige State-Verschlüsselung, provider for_each, enabled, oder dynamisches prevent_destroy und der Terraform-Workaround sich nicht mehr lohnt. Drittens: Sie bevorzugen Multi-Party-Governance gegenüber einer Roadmap eines einzigen Anbieters. Trifft nichts davon zu und läuft Terraform sauber, bleiben Sie. Migration ist in vielen Beständen reversibel, aber nicht kostenlos.

Intensiver HCP-Terraform-Nutzer. Betrachten Sie dies als Plattformentscheidung, nicht automatisch als Backend-Migration. OpenTofu kann kompatible Remote-Backends nutzen, aber HCP-spezifische Remote-Ausführung, Sentinel, Run Triggers, dynamische Zugangsdaten und Stacks brauchen weiterhin eine Bewertung Funktion für Funktion. Sind diese Kontrollen zentral, testen Sie zuerst. Verlassen Sie HCP aus Lizenz-, Kosten- oder Governance-Gründen, planen Sie die Arbeit als Plattformmigration.

Erwägung von Pulumi oder einer anderen Nicht-HCL-Alternative. OpenTofu ist der nächstliegende Weg, wenn Sie HCL und die meisten bestehenden Workflows behalten möchten. Pulumi ist eine breitere Plattform- und Sprachwahl: TypeScript, Python, Go oder .NET zur Steuerung von Cloud-APIs. Der Wechsel dorthin kann eine Konvertierung oder Neufassung bedeuten, bewerten Sie ihn also getrennt von einem einfachen Terraform-zu-OpenTofu-Binärwechsel.

Ein weiterer Punkt verdient direkte Ansprache: die berechtigte Kritik, dass OpenTofu teilweise eine Absicherung für SaaS-Anbieter ist. Ein Hacker-News-Thread zur BSL-Änderung brachte die Sorge auf, dass die Gründungsmitglieder des Projekts kommerzielle Terraform-Plattformen mit einem eigenen Lizenzflexibilitäts-Motiv sind. Ich nehme diese Sorge ernst. Die Abmilderung liegt in der Governance-Struktur, dem Hosting durch die Linux Foundation, dem CNCF-Sandbox-Status, MPL 2.0 auf jeder Datei, was eine künftige Neulizenzierung deutlich schwerer macht, als es bei einem einzelnen Anbieter der Fall war. Unmöglich macht das nichts. Aber es macht es teuer genug, um eine echte Bremse zu sein.

Kurzes Fazit. Beginnen Sie bei jeder neuen IaC-Arbeit 2026 mit OpenTofu. Lizenz, Governance, aktive Entwicklung und Funktionsumfang machen es zu einer starken Standardwahl. Wechseln Sie bei bestehenden Terraform-Bereitstellungen, wenn einer der drei obigen Auslöser zutrifft; andernfalls ist das Kosten-Nutzen-Verhältnis dünn, und Bleiben ist in Ordnung.

Sobald die Toolwahl klar ist, lautet die nächste praktische Frage, wo OpenTofu laufen soll. Diese Entscheidung beeinflusst den Umgang mit Geheimnissen, die Kosten, die Wiederholbarkeit und wie viel Kontrolle Ihr Team über die Ausführungsumgebung hat.

OpenTofu selbst betreiben

OpenTofu ist eine CLI-Binärdatei. Wo Sie es ausführen, bestimmt viel über Kosten, Sicherheit und was Sie damit tun können. Es gibt grob drei sinnvolle Orte dafür.

Laptop oder Entwicklungsrechner. Gut für einmalige Pläne, Prototyping und kleine private Projekte. Als Standard für gemeinsam genutzte Produktions-Workflows ist es schlecht geeignet, sofern Remote-State, Locking und Review-Disziplin nicht bereits durchgesetzt sind. Teams profitieren meist von einer kanonischen Ausführungsumgebung statt davon, welcher Laptop zuletzt tofu apply.

Verwalteter CI-Runner (GitHub Actions, GitLab CI usw.). Der gängige Weg. Die opentofu/setup-opentofu -Action ist ein direkter Ersatz für hashicorp/setup-terraform. Das funktioniert für die meisten Teams und Projekte gut. Kompromisse: Geheimnisse durchlaufen einen Drittanbieter-CI-Dienst, Freikontingent-Minuten können bei großen State-Operationen ausgehen, und die Runner-Umgebung ist flüchtig, was meist ein Vorteil, manchmal aber eine Einschränkung ist. Siehe GitHub vs GitLab , falls Sie noch zwischen gehosteten CI-Optionen wählen, und Best CI/CD Tools für den breiteren Überblick.

Selbst gehosteter Runner auf einem VPS. Nützlich, wenn die Kompromisse von verwaltetem CI nicht mehr funktionieren: Geheimnisse müssen von einem Drittanbieter-Dienst ferngehalten werden, CI-Minuten werden teuer, oder Sie wollen persistente Provider-Caches. Die Einrichtung ist unkompliziert: ein Linux-VPS, die OpenTofu-Binärdatei, ein GitHub-Actions- oder GitLab-Runner-Agent und Docker zur Job-Isolation. Siehe Install Docker on VPS , falls dieser Teil neu für Sie ist. Für einen Runner eines kleinen Teams sind 4 GB RAM, 2 vCPU und 60 GB NVMe ein vernünftiger Ausgangspunkt; skalieren Sie CPU, Speicher und Storage für größere Pläne und höhere Parallelität.

Für Teams, die strengere Kontrolle über Runner-Geheimnisse, persistente Provider-Caches oder planbare CI-Kosten brauchen, kann ein selbst gehosteter Runner auf einem VPS sinnvoll sein. Priorisieren Sie dabei Root-Zugriff, schnellen NVMe-Speicher, einfache Skalierung und genug CPU/RAM für größere Plan-Operationen.

Cloudzy Linux VPS -Instanzen passen mit Root-Zugriff, NVMe-Speicher und flexibler Größenanpassung gut zu diesem Muster eines selbst gehosteten Runners, sodass Sie klein anfangen und den Runner mit wachsenden OpenTofu-Workloads skalieren können.

Häufig gestellte Fragen

Ist OpenTofu dasselbe wie Terraform?

Nicht ganz. OpenTofu begann als Fork von Terraform 1.5.x und bleibt weitgehend konfigurationskompatibel mit Terraform-artigem HCL: dieselben .tf Dateien, dieselben Provider und derselbe plan/apply plan/apply-Workflow für viele Projekte. Sie unterscheiden sich in der Lizenz und in den nach dem Fork hinzugefügten Funktionen. OpenTofu hat clientseitige State-Verschlüsselung, provider for_each, enabled, und dynamisches prevent_destroy; Terraform hat eigene Post-Fork-Funktionen, einschließlich ephemerer Ressourcen.

Unterstützt OpenTofu alle meine Terraform-Provider?

Bei großen Providern wie AWS, GCP, Azure, Kubernetes und Helm im Allgemeinen ja. Die OpenTofu Registry meldet mit Stand Juli 2026 mehr als 3.900 Provider. tofu init kann .terraform.lock.hcl -Metadaten aktualisieren. Prüfen Sie bei Nischen-, anbieterspezifischen oder neu veröffentlichten Providern vor dem Wechsel direkt Verfügbarkeit und Versionsunterstützung.

Könnte OpenTofu selbst irgendwann neu lizenziert werden?

Eine künftige Neulizenzierung ist schwieriger als bei Terraform, aber nicht unmöglich. OpenTofu steht unter MPL 2.0, wird von der Linux Foundation gehostet und ist seit dem 23. April 2025 ein CNCF-Sandbox-Projekt. Die Governance ist Multi-Party, und die Lizenz ist OSI-zertifiziert. Eine einseitige Neulizenzierung durch einen einzelnen Gründer würde sowohl der Satzung der Foundation als auch den bestehenden MPL-2.0-Beiträgen widersprechen, die entfernt oder neu geschrieben werden müssten. Die Sorge ist berechtigt; die strukturellen Hürden sind real.

Was bedeutet die IBM-Übernahme von HashiCorp für die Zukunft von Terraform?

IBM hat die Übernahme von HashiCorp am 27. Februar 2025 für 6,4 Milliarden Dollar abgeschlossen. Die Roadmap von Terraform liegt nun innerhalb eines größeren Unternehmensanbieters. Die Übernahme allein sagt nichts über künftige Lizenzierung oder Produktrichtung aus; bewerten Sie aktuelle Release Notes, Lizenzhinweise und HCP-Produktänderungen, statt die Eigentümerschaft als Vorhersage zu behandeln.

Ist OpenTofu 2026 produktionsreif?

Ja. v1.12.5 ist das aktuelle Wartungsrelease, das Projekt befindet sich im CNCF Sandbox, und Fidelity hat den Produktionseinsatz über einen IaC-Bestand mit mehr als 50.000 State-Dateien und vier Millionen Ressourcen beschrieben. Produktionsreif bedeutet nicht funktionsidentisch: Teams, die auf HCP-exklusive Funktionen wie Terraform Stacks angewiesen sind, brauchen weiterhin eine gesonderte Kompatibilitätsentscheidung.