--- title: "OpenTofu vs Terraform 2026: Lohnt sich der Fork?" description: "OpenTofu vs Terraform 2026: warum der Fork entstand, was wirklich anders ist (State-Verschlüsselung, provider for_each, Lizenz), eine Vergleichstabelle und ein ehrliches Fazit." author: Aleksei Aleinikov date: 2026-07-17 lang: de tags: [opentofu, terraform, infrastructure-as-code, iac, opentofu-vs-terraform, devops, hashicorp] canonical: https://www.alekseialeinikov.com/de/blog/topics/devops/opentofu-vs-terraform-lohnt-der-fork-2026 source: alekseialeinikov.com --- # 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. ![Zeitleiste des Forks: Terraform bis 1.5 war MPL; im August 2023 lizenzierte HashiCorp auf BUSL um und die Community forkte die letzte MPL-Version in OpenTofu unter der Linux Foundation. Terraform ging zu HCP Terraform und IBM-Besitz; OpenTofu ergänzte State-Verschlüsselung und erreichte 1.12.](https://www.alekseialeinikov.com/blog/opentofu-fork-timeline-2026.webp) 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. ![Drei-Spalten-Vergleich: OpenTofu-Alleinstellungsmerkmale (State-Verschlüsselung, provider for_each, -exclude, offene Registry), gemeinsame Grundlage (HCL, Provider, plan/apply, Module, Testing) und Terraform-Alleinstellungsmerkmale (HCP Terraform, Stacks, Sentinel, offizieller Support).](https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-features-2026.webp) 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: ```hcl 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 | | **OpenTofu** | **Terraform** | |---|---|---| | **Lizenz** | MPL-2.0 (Open Source) | BUSL 1.1 (source-available) | | **Governance** | Linux Foundation (anbieterneutral) | HashiCorp / IBM (ein Anbieter) | | **Aktuelle Version (2026)** | 1.12 | 1.x (HashiCorp) | | **Konfigurationssprache** | HCL | HCL | | **Provider** | Gleiches Plugin-Protokoll | Gleiches Plugin-Protokoll | | **State- & Plan-Verschlüsselung** | Nativ (KMS / PBKDF2, AES-GCM) | Nicht eingebaut | | **provider-`for_each` (Iteration)** | Ja | Nein | | **`-exclude`-Targeting** | Ja | Nein | | **Registry** | Offene MPL-Registry | HashiCorp-Registry (restriktive ToS) | | **Verwaltete Plattform** | Drittanbieter (Spacelift, env0, Scalr) | HCP Terraform (First-Party) | | **Policy-Engine** | OPA / Drittanbieter | Sentinel (First-Party) + OPA | | **Stacks / Orchestrierung** | Über CI-Plattformen | Terraform Stacks (First-Party) | | **Offizielle Anbieter-SLA** | Nein (Community + Anbieter) | Ja (IBM/HashiCorp) | | **Migration** | Drop-in von Terraform ≤ 1.5/1.6 | — | ## 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](https://www.alekseialeinikov.com/de/blog/topics/cloud/gke-autopilot-vs-standard-vergleich-2026) für die Cluster-Modus-Entscheidung und [Sichere GKE-Referenzarchitektur](https://www.alekseialeinikov.com/de/blog/topics/architecture/secure-by-default-gke-referenzarchitektur-2026) zum Härten dessen, was deine IaC ausrollt.