Wenn man DevOps-Teams fragt, welches IaC-Tool sie einsetzen, lautet die Antwort in neun von zehn Fällen: Terraform. Das ist keine Überraschung. Terraform ist seit 2014 auf dem Markt, hat eine riesige Provider-Bibliothek, läuft in jeder CI/CD-Pipeline und kennt jeder Senior Engineer, der in den letzten acht Jahren mit Cloud gearbeitet hat.
Pulumi macht seit drei bis vier Jahren Boden gut. Das Versprechen: Infrastruktur mit echten Programmiersprachen definieren – TypeScript, Python, Go, C#. Kein HCL, keine eigene DSL, sondern Code, den Entwickler kennen.
Die Frage “Terraform oder Pulumi?” hat keine universelle Antwort. Sie hat aber klare Kriterien – und die werden in der Praxis selten sauber angewendet.
HCL – Hashicorps Configuration Language – ist eine deklarative Sprache. Man beschreibt den Zielzustand der Infrastruktur, und Terraform berechnet den Plan, um dahin zu kommen. Das hat mehrere echte Vorteile:
Lesbarkeit für Nicht-Entwickler. Ein Operations-Engineer, der kein TypeScript spricht, kann eine Terraform-Datei lesen und verstehen. Ein Security-Auditor auch. Das ist in regulierten Umgebungen nicht trivial.
Reife Ecosystem. Mit über 3.000 Providern im Terraform Registry gibt es für nahezu jeden Cloud-Dienst, jedes SaaS-Tool und jede API einen offiziellen oder Community-Provider. Pulumi bietet eine vergleichbar breite Abdeckung, aber Terraform-Provider sind in der Regel älter, stabiler und besser dokumentiert.
State-Management als erstes Konzept. Das Terraform State-File ist gleichzeitig Stärke und schwache Stelle des Tools. Wer versteht, wie State funktioniert – und wie er sicher im Team geteilt wird (Remote State, Locking) – hat ein sehr verlässliches Werkzeug in der Hand.
HCL ist keine vollständige Programmiersprache. Wer komplexe Logik ausdrücken will – Schleifen über dynamische Strukturen, bedingte Ressourcenmengen, Abstraktion über mehrere Module hinweg –, landet irgendwann in unlesbaren Konstrukten.
Ein konkretes Beispiel: Wer in Terraform über eine Map iterieren und für jeden Eintrag mehrere verschachtelte Ressourcen erzeugen will, benötigt for_each mit toset, local Variablen und oft ein paar Umwege, die niemand beim ersten Lesen versteht. Dasselbe in TypeScript oder Python: eine normale Schleife.
Das zweite Problem ist das Lizenzmodell. HashiCorp hat 2023 die Lizenz von Terraform von Open-Source (MPL) auf BSL (Business Source License) umgestellt. Das hat die Community aufgeteilt – OpenTofu ist als Fork entstanden –, aber für Teams, die ihr Tooling langfristig bewerten, entstand Unsicherheit. Pulumi war von Anfang an unter Apache-2.0-Lizenz.
Was Pulumi anders macht – und wann das relevant ist
Pulumi ist kein “besseres Terraform”. Es ist ein anderes Konzept. Infrastruktur wird als imperativer Code ausgedrückt – mit Klassen, Funktionen, Schleifen, Bedingungen, Tests. Der Stack-State wird intern verwaltet, ähnlich wie bei Terraform.
Das ist dann sinnvoll, wenn:
Das Team aus Entwicklern besteht, nicht aus Operations-Engineers. Wer täglich TypeScript oder Python schreibt, wird Pulumi produktiver nutzen als HCL lernen zu müssen. Die Lernkurve dreht sich um.
Die Infrastruktur dynamisch ist. Wenn die Anzahl der zu provisionierenden Ressourcen von externen Eingaben abhängt – etwa von einer Kundenliste, einem Feature-Flag-System oder einer Datenbank –, ist imperativer Code klarer ausdrückbar als deklarative Schleifen.
Testing ein echtes Anforderung ist. Mit Pulumi kann man Unit-Tests für Infrastrukturcode schreiben – mit denselben Testframeworks, die man für Anwendungscode nutzt. Das ist kein Gimmick; es ist der Unterschied zwischen “wir deployen und schauen ob es läuft” und “wir testen Infrastruktur vor dem Deployment systematisch”.
Was bei der Entscheidung zählt
Drei Fragen helfen bei der Einordnung:
Wer schreibt und pflegt den IaC-Code? Wenn es ein dediziertes Platform-Team mit Operations-Hintergrund ist: Terraform. Wenn es Entwickler sind, die Infrastruktur als Teil ihrer Codebasis betrachten: Pulumi macht mehr Sinn.
Wie komplex ist die Logik? Wer einfache, stabile Cloud-Infrastruktur beschreibt – VPCs, Subnetze, ECS-Cluster, RDS-Instanzen –, braucht kein Pulumi. Wer Infrastruktur dynamisch aus Anwendungsparametern generiert, profitiert von echten Programmiersprachenkonzepten.
Gibt es einen bestehenden Terraform-Stack? Migration von einem funktionierenden Terraform-Setup zu Pulumi ist teuer und riskant. Das lohnt sich selten, wenn das bestehende Setup gut gewartet ist. Pulumi ist kein Upgrade, es ist ein Neuanfang.
Die Frage, die selten gestellt wird
Beide Tools adressieren dasselbe Grundproblem: Infrastruktur muss versionierbar, reproduzierbar und auditierbar sein. Ob das mit HCL oder TypeScript geschieht, ist zweitrangig gegenüber der Frage, ob es überhaupt systematisch geschieht.
In vielen Teams, die wir kennen, ist die eigentliche Lücke nicht das Tool – es ist das Fehlen einer klaren Eigentümerschaft. Wer ist für den IaC-Code verantwortlich? Wer reviewt Änderungen? Wer stellt sicher, dass der State-File nicht in Gitignore landet und auf dem Laptop eines Kollegen liegt?
Diese Fragen sind unabhängig vom Tool zu beantworten. Und sie sind meistens wichtiger als die Wahl zwischen Terraform und Pulumi.