OpenTofu oder Terraform: Tempo entscheidet kaum, Governance schon

Für Teams mit selbst betriebenen IaC-Pipelines spricht viel für OpenTofu, wenn offene Governance und clientseitige Verschlüsselung von State und Plan wichtig sind. Wer Zugriffe, Remote-Läufe und Zustandsverwaltung bereits über HCP Terraform organisiert, sollte den Wert dieser Plattform gegen den Aufwand eines Wechsels abwägen.

Beide Werkzeuge nutzen HCL und ein weitgehend gemeinsames Provider-Ökosystem. Für die Wahl zählen deshalb weniger kleine Abstände bei der Laufzeit eines Plans als die Fragen, wer State und Schlüssel verwaltet, welche Freigaben gebraucht werden und wie stark bestehende Abläufe an HCP Terraform gebunden sind.

Die Entscheidung nach Betriebsmodell

Die CLI allein bildet den Betrieb von Infrastruktur als Code selten vollständig ab. Diese Zuordnung macht sichtbar, wo die Unterschiede für ein Team Folgen haben:

• Eigene CI und eigenes Backend: OpenTofu ist besonders interessant, wenn State vor der Ablage verschlüsselt werden soll und das Team die Schlüsselverwaltung selbst übernehmen kann. Terraform Community Edition bleibt eine Option, wenn die Schutzmaßnahmen des gewählten Backends die Anforderungen erfüllen.
• HCP Terraform: Bestehende Workspaces, Remote-Läufe, Zugriffsrollen und eine private Registry sprechen dafür, die Plattformbindung mitzuberechnen. Beim Wechsel müssten diese Abläufe an anderer Stelle bereitgestellt werden.
• Lizenz und Projektsteuerung: Wer eine offen lizenzierte, gemeinschaftlich gesteuerte Grundlage verlangt, hat mit OpenTofu einen klaren Grund für die Wahl. Bei ausschließlich interner Infrastrukturnutzung ist die Terraform-Lizenz allein meist kein Anlass zur Migration.
• Bestehende Konfiguration: Gemeinsame Sprachgrundlagen erleichtern eine Erprobung. Die tatsächlich verwendeten Module, Provider-Versionen, State-Dateien und CI-Integrationen bestimmen, wie aufwendig der Wechsel wird.

Lizenz und Governance: Wer kann das Werkzeug wie nutzen?

Die Gegenüberstellung von Spacelift beschreibt OpenTofu als Projekt unter der Mozilla Public License 2.0 und dem Dach der Linux Foundation, Terraform dagegen als von HashiCorp gesteuertes Werkzeug unter der Business Source License. Sie hält auch die gemeinsame HCL-Grundlage und breite Provider-Kompatibilität fest. Offene Governance betrifft damit vor allem die langfristige Kontrolle über Entwicklung und Lizenzierung, nicht das Ergebnis eines einzelnen Infrastruktur-Laufs.

Für die Lizenzfrage ist der konkrete Einsatz entscheidend. Der BSL-Lizenztext von HashiCorp gestattet interne Nutzung ausdrücklich; seine Einschränkung betrifft konkurrierende kostenpflichtige Angebote an Dritte, die das lizenzierte Werkzeug hosten oder einbetten. Ein Unternehmen, das nur seine eigene Infrastruktur verwaltet, hat daher eine andere Ausgangslage als ein Anbieter einer gehosteten IaC-Plattform. Bei letzterem hängt die Bewertung vom Angebot und seiner technischen Einbindung ab.

State-Schutz: Wo die Verschlüsselung beginnt

OpenTofu kann State- und Plan-Dateien bei lokaler Speicherung und bei Nutzung eines Backends verschlüsseln. Die OpenTofu-Dokumentation zur Verschlüsselung warnt zugleich, dass diese Dateien ohne den passenden Schlüssel nicht wiederherstellbar sind. Der Schutz vor der Ablage ist besonders relevant, wenn ein Team den Zugriff auf das Backend getrennt vom Zugriff auf sensible State-Inhalte halten will.

Damit entsteht eine eigene Betriebsaufgabe: Schlüssel müssen gesichert und für die ausführende CI verfügbar sein; auch ein Wiederherstellungsweg gehört dazu. OpenTofu nennt dafür sowohl statische Passphrasen als auch Schlüsselverwaltungssysteme und empfiehlt vor dem Einschalten der Verschlüsselung eine Sicherung des unverschlüsselten State. Die Funktion schützt den gespeicherten Inhalt, aber weder vor einer beschädigten State-Datei noch vor Einsicht durch eine Person, die einen berechtigten Lauf ausführt.

Verschlüsselung im Backend setzt an einer anderen Stelle an: Sie schützt Daten am Speicherort. Clientseitige Verschlüsselung sorgt dafür, dass der abgelegte State bereits verschlüsselt ist. Welche Variante ausschlaggebend ist, hängt davon ab, wem das Team den Zugriff auf Backend, Ausführungsumgebung und Schlüssel gestattet. Der zusätzliche Schutz lohnt sich nur mit einer verlässlichen Schlüsselverwaltung.

HCP Terraform: Der Nutzen steckt im gemeinsamen Ablauf

Terraform Community Edition ist ein CLI-Werkzeug; HCP Terraform ergänzt es um einen verwalteten Betrieb. HashiCorps Übersicht der Terraform-Editionen nennt durch Änderungen in der Versionskontrolle ausgelöste Läufe, rollenbasierte Zugriffe, eine private Registry sowie versionierten Remote-State mit Verschlüsselung am Speicherort. Terraform Enterprise wird dort als selbst betriebene Variante dieser Plattformfunktionen beschrieben.

Diese Funktionen lösen andere Aufgaben als die Verschlüsselung durch die OpenTofu-CLI. Zugriffsrollen legen fest, wer Infrastruktur ändern darf; eine private Registry verteilt freigegebene Module; versionierter State erleichtert den Zugriff auf frühere Zustände. Ein Team mit eigener CI kann solche Aufgaben selbst organisieren. Bestehen sie bereits als HCP-Ablauf, umfasst eine Migration auch deren Ersatz, Berechtigungen und laufenden Betrieb.

Kompatibilität und Migration: Der State ist nur ein Teil

Die gemeinsame HCL-Basis und die breite Unterstützung für Provider senken die Einstiegshürde. Daraus folgt jedoch keine Zusage für jede Kombination aus Modul, Provider-Version und Sprachfunktion: Beide Projekte entwickeln sich weiter. Besonders private Module, eigene Provider, enge Versionsvorgaben und plattformspezifische Integrationen verdienen Aufmerksamkeit, weil sie in allgemeinen Kompatibilitätsaussagen leicht verschwinden.

Für einen Wechsel ist ein Probelauf mit einer gesicherten State-Kopie und den tatsächlich eingesetzten Provider-Versionen aussagekräftiger als eine reine Syntaxprüfung. Initialisierung und Plan zeigen, ob Konfiguration und State in dieser Kombination erwartungsgemäß gelesen werden. Danach kommen CI-Befehle, Registry-Zugänge und Freigaben hinzu. Die clientseitige Verschlüsselung sollte als eigener Migrationsschritt behandelt werden: Einen bereits verschlüsselten OpenTofu-State kann Terraform nicht unverändert lesen; für einen Rückweg muss er zuvor entschlüsselt werden.

Was die veröffentlichte Laufzeitmessung aussagt

Eine veröffentlichte AWS-Messreihe von TechPlained nennt für unveränderte Pläne einer Konfiguration mit rund 400 Ressourcen 12,4 Sekunden mit Terraform 1.10 und 12,1 Sekunden mit OpenTofu 1.9. Der Abstand beträgt in dieser Messung 0,3 Sekunden. Das ist ein vom Autor berichtetes Ergebnis für seine Konfiguration, kein unabhängig reproduzierter Durchschnitt und keine Leistungszusage für andere Provider, Runner oder Backends.

Bei einem einzelnen Plan kann ein solcher Abstand die organisatorischen Unterschiede kaum aufwiegen. In einer Umgebung mit sehr vielen kurzen CI-Läufen mag die Laufzeit unter den eigenen Bedingungen wichtig werden; dafür wären Messungen mit denselben Konfigurationen, Providern und Ausführungsumgebungen nötig. Für die grundlegende Wahl ist zunächst entscheidend, ob das Team clientseitigen State-Schutz und offene Projektsteuerung braucht oder ob die bereits genutzten HCP-Funktionen den größeren Betriebsnutzen liefern.

Lesen Sie auch:

• Proton Mail oder mailbox: Eigene Domain und Mailprogramm drehen die Wahl
• OBS Studio oder Streamlabs: Im Test war der Leistungsvorteil gering
• Cloudflare Workers oder AWS Lambda: Die Laufzeit bestimmt die Rechnung