OpenTofu vs Terraform 2026: Lohnt sich der Fork?

Wenn du Infrastructure as Code schreibst, verschob sich 2023 der Boden unter deinen Füßen. Terraform — ein Jahrzehnt lang das Standard-IaC-Tool — war plötzlich nicht mehr Open Source, und die Community reagierte mit einem Fork. Dieser Fork ist OpenTofu, und 2026 ist er ein ausgereiftes, produktionsreifes Tool in Version 1.12.

Also die eigentliche Frage jedes Plattform-Teams: Bleibe ich bei Terraform oder wechsle ich zu OpenTofu? Das hier ist eine ehrliche, aktuelle Antwort — warum die Spaltung passierte, was wirklich anders ist und wann welches Tool die richtige Wahl ist.

Warum es plötzlich zwei Tools gibt

Den größten Teil seines Lebens war Terraform unter der Mozilla Public License 2.0 (MPL-2.0) lizenziert — einer echten Open-Source-Lizenz. Im August 2023 lizenzierte HashiCorp Terraform (ab v1.6) auf die Business Source License 1.1 (BUSL) um — eine source-available Lizenz, die konkurrierende kommerzielle Nutzung einschränkt. Das ist kein OSI-Open-Source.

Die Community forkte die letzte MPL-2.0-Version, und das Projekt — nun OpenTofu — wechselte zur Linux Foundation für anbieterneutrale Governance. Dann kündigte IBM 2024 die Übernahme von HashiCorp an (abgeschlossen Anfang 2025) und stellte Terraforms Verwaltung unter einen einzigen großen Anbieter. OpenTofu ging in die andere Richtung: offene Lizenz, offene Governance, offene Registry.

Das ist mehr als Ideologie. Eine BUSL-Lizenz ändert, was deine Rechtsabteilung freigibt, worauf du ein Produkt aufbauen darfst und ob die Roadmap des Tools von einem Anbieter oder einer Stiftung kontrolliert wird.

Was tatsächlich gleich ist

Das ist der Teil, den das Drama verdeckt: OpenTofu und Terraform sind unter der Haube noch dasselbe Tool. OpenTofu war ein Fork, kein Rewrite. Das bedeutet, sie teilen:

• Die HCL-Konfigurationssprache — deine .tf-Dateien funktionieren unverändert.
• Das Provider-Plugin-Protokoll — dieselben AWS-, Google-, Azure-, Kubernetes-Provider laufen auf beiden.
• Das State-Modell, den plan/apply-Workflow und terraform {}-Blöcke.
• Module, Workspaces, moved/import/check-Blöcke und ein natives Test-Framework.

Weil die Grundlage geteilt ist, ist die Migration meist ein Drop-in: OpenTofu installieren, tofu init gegen den bestehenden State ausführen und mit einer kleinen Änderung verifizieren. Der offizielle Pfad ist sicher und umkehrbar.

Was OpenTofu kann, was Terraform nicht kann

Der Fork verfolgte Terraform nicht nur — er ergänzte Features, die Terraform 2026 noch fehlen:

• Native State- & Plan-Verschlüsselung. OpenTofu verschlüsselt State- und Plan-Dateien im Ruhezustand, clientseitig, mit steckbaren Key-Providern — AWS KMS, GCP KMS, Azure Key Vault, OpenBao oder einer PBKDF2-Passphrase — mit AES-GCM. Wenn deine State-Datei (voller Secrets und Access Keys) leakt, ist sie Ciphertext. Terraform hat kein Äquivalent; du schnallst stattdessen Verschlüsselung auf Backend-Ebene an.
• Provider-Iteration mit for_each. OpenTofu unterstützt for_each auf provider-Blöcken — echt nützlich für Multi-Region- oder Multi-Account-Setups. Es erlaubt außerdem Variablen in module-source und version (dynamische Modul-Quellen). Terraform kann provider-Konfigurationen immer noch nicht iterieren.
• Das -exclude-Flag. Sprich das Komplement einer Ressourcenmenge an (tofu plan -exclude=...), das Gegenstück zu -target.
• Frühe Variablenauswertung für Backend- und Verschlüsselungs-Konfiguration und eine offene, MPL-lizenzierte Provider- und Modul-Registry (registry.opentofu.org), die nicht an die restriktiven Bedingungen der Terraform-Registry gebunden ist.

