IBM and HashiCorp recently announced they’re ending external language support for Terraform. If you’ve been using Python, Ruby, or other third-party languages in your Terraform configurations, this changes things.
The decision marks a clear strategic shift. HashiCorp wants to focus on Terraform’s core capabilities instead of maintaining support for multiple programming languages. For teams managing infrastructure at scale, this means rethinking how you write and maintain your Infrastructure as Code.
What’s Actually Changing
Terraform will no longer support external languages in new releases. The HashiCorp Configuration Language (HCL) will become the only supported option in the future. If you’ve built workflows around Python or Ruby integrations, you’ll need to migrate to HCL.
HCL isn’t new. It has been Terraform’s primary language since the beginning. HashiCorp designed it specifically for infrastructure management, and it handles most IaC tasks well. But the removal of language flexibility does limit options for teams that prefer other tools.
Why This Matters for DevOps Teams
Infrastructure as Code has become standard practice in DevOps. Terraform sits at the center of many organizations’ multi-cloud strategies. When a major vendor narrows the scope of a critical tool, it affects how teams plan and execute their work.
Some teams chose Terraform specifically because it uses familiar languages. Python developers could write infrastructure code in Python. Ruby teams could stick with Ruby. That flexibility made Terraform easier to adopt in diverse technical environments.
Now, those teams need to either commit to HCL or evaluate alternative options. That’s not a small decision. Migration takes time. Training takes resources. And any transition introduces risk.
The Business Logic Behind It
From HashiCorp’s perspective, this makes sense. Supporting multiple languages means maintaining multiple codebases, handling edge cases across different ecosystems, and managing compatibility issues. That’s expensive and complicated.
Focusing on HCL lets HashiCorp improve one language really well, rather than supporting several languages adequately. The company can move faster, ship features more consistently, and reduce technical debt.
For IBM, which acquired HashiCorp earlier this year, consolidation fits its enterprise software playbook. Streamlined products are easier to support, document, and sell.
What HCL Does Well
HCL isn’t a bad language. It’s declarative, which fits infrastructure management naturally. You describe what you want, and Terraform figures out how to create it. The syntax is readable even if you’re not a developer.
HCL handles variables, modules, and dependencies in ways that make sense for infrastructure work. HashiCorp has spent years refining it based on real-world use cases. The language works.
But it’s still a domain-specific language. That means learning a new syntax, understanding new patterns, and adjusting your mental model if you’re coming from general-purpose languages.
The Migration Challenge
Moving existing Terraform configurations from external languages to HCL isn’t trivial. You can’t just run a converter and call it done. Infrastructure code often includes business logic, error handling, and integration points that need thoughtful translation.
Teams will need to audit their current implementations, prioritize what to migrate first, and test thoroughly. In production environments, that process can take months.
The timing creates additional pressure. Organizations are already managing initiatives in cloud cost optimization, security compliance, and platform engineering. Adding a forced migration to the list strains already busy teams.
“This change does not alter Terraform itself, but it directly impacts the Cloud Development Kit for Terraform, which enabled teams to define infrastructure using Java, Python, TypeScript, and other general-purpose languages. HashiCorp is ending its support for CDKTF, even though the project remains available on GitHub under the Mozilla Public License 2.0,” according to Mitch Ashley, VP and practice lead, software lifecycle engineering, The Futurum Group.
Ashley continues, “I expect the open source community will rally around CDKTF and sustain it, which would significantly lessen the disruption for existing users. By any practical measure, HashiCorp is turning CDKTF support over to the community, and acknowledging that reality directly would have been a more palatable message to the community.”
Alternatives Worth Considering
This change might push some teams to evaluate other IaC tools. Pulumi supports multiple programming languages, including Python, TypeScript, and Go. AWS CDK lets you write infrastructure in JavaScript, Python, or Java. OpenTofu, the Terraform fork, continues to support a broader range of language options.
Switching tools has costs, too. But if language flexibility matters more than staying in the HashiCorp ecosystem, alternatives exist.
Moving Forward
DevOps teams need to make some decisions. Evaluate how much you rely on external language support in Terraform. Map out what migration would require. Consider whether this fits your long-term infrastructure strategy.
For organizations deeply invested in Terraform, committing to HCL probably makes sense. The tool still works well for IaC. HashiCorp will likely improve it faster without the burden of maintaining external language support.
For teams on the fence, this might be the moment to explore other options. The IaC landscape has matured. You have choices.
Either way, plan. These transitions go more smoothly when you control the timeline rather than reacting under pressure.
The infrastructure tooling market keeps evolving. This won’t be the last time vendors make strategic decisions that affect how you work. Building adaptable teams and processes matters more than betting everything on a single tool.
