CDKTF is officially deprecated
The deprecation announcement
Well, it finally happened.
HashiCorp (now owned by IBM) officially deprecated the Cloud Development Kit for Terraform (CDKTF) on December 10, 2025. The repository is archived. No more features. No more fixes. If you chose CDKTF to write infrastructure code in TypeScript, Python, or Go instead of HCL, you’re now being told to go back to the very thing you tried to avoid.
Impact on existing users
Your existing stacks keep working, because CDKTF only generates Terraform configuration and Terraform still runs it. What you lose is bindings for new providers, bug fixes, and anyone to report a security issue to after the archive date.
Why HashiCorp killed CDKTF
The business reason
Why did this happen?
According to HashiCorp, CDKTF “did not find product-market fit at scale.” Translation: not enough enterprise customers using it to justify the investment. This is what happens when tools are owned by a single vendor focused on enterprise priorities over community needs.
What that says about priorities
CDKTF was never what enterprises were paying for. The paid tiers around Terraform are, and CDKTF meant maintaining a second toolchain that sold nothing on its own. Under IBM that arithmetic got less forgiving, not more.
Migration options after the deprecation
Your choices
What are your options?
You’ve got two paths forward:
Option 1: Go back to HCL (with OpenTofu)
HashiCorp suggests using cdktf synth --hcl to convert your code to raw HCL. But you don’t have to run that HCL on HashiCorp’s Terraform. OpenTofu is the truly open-source, Linux Foundation-backed alternative that won’t change licenses on you or sunset tools you depend on.
Converting existing code
cdktf synth --hcl emits HCL rather than JSON, so you get files a reviewer can read. Budget time to clean the output up. Generated resource names are long, and every loop and conditional you wrote in TypeScript arrives fully expanded.
OpenTofu as the alternative
OpenTofu is a Linux Foundation fork of Terraform from before the licence change, so the state format, the provider protocol and most of the CLI are the same. In practice the move is a binary swap and a CI change rather than a rewrite.
Option 2: Switch to Pulumi
If you picked CDKTF because you wanted real programming languages with loops, variables, and proper abstractions, Pulumi is your best bet. Unlike CDKTF (which was always a translation layer), Pulumi is native infrastructure-as-software. You keep the power of TypeScript/Python/Go without the deprecation risk.
What Pulumi does differently
CDKTF generated Terraform configuration and handed it to Terraform. Pulumi talks to the providers itself, which mostly shows up in errors: a failure points at the line you wrote instead of at generated output you have to map back.
You keep the language
Loops, functions, real types and your existing unit tests all survive the move. What changes is the state backend, the CLI your pipeline runs, and the fact that you are now paying attention to a different company’s roadmap.
The vendor lock-in lesson
Vendor risk
The bigger lesson here?
CDKTF is the small version of this. The Terraform licence change in 2023 was the large one. Both came out of one company deciding what happens to code other people had already shipped to production. Today it’s CDKTF. Tomorrow it could be another tool you depend on.
Long-term strategy
The test I now apply is whether we could keep deploying if the vendor walked away tomorrow. An open state format counts. A provider protocol someone else has already implemented counts. A fork that exists and has commits in it counts. A tool only one company ships does not.
Plan your migration now
Start now
Your move:
If you’re using CDKTF in production, start planning your migration now. Whether you go with OpenTofu for stability or Pulumi for programming power, don’t wait until support runs out completely.
Migration timeline
Nothing breaks on a specific date, which sounds relaxed right up until a provider you use ships a change and nobody is left to regenerate the bindings. Treat it as a quarter of work spread across sprints, not a sprint.
Risk assessment
Sort your stacks by how often you change them. The ones you touch weekly hurt first, because those are the ones that will want a newer provider. A stack nobody has edited in a year can sit on archived CDKTF for a while, and being honest about that is what makes the rest of the plan fit.
Community discussion
Share your experience
What do you think?
Have you been using CDKTF? What’s your migration plan? I would like to hear whether synth --hcl gave you output you were actually willing to keep, because that is the part I am least sure about.
Lessons learned
The thing I keep coming back to is that CDKTF was not a bad tool. It was a decent tool with no revenue attached to it, and that turns out to be the risk worth pricing when you pick anything from a single vendor.