Ein minimaler State-Verschlüsselungs-Block sieht so aus:

terraform {
  encryption {
    key_provider "gcp_kms" "prod" {
      kms_encryption_key = "projects/acme/locations/global/keyRings/tofu/cryptoKeys/state"
      key_length         = 32
    }
    method "aes_gcm" "prod" {
      keys = key_provider.gcp_kms.prod
    }
    state { method = method.aes_gcm.prod }
    plan  { method = method.aes_gcm.prod }
  }
}

Was Terraform OpenTofu voraushat

Das ist nicht einseitig. Terraform behält echte Vorteile, meist rund um sein kommerzielles Ökosystem:

• HCP Terraform (früher Terraform Cloud) und Terraform Enterprise — die verwaltete Run-Umgebung, private Registry und der Remote-State-Dienst, eng integriert.
• Terraform Stacks — HashiCorps übergeordnete Orchestrierung zum gemeinsamen Verwalten vieler Konfigurationen.
• Sentinel — die Policy-as-Code-Engine, eingebacken ins HCP-Ökosystem.
• Offizieller Anbieter-Support und SLAs von IBM/HashiCorp, die manche Unternehmen vertraglich verlangen.
• Der größte Mindshare — Tutorials, Bewerber-Pool und Drittanbieter-Integrationen sagen weiterhin zuerst „Terraform“.

Gegenüberstellung: Das vollständige Bild

Wie man wählt

Entscheide nach Abhängigkeiten, nicht nach dem Lizenzkrieg.

Migriere zu OpenTofu, wenn:

• Du eine echte Open-Source-Lizenz brauchst — rechtlich, Compliance oder weil du ein Produkt auf dem Tool aufbaust.
• Du native State-Verschlüsselung willst, ohne sie anzuschnallen.
• Du anbieterneutrale Governance und eine offene Roadmap schätzt.
• Du provider-for_each, -exclude oder eine Plattform (Spacelift, env0, Scalr, GitLab, Harness) nutzt, die OpenTofu bereits unterstützt.

Bleib bei Terraform, wenn:

• Dein Workflow auf HCP Terraform, Terraform Stacks oder Sentinel aufbaut.
• Du offiziellen IBM/HashiCorp-Support und SLAs benötigst.
• Deine Organisation den etablierten Anbieter vorschreibt und kein Compliance-Druck zum Wechsel besteht.

Unsicher? Die Migration ist risikoarm und umkehrbar, also pilotiere OpenTofu auf einem unkritischen Stack. Weil HCL und Provider identisch sind, sind die Wechselkosten wirklich gering — das ist der ganze Sinn eines kompatiblen Forks.

Die Feldregel

OpenTofu und Terraform sind dasselbe Tool mit unterschiedlichen Lizenzen und Governance. Der Code, den du schreibst, ändert sich kaum; was sich ändert, ist, wer das Tool kontrolliert und wie offen es ist. Für einen reinen IaC-Workflow ohne harte Abhängigkeit von HCP Terraform ist OpenTofu 2026 der sicherere offene Standard — MPL-lizenziert, stiftungsverwaltet und bei State-Verschlüsselung voraus. Wenn du in HashiCorps kommerzieller Plattform lebst, verdient Terraform weiterhin seinen Platz. Wähle nach deinen echten Einschränkungen, pilotiere vor der Festlegung, und denk daran: die Migrationstür schwingt in beide Richtungen.

Wenn du GKE mit einem der beiden Tools provisionierst, kombiniere dies mit GKE Autopilot vs Standard 2026 für die Cluster-Modus-Entscheidung und Sichere GKE-Referenzarchitektur zum Härten dessen, was deine IaC ausrollt.