📷 "NEC-Monitor-292" by NEC Corporation of America is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.
OpenTofu 1.13: Symbol Libraries, Linting-Experiment und weniger Unknowns beim Planen
Am 30. September 2026 hat das OpenTofu-Projekt Version 1.13.0 veröffentlicht — bewusst als schlankeres Release: Die Entwicklungszeit wurde verkürzt, um sich am Go-Veröffentlichungszyklus auszurichten, wodurch die Serie länger unter Sicherheitssupport bleibt (bis August 2027). Gerade wegen der reduzierten Feature-Fracht sind zwei Experimente umso bemerkenswerter, denn sie zeigen, wohin die Reise geht: eingebautes Linting und ein neues Artefakt namens „Symbol Libraries". Dazu kommen neue Funktionen für präzisere Pläne, offizielle Windows-ARM64-Pakete und einige Breaking Changes, die beim Upgrade beachtet werden sollten. Für IaC-Teams ist der Release auch ein guter Anlass, die Position des Projekts zu überprüfen: OpenTofu ist inzwischen der etablierte, unter der Linux Foundation beheimatete Terraform-Fork und seit April 2025 CNCF-Sandbox-Projekt.
Weniger „(known after apply)" mit convert und assume
Der Kern-Workflow von OpenTofu hängt davon ab, den Apply möglichst genau vorherzusagen. Werte, die sich beim Planen nicht bestimmen lassen, erscheinen im Plan als „(known after apply)" — praktisch, aber problematisch: Die Meta-Argumente enabled, for_each und count lehnen unbekannte Werte ab, und automatische Policy-Prüfungen, die die maschinenlesbare Plan-Ausgabe auswerten, sind durch Unknowns praktisch geblendet.
OpenTofu 1.13 führt deshalb zwei Werkzeug-Familien ein, mit denen Modulautoren dem Tool zusätzliche Hinweise geben können:
convert()gibt einen erwarteten Typ vor, etwa wenn ein unbekannter String perjsondecodegeparst wird: Das Ergebnis bleibt unbekannt, aber OpenTofu weiß dann, dass der Zugriff aufideinen String liefert.- Die
assume...-Funktionen (z. B.assumenotnull,assumestringprefix) machen Aussagen über den Wert selbst.
Ein typisches Beispiel: Der id eines AWS-Ressourcenobjekts ist beim Planen unbekannt. Mit einem Hinweis lässt sich der Vergleich mit null zu einem bekannten false machen:
output "vpc_id" {
value = assumenotnull(
assumestringprefix(
aws_vpc.example.id,
"vpc-",
)
)
}
Die entscheidende Bedingung: Die Hinweise müssen beim Apply tatsächlich zutreffen. Stimmt das versprochene Präfix nicht, schlägt die Funktion im Apply fehl. Wo Provider- oder API-Dokumentationen eine Garantie geben, lassen sich solche Annahmen sauber in einem geteilten Modul kapseln.
Zwei Experimente: Linting und Symbol Libraries
Version 1.13 enthält sehr frühe Arbeit an eingebautem Linting: erste Infrastruktur, um Lint-Regeln zu aktivieren und Ergebnisse als Warnungen zu melden, plus einige eingebaute Beispielregeln zur OpenTofu-Sprache. Das Projekt will daraus langfristig ein umfassendes Feature entwickeln, das auch Policy-Enforcement abdeckt.
Das zweite Experiment sind „Symbol Libraries": wiederverwendbare Sammlungen von Werten, Funktionen und Typ-Aliassen, die sich aus allen Quelltypen importieren lassen, die auch für Module unterstützt werden. So lässt sich etwa eine organisationsweite Konvention für DNS-Records zentral definieren:
typedef "recordset" {
type = set({
name = string
type = string
ttl = number
records = set(string)
})
}
function "a_records" {
type = symbols::dns_recordset()
parameter "records" {
type = map(set(string))
}
parameter "ttl" {
type = number
}
return = [
for name, ip_addrs in param.records : {
name = name
type = "A"
ttl = param.ttl
records = ip_addrs
}
]
}
Beide Experimente sind bewusst unreif markiert und sollen nicht in Produktion eingesetzt werden — das Projekt sucht explizit frühes Feedback aus der Community.
Windows on ARM64 und der Abschied von WinRM
Neu ist offizieller Support für Windows auf ARM64: Die großen Cloud-Provider haben entsprechende windows_arm64-Pakete, bei Drittanbietern kann ein Provider-Upgrade nötig sein. Auf der Streichliste steht dagegen WinRM: Die Verbindungstypen der Provisioner remote-exec und file werden nicht mehr unterstützt, weil zugrunde liegende Go-Bibliotheken ungepflegt sind. Betroffene Konfigurationen sollten auf OpenSSH für Windows migrieren.
Weitere Breaking Changes beim Upgrade
base64gzipliefert durch eine neue DEFLATE-Implementierung äquivalente, aber nicht mehr byte-identische Ergebnisse — OpenTofu kann dadurch Ressourcen-Änderungen vorschlagen; als Übergang dient das Meta-Argumentignore_changes.- macOS-Builds erfordern mindestens macOS 13 Ventura.
- v1.13 ist die letzte Serie mit offiziellen 32-Bit-Paketen (
386,arm); der Aufruf vontofu initwarnt darauf, v1.14 wird sie komplett streichen. - Der erste Patch, v1.13.1 vom 1. Oktober, fixt unter anderem
tofu show -jsonmit Ephemeral Resources.
Wo OpenTofu 2026 steht
Der Fork entstand im August 2023, nachdem HashiCorp Terraform von MPL 2.0 auf die Business Source License umgestellt hatte; seit September 2023 lebt das Projekt unter der Linux Foundation, die erste stabile Version 1.6.0 erschien im Januar 2024, die CNCF-Aufnahme als Sandbox-Projekt folgte im April 2025. 2026 führt OpenTofu weiterhin Features ein, die Terraform so nicht bietet — etwa eingebaute State-Encryption (1.7), Early Variable Evaluation (1.8) und dynamisches prevent_destroy (1.12); Provider-for_each (1.9) und Ephemeral Values (1.11) kamen ebenfalls zuerst in OpenTofu. Aktuell werden die Linien 1.11, 1.12 und 1.13 gepflegt; der Patch 1.12.7 schloss zuletzt Sicherheitslücken im SSH-Provisioner (CVE-2026-78662, CVE-2026-56855). Auch große Unternehmen ziehen um: Fidelity Investments dokumentierte seine Migration von Terraform zu OpenTofu im offiziellen Blog.
Fazit
OpenTofu 1.13 ist ein Signal-Release: Mit den assume...-Funktionen wird die Planung präziser, und die Experimente zu Linting und Symbol Libraries deuten auf die nächste Evolutionsstufe des Tools hin — Qualitätssicherung und wiederverwendbare Logik direkt im Kern statt in externen Tools. Teams sollten beim Upgrade WinRM-Abbau, base64gzip-Änderungen und die 32-Bit-Abkündigung einplanen. Der Blick auf v1.14 (ohne 32-Bit-Pakete) und die bis August 2027 unterstützte 1.13-Serie lohnt sich für jede IaC-Roadmap — OpenTofu ist 2026 kein Nebenprojekt mehr, sondern eine eigenständige Kraft im IaC-Ökosystem.
Quellen
- OpenTofu v1.13.0 (offizieller Blogpost) — Feature-Details, Experimente, Breaking Changes
- opentofu/opentofu Releases (GitHub) — v1.13.0/v1.13.1/v1.12.7, Support-Zeiträume, CVEs
- OpenTofu Blog — u. a. „An Introduction to OpenTofu Symbol Libraries" (17.09.2026), „A Vision for Built-in Linting" (03.09.2026), Fidelity-Migrationsbericht
- Spacelift: OpenTofu – The Open-Source Alternative to Terraform — Projektgeschichte, Release-Kadenz, Feature-Timeline
- env.dev: OpenTofu in 2026 — Terraform-Vergleich, Migrationspfad
🤖 Dieser Beitrag wurde KI-gestützt erstellt und redaktionell geprüft.
Anzeige