CDKTF is Dead

If you have not seen the news, Terraform CDK (also known as CDKTF) is dead. Hashicorp, an IBM company, sunset and archived the tool on 10 Dec 2025. CDKTF is an open-source framework that lets you define and provision infrastructure using familiar programming languages (like Python, TypeScript, Java, C#, or Go) instead of Terraform's native HashiCorp Configuration Language (HCL). Although moot at this point in time, I wrote up an introductory post a while back. If your team has been using CDKTF for a while, you are now at a crossroads. What is your path going forward?

Site Note: The number of times that Hashicorp tells us that they are IBM company in their sunset notice reminds me of how some people talk about themselves in third person.

What Are Your Options?

Do Nothing

Although it is not a great option, your team can continue to use CDKTF as it always has. Unfortunately, you are now the owner of day zero tech debt. As it ages, you will need to find workarounds and creative solutions as the drift between CDKTF and modern technology increases. This is a good short term option if you do not have a long term solution selected. Your CI/CD pipelines will still function in the short term.

Back To Basics

Hashicorp's official recommendation is to migration back to Hashicorp Configuration Language (HCL). This path involves using the built-in cdktf synth --hcl command to convert the existing project's code from a general-purpose language back into native HCL. This is probably the quickest path back to a supported platform. The code, once converted, is now written in the widely adopted, declarative language that is the industry standard for multi-cloud IaC, guaranteeing the largest community, most established tooling, and consistent workflows. However, the primary disadvantage is a significant loss of programmatic power: teams must abandon the use of general-purpose languages like Python or TypeScript, which were used in CDKTF for strong typing, unit testing, and complex flow control, leading to potentially more verbose and less abstract code for dynamic infrastructure needs.If you require commercial support, you will also be licensing under Hashicorp's BSL license.

The Open Source Route

For teams that want to use a truly open-source and community-governed alternative to Terraform, OpenTofu is the answer. As a fork of the last fully open-source version of Terraform, it is a drop-in replacement that uses HCL. This option is best when combining it with first (generating HCL) to ensure the team benefits from the open-source governance and compatibility with the vast Terraform provider ecosystem without being locked into HashiCorp's proprietary licensing. infrastructure needs. Overall, this is a good option if Hashicorp's BSL is a sticking point for your team. The main advantage is vendor neutrality, governance under the Linux Foundation, and the introduction of community-requested features like built-in state encryption and enhanced variable evaluation. Its primary disadvantage is its comparative youth and lack of official, integrated commercial support (like Terraform Cloud), meaning organizations needing enterprise-grade features and vendor-backed SLAs must rely on third-party vendors or consultants.

Switch to Pulumi

Teams whose primary motivation for using CDKTF was the ability to define infrastructure using general-purpose programming languages (TypeScript, Python, Go, etc.) should consider migrating to Pulumi. Pulumi is a fully supported and actively developed Infrastructure as Code (IaC) tool designed natively for this "code-first" approach, offering a direct replacement for CDKTF's developer experience, though it requires migrating to an entirely new platform and state management system. Switching from CDKTF to Pulumi allows teams to maintain their preferred programmatic IaC approach, leveraging familiar general-purpose languages like Python and TypeScript for defining infrastructure, which is a major advantage. Pulumi is fully supported, actively developed, and works across multiple clouds, effectively replacing CDKTF's core capability. However, the main disadvantage is the required platform migration: teams must adopt a new CLI, learn Pulumi's resource model and state management, and convert their existing CDKTF constructs to Pulumi's equivalent code, which represents a significant one-time effort.

Go Cloud Provider Specific

If the team's infrastructure is exclusively or predominantly hosted on Amazon Web Services (AWS), the AWS Cloud Development Kit (AWS CDK) provides a highly integrated and idiomatic solution. AWS CDK allows the use of general-purpose languages to define infrastructure using high-level, optimized constructs specific to the AWS cloud, but it is not a viable option for multi-cloud or other non-AWS environments.

Bicep is Microsoft's dedicated, declarative language for deploying Azure resources, designed as a significant improvement over the verbose JSON of its predecessor, Azure Resource Manager (ARM) templates. While it is not a general-purpose language like Python or TypeScript, Bicep uses a clean, concise Domain Specific Language (DSL) that is simpler to read and maintain than other template formats. It offers native tooling, strong type safety, and guaranteed day-one support for all new Azure features, making it the most integrated and idiomatic Infrastructure as Code solution for teams operating exclusively in the Azure cloud.

Google Cloud Deployment Manager is GCP's native service for provisioning and managing Google Cloud resources as a single unit or "deployment." The configuration primarily relies on declarative YAML files, but for more advanced or programmatic logic—which was the strength of CDKTF—it allows users to define resources and logic using templates written in Python or Jinja2. While effective for GCP-only environments, its approach to programmatic IaC is less modern and robust than frameworks like AWS CDK or Pulumi, meaning teams migrating from CDKTF for the code-first experience may find it less powerful.

Moving from CDKTF to a cloud provider's native IaC solution (like AWS CDK, Bicep, or Deployment Manager) presents a significant trade-off. The effort involves a complete rewrite, as the team must move away from general-purpose languages (which was the CDKTF benefit) or cross-cloud constructs and adopt a platform-specific framework or DSL. This migration generates zero business value initially and requires substantial time to rewrite, test, and re-architect existing infrastructure definitions. The primary risk is intensified vendor lock-in: by abandoning a multi-cloud tool like CDKTF, the team binds its infrastructure code and engineering talent deeply to that single cloud platform's specific terminology, APIs, and roadmap, making any future move to a different cloud provider extremely difficult and prohibitively expensive.

Wrapping Up

Now that CDKTF is dead, teams must strategically evaluate whether their future lies in the established stability of native declarative languages like HCL and OpenTofu, the programmatic agility of a framework like Pulumi, or the deeper integration offered by a cloud-specific tool like AWS CDK or Bicep. Each path demands a significant investment in rewriting and upskilling, meaning the best direction forward depends entirely on your organization's unique requirements for vendor independence, multi-cloud strategy, and the desired developer experience going into this next phase of Infrastructure as Code. I will probably move my personal stuff to OpenTofu. Which direction will your team take?