CDKTF ist archiviert. Dein State ist in Ordnung.

HashiCorp hat das Cloud Development Kit for Terraform am 10. Dezember 2025 archiviert. Das Repository ist schreibgeschützt. Keine Updates mehr, keine Fixes, keine Kompatibilitäts-Updates. Das Letzte bestimmt deinen Zeitplan. Als Grund nennt HashiCorp, es habe „keinen Product-Market-Fit in größerem Maßstab gefunden“.

Wenn du CDKTF produktiv einsetzt, liegt die gute Nachricht in der Struktur: Du sitzt weniger fest, als die Ankündigung vermuten lässt.

Was CDKTF tatsächlich war

CDKTF ist ein Generator, keine Engine. Du schreibst TypeScript, Python oder Go; cdktf synth schreibt Terraform-Konfiguration nach cdktf.out; cdktf deploy und cdktf destroy sind Wrapper um terraform apply und terraform destroy. Der State darunter ist gewöhnlicher Terraform-State, geschrieben von gewöhnlichem Terraform gegen gewöhnliche Provider.

Deshalb ist diese Abkündigung halb so wild. Nichts Proprietäres hält deine Ressourcen fest: Die archivierte Schicht sitzt über der, der sie gehören. Es ist dieselbe Unterscheidung, die darüber entscheidet, was deine Infrastruktur wirklich ausführt, wenn du SST benutzt. Und sie ist der Grund, warum der Ausstieg aus CDKTF weniger kostet als der aus einem Werkzeug mit eigenem State-Modell.

Der Ausstieg ist ein Befehl

cdktf synth --hcl gibt HCL aus statt des voreingestellten JSON. Diese Ausgabe einchecken, Terraform darauf richten, die CDKTF-Schicht löschen. Dein State bleibt unberührt, weil er nie CDKTF gehörte.

Was du dabei verlierst, gehört vorher benannt:

• Schleifen, Bedingungen und Typen. Der Grund für CDKTF war, dass sich for besser liest als count und if besser als try(…). Synthetisiertes HCL ist das Ergebnis, nicht der Ausdruck: Aus jeder Schleife wird ihre ausgerollte Form.
• Deine Abstraktionen. Aus einem Construct, das zwölf Ressourcen erzeugte, werden zwölf Ressourcen. Die Absicht dahinter lebt nur in dem Code, den du gerade löschst.
• Lesbare Diffs. Generiertes HCL ist ausufernd und maschinenförmig. Es funktioniert, und niemand liest es gern im Review.

Synthetisieren ist damit der Ausstieg und noch nicht die Migration. Du stehst ab Tag eins auf einer Toolchain, die gepflegt wird, und die Neuschreibung rückt auf deinen Zeitplan statt auf den des nächsten Kompatibilitätsbruchs.

Die drei echten Optionen

• Standard-Terraform mit HCL. HashiCorps eigene Empfehlung, ohne neuen Anbieter und ohne neues State-Format. Du tauschst Programmierkonstrukte gegen eine Sprache, die im Team ohnehin jeder liest und die jedes Werkzeug unterstützt.
• AWS CDK, wenn dein CDKTF-Code ohnehin mit AWS-CDK-Constructs verflochten ist. HashiCorp nennt diesen Weg ausdrücklich. Klein ist er nicht: CloudFormation ist eine andere Engine mit anderem State-Modell, und Nicht-AWS-Provider kommen nicht mit.
• Pulumi. Behält, was du mochtest, nämlich eine echte Programmiersprache über denselben Providern, und verlangt dafür seinen eigenen State und seine Runtime. Pulumi hat im selben Monat einen Migrationspfad veröffentlicht; lesenswert, mit dem Bewusstsein, dass ihn die Partei geschrieben hat, die davon profitiert.

Was ich tun würde

Jetzt nach HCL synthetisieren, auf dem bestehenden State, und heute aufhören, von einer archivierten Toolchain abzuhängen statt in dem Quartal, in dem ein Provider-Release sie bricht. Die Neuschreibung danach getrennt entscheiden, ohne Druck.

Die Frist ist nicht das Archivierungsdatum. Sie ist die erste Provider-Version, für die dein festgepinntes CDKTF nicht mehr generieren kann. Und weil niemand mehr Kompatibilitäts-Updates veröffentlicht, setzen dieses Datum AWS, Google oder Cloudflare, nicht du.

Next

Zeilen vorher und nachher zu zählen misst Geschwätzigkeit, und Geschwätzigkeit ist nicht das Risiko. Der Post steht und fällt mit der Behauptung, dass sich deine Ressourcen nicht bewegen, weil der State nie CDKTF gehört hat. Diese Behauptung lässt sich prüfen, und die Antwort ist binär.

Nach HCL synthetisieren, Terraform darauf zeigen lassen, gegen denselben State planen. Plane aber zuerst den bestehenden Stand: Wo ohnehin Drift liegt, kommt in beiden Fällen ein unsauberer Plan heraus, und du schiebst der Migration etwas in die Schuhe, was vorher schon da war.

# Baseline: Was plant das CDKTF-Setup heute?
terraform plan -out=old.tfplan

# Dasselbe Projekt als HCL, gegen denselben State
cdktf synth --hcl
terraform plan -out=new.tfplan

# Beide Pläne als Daten vergleichen, nicht als Text
for p in old new; do
  terraform show -json $p.tfplan \
    | jq -S '[.resource_changes[]
        | select(.change.actions != ["no-op"])
        | {address, type, actions: .change.actions}] | sort_by(.address)' > $p.json
done
diff old.json new.json

Ein sauberer Ausstieg heißt: diff gibt nichts aus. Alles andere benennt sich selbst. Ein ~ heißt, dass das erzeugte HCL ein Attribut anders schreibt als das JSON zuvor — meistens kosmetisch, manchmal nicht. Ein -/+ heißt, dass eine Ressource zerstört und neu angelegt würde, weil ein Construct beim Auflösen andere Namen vergibt, und das ist der Unterschied zwischen einer Migration und einem Ausfall. Eine Zeilenzahl sieht von beidem nichts.

Ich habe eine CDKTF-Codebase in Produktion, an der ich das durchspielen kann. Veröffentlichen lässt sich davon die Form der Antwort, nicht die Infrastruktur: ob der Diff leer zurückkommt, und wenn nicht, welche Art von Construct sich als tragend herausgestellt hat.

Läuft bei dir irgendwo CDKTF? Mich interessiert, ob die Constructs, die du gebaut hast, sich sauber ausrollen lassen, oder ob genau sie der Grund waren, CDKTF zu nehmen.