← zurück

📷 "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

19. Oktober 2026 · 4 min · Martin Jochum #DevOps#IaC#OpenTofu#Terraform#Open Source#Cloud Native#Linux Foundation

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 per jsondecode geparst wird: Das Ergebnis bleibt unbekannt, aber OpenTofu weiß dann, dass der Zugriff auf id einen 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

  • base64gzip liefert durch eine neue DEFLATE-Implementierung äquivalente, aber nicht mehr byte-identische Ergebnisse — OpenTofu kann dadurch Ressourcen-Änderungen vorschlagen; als Übergang dient das Meta-Argument ignore_changes.
  • macOS-Builds erfordern mindestens macOS 13 Ventura.
  • v1.13 ist die letzte Serie mit offiziellen 32-Bit-Paketen (386, arm); der Aufruf von tofu init warnt darauf, v1.14 wird sie komplett streichen.
  • Der erste Patch, v1.13.1 vom 1. Oktober, fixt unter anderem tofu show -json mit 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

🤖 Dieser Beitrag wurde KI-gestützt erstellt und redaktionell geprüft.

Anzeige
Deine Anzeige hier — erreiche Tech-affine Leser. Kontakt: info@saaro.net→