OpenTofu vs Terraform 2026: Wie die IaC-Landschaft sich neu formiert

Seit August 2023 ist die Infrastruktur-as-Code (IaC)-Welt keine Eintoolwelt mehr. Damals stellte HashiCorp Terraform von der offenen MPL-2.0-Lizenz auf die Business Source License (BSL) um — und die Community spaltete sich. Aus dem Fork entstand OpenTofu, heute unter dem Dach der Linux Foundation und der CNCF. Drei Jahre später, Mitte 2026, sind beide Projekte produktiv, aber sie haben sich technisch und strategisch weit auseinanderentwickelt. Dieser Artikel zeigt, wo die Unterschiede liegen, welche Features wirklich zählen und wie Teams die richtige Wahl treffen.

Der Lizenzkonflikt: BSL vs. MPL 2.0

Der Auslöser des Forks war lizenzrechtlich, aber seine Folgen sind heute technisch und strategisch. Terraform wird seit August 2023 unter der BSL 1.1 ausgeliefert, die von der Open Source Initiative (OSI) nicht als Open-Source-Lizenz anerkannt wird (Scalr, Juli 2026). Die Nutzung im Unternehmen ist weiterhin kostenlos möglich, aber wer Terraform als Dienstleistung Dritten anbietet, muss prüfen, ob dies mit HashiCorps Geschäftsmodell konkurriert.

OpenTofu blieb unter der MPL 2.0 — einer OSI-zertifizierten Lizenz ohne Nutzungseinschränkungen. Das Projekt wird von einem Multi-Vendor-Steuerungskomitee unter der Linux Foundation gelenkt, nicht von einem einzelnen Unternehmen (DEV Community, März 2026). Für Unternehmen mit strengen Compliance-Anforderungen, insbesondere im öffentlichen Sektor, ist dieser Unterschied oft entscheidend.

Ein weiterer strategischer Faktor: IBM schloss die Übernahme von HashiCorp im Februar 2025 ab (Expeditious Software, Juni 2026). Seither ist Terraform Teil eines $6,4-Milliarden-Portfolios für Hybrid-Cloud-Lösungen. Der Produkt-Roadmap wird zunehmend von IBMs Suite-Strategie bestimmt.

Technische Innovationen im Vergleich

Die Zeiten, in denen OpenTofu lediglich ein umbenannter Terraform-Fork war, sind vorbei. Beide Projekte haben eigenständige Features entwickelt:

OpenTofu (Version 1.11, Dezember 2025) brachte unter anderem:

Native State-Verschlüsselung (bereits seit v1.7): Zustandsdateien können clientseitig mit AES-GCM oder PBKDF2 verschlüsselt werden — unabhängig vom Backend (Scalr). Ein kompromittierter S3-Bucket reicht dann nicht mehr aus, um an sensible Infrastrukturdaten zu gelangen.
Provider for_each (v1.9): Iteration über Provider-Konfigurationen, nützlich für Multi-Region- oder Multi-Account-Setups.
Early Variable Evaluation (v1.8): Variablen können im terraform-Block verwendet werden, etwa für dynamische Backend-Konfigurationen. Das ersetzt Workarounds wie Terragrunt.
Ephemere Ressourcen (v1.11): Kurzlebige Zugangsdaten werden nicht in den State geschrieben.

Terraform (Version 1.9–1.10) konzentrierte sich auf:

Ephemere Werte (v1.10): Ähnlich wie OpenTofus Ansatz — Credentials, die nur während des apply existieren und nie im State landen (Clanker Cloud, April 2026).
Provider-definierte Funktionen (v1.10): Provider können eigene HCL-Funktionen mitliefern, etwa zum Validieren von CIDR-Bereichen.
terraform test: Unit-Tests für Module mit Assertions auf Plan-Ebene, ohne tatsächliche Infrastruktur zu provisionieren.
Stacks (Preview): Orchestrierung mehrerer Deployments als Einheit — bisher jedoch nur in HCP Terraform verfügbar, nicht im Open-Source-CLI (Scalr).

Der größte Unterschied liegt im State-Management. OpenTofu bietet native clientseitige Verschlüsselung; Terraform setzt weiterhin auf Backend-seitige Verschlüsselung (etwa S3 Server-Side Encryption). In sicherheitskritischen Umgebungen ist OpenTofus Ansatz klarer überlegen.

KI-gestützte IaC-Workflows 2026

Ein neuer Trend, der beide Tools betrifft: KI-Assistenten generieren Terraform/OpenTofu-Code. LLMs wie Claude Opus, GPT-5 oder Codex können auf Anfrage vollständige Module für EKS-Cluster, VPCs oder IAM-Rollen schreiben (Clanker Cloud). Der Workflow lautet: Generieren → Planen → Reviewen → Anwenden. Der menschliche Review-Schritt vor dem apply bleibt unverzichtbar — KI-generiertes HCL enthält oft noch hartcodierte Werte oder fehlende Tags.

Terraform hat hier einen eigenen Akzent gesetzt: Mit dem HCP-Terraform-MCP-Server können KI-Agenten direkt mit Terraform-Registries interagieren und kontextbewusste Pläne generieren (DEV Community). OpenTofu setzt dagegen auf Offenheit — jeder Anbieter kann darauf aufsetzen.

Entscheidungshilfe: Was ist 2026 die richtige Wahl?

Beide Tools sind produktionsreif. Die Wahl hängt von organisationsspezifischen Faktoren ab:

Für OpenTofu spricht:

OSI-zertifizierte Open-Source-Lizenz (MPL 2.0)
Multi-Vendor-Governance unter Linux Foundation / CNCF
Native State-Verschlüsselung und Early Variable Evaluation
Keine Abhängigkeit von einem einzelnen Anbieter
Ideal für Greenfield-Projekte und Teams mit strengen Compliance-Vorgaben

Für Terraform spricht:

Bestehende HCP-Terraform-Integrationen und Sentinel-Policys
Stacks (Preview) für Multi-Deployment-Orchestrierung
MCP-Server für KI-Integration
Bewährter Enterprise-Support durch IBM
Sinnvoll, wenn HashiCorp/IBM bereits Framework-Partner ist

Die Migration ist technisch einfach: tofu ist ein Drop-in-Ersatz für terraform. Der Wechsel erfolgt oft mit einem einzigen PR, der die CI-Pipelines aktualisiert (Scalr). Dennoch sollten Teams vorher einen tofu plan ausführen, um die State-Kompatibilität zu prüfen.

Fazit

OpenTofu und Terraform sind 2026 zwei eigenständige, leistungsfähige IaC-Plattformen mit unterschiedlichen Governancen und Schwerpunkten. OpenTofu hat sich vom reinen Fork zu einem Innovationsmotor entwickelt, insbesondere bei State-Sicherheit und Konfigurationsflexibilität. Terraform punktet weiterhin mit HCP-Integration und Enterprise-Ökosystem. Die Entscheidung ist keine technische mehr, sondern eine strategische — und sollte dokumentiert getroffen werden, bevor die Codebasis auf beide Tools verteilt wächst.