Der Terraform-Fork geschah 2023: HashiCorp wechselte die Lizenz zu BSL, die Community antwortete mit dem OpenTF-Manifest. Damals klang die Frage beunruhigt — ist es überhaupt sicher, auf einen Fork zu setzen? 2026 ist sie überholt. OpenTofu lebt unter der Linux Foundation, bleibt ein Drop-in-Ersatz mit demselben HCL und denselben Providern, läuft in Version 1.11 in Produktion und zählt Allianz und Fidelity zu seinen Anwendern. Die Frage wurde pragmatisch: nicht ob man kann, sondern wann der Fork bereits die bessere Wahl ist.
Von „riskant" zu „Standard ab Werk"
OpenTofu ist kein aufholender Klon. Es ist eine eigene Engine mit derselben Syntax, aber eigener Bahn. Drop-in ist hier wörtlich gemeint: dasselbe HCL, dieselben Provider aus der Registry, die Datei .terraform.lock.hcl wird nicht umbenannt, der Block terraform {} wird unverändert akzeptiert. Die CLI heißt tofu, die Governance ist community-getrieben unter der Linux Foundation statt eines einzelnen Anbieters. Für ein neues Projekt ist die Einstiegshürde null, und die MPL-2.0-Lizenz (OSI) klärt die BSL-Frage mit der Rechtsabteilung sofort, ohne Vorbehalte.
Wo der Fork den Upstream überholt hat
Die Schlagzeile der letzten zwei Jahre: OpenTofu hält nicht nur Parität — stellenweise führt es vor dem Original.
Native Verschlüsselung von State und Plan (seit 1.7) — ein encryption {}-Block mit AWS/GCP KMS oder OpenBao, ohne externes sops oder GPG. Terraform hat hier nichts Natives. Early Evaluation (1.8) erlaubt Variablen im backend {}-Block und in module.source — dynamische Backend-Konfigurationen, die im Upstream unmöglich sind. for_each auf Providern (1.9) faltet Multi-Region in einen einzigen Block statt handgeschriebener Aliase. Natives S3-Locking (use_lockfile, ohne DynamoDB) kam in OpenTofu 1.10 — eine Release vor Terraform 1.11. Das ist kein kostenloser Ersatz mehr, sondern eine Engine, die Aufgaben löst, die dem Original verschlossen bleiben.
Lock-in ist asymmetrisch: Bleiben ist auch eine Wette
Ein verbreiteter Mythos: Migration ist Risiko, der Status quo ist Sicherheit. Tatsächlich ist die Kompatibilität einseitig. Terraform → OpenTofu läuft glatt: Migrationswerkzeuge, ein Plan mit null Änderungen. Der Rückweg ist schmerzhaft — wer die einzigartigen Funktionen genutzt hat, dessen verschlüsselter State und dynamische Backends sind schlicht inkompatibel mit dem Original. Nichts zu tun ist also ebenfalls eine Entscheidung mit Folgen: Je länger ein Team auf einer BSL-Engine sitzt und HCP-Spezifika (Stacks, Sentinel) ansammelt, desto teurer wird die spätere Entflechtung.
Migration ist billiger als die Angst davor
Ein realer Fall: 8 Tausend Zeilen, 12 Module, drei Umgebungen, ein Backend auf S3 + DynamoDB, GitHub Actions — der Umzug dauerte etwa vier Stunden, und der größte Teil davon floss ins Umschreiben der CI, nicht des Codes. Der Ablauf: zuerst alle ausstehenden Änderungen anwenden und den State sichern — migriert wird aus einem sauberen Zustand. Dann koordiniert die Datei .terraform.lock.hcl im gesamten Team gleichzeitig löschen, sonst trifft einen Kollegen mit einem Terraform-Lock-File ein Hash-Konflikt. Danach tofu init und tofu plan, der null Änderungen zeigen muss — das ist das Go/No-go-Gate: ein Diff bedeutet, nicht zu migrieren, sondern zu untersuchen. Der letzte Schritt ist der Tausch von setup-terraform gegen setup-opentofu in der Pipeline. Und niemals Binaries auf einem State mischen: nach tofu apply wechseln alle Ingenieure und die CI auf tofu, sonst schleicht sich stiller Drift ein.
Wo Terraform weiterhin gewinnt
Ein ehrlicher Kontrapunkt: Der Fork ist keine universelle Antwort. Auf Terraform zu bleiben ist rational, wenn eine tiefe Investition in HCP Terraform und Sentinel besteht, wo das Policy- und Orchestrierungs-Ökosystem an den Anbieter gebunden ist; wenn Stacks zur Orchestrierung vieler Workspaces gebraucht werden und OpenTofu noch kein Pendant hat; wenn die offizielle MCP-Integration für KI-Agenten nötig ist — Terraform hat sie, der Fork offiziell noch nicht, und das zählt beim Bau agentischer Pipelines; wenn Enterprise-Support von IBM gebraucht wird und die Rechtsabteilung mit BSL einverstanden ist. Das ist eine rationale Wahl, kein Konservatismus.
Die Entscheidungsregel für 2026
Für ein Greenfield-Projekt ist OpenTofu der Standard: null Einstiegshürde, eine OSI-Lizenz, Funktionen, die stellenweise führen, keine BSL-Exposition. Der Fork lohnt sich bereits, wenn kein HCP-Lock-in besteht und native State-Verschlüsselung, dynamische Backends und das Fehlen von Anbieterabhängigkeit zählen. Auf Terraform zu bleiben ergibt nur Sinn bei tiefer Bindung an HCP Stacks, Sentinel oder MCP — oder bei einer harten Anforderung an Anbieter-Support. Die Ära eines einzigen IaC-Standards ist vorbei, die Ära der Wahl hat begonnen; und 2026 verschiebt sich für die meisten neuen Projekte die bewusste Wahl hin zum Fork.