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
forbesser liest alscountundifbesser alstry(…). 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
Was fehlt, ist ein echtes Repository. Ein bestehendes Projekt nach HCL synthetisieren, die Zeilen vorher und nachher zählen — dann sieht man, wie viel von der Abstraktion Arbeit geleistet hat, die die Ausrollung nicht ausdrücken kann. Ich habe keine CDKTF-Codebase in Produktion, um es zu versuchen; falls du eine hast und mich in die Zahlen schauen lässt, gern.
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.
Quellen sind die Archivierungsmeldung, die CDKTF-CLI-Referenz und das State-Modell. Für diesen Post wurde keine Migration gefahren.
Baust du an etwas Ähnlichem?
Ich schreibe hier über Setups, die ich selbst benutze. Wenn du an etwas Vergleichbarem arbeitest, würde mich interessieren, wie dein Workflow aussieht.