The future of Terraform CDK

Posted by mfornasa 12/10/2025

136 points | 134 commentspage 2

Havoc 12/11/2025|

As far as corporate mercy killings goes archived under mozilla license is better than a pivot to "you now pay per core" or whatever

borisbanjo 12/10/2025||

CDKTF works beautifully, all the complains here seem to be from salty devops who got pissed the developers wanted something more powerful than the garbage HCL with its even more garbage module system.

CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.

nevon 12/11/2025||

Not stated in the most diplomatic way, but I do agree. Having used CDK (not cdktf) and now being forced back to Terraform feels like going back to the stone age. It is absolutely obvious to me that generating infrastructure definitions from a regular, testable language using all the same tools, techniques and distribution mechanisms that you use for all your other software development is the superior way. Being able to piggyback off of the vast ecosystem of Terraform providers was a really clever move, although I understand it led to some rough edges.

nijave 12/11/2025||

I kind of like it but I always found it kind of clunky how it's ultimately just generating JSON/HCL anyway. For instance, you can't data source then use code to transform and send it to a resource since it has to transpile first.

That also means you end up with things like the language's native JSON not doing what you expect and having to use a special Terraform function call.

zer0-c00l 12/10/2025||

This is a bummer. I don't particularly like Pulumi but use it anyways because for my use cases being able to write actual code is really impactful. Sucks to see fewer options in that space

leetrout 12/10/2025||

The often excluded option is dynamically generating JSON and feeding that to TF instead of HCL.

You can combine it with tools like Dhall or my personal preference Jsonnet instead of imperative languages for an interesting experience for reusable pieces outside of module concepts.

Duologic 12/10/2025||

Any particular libraries you use to generate TF-JSON from jsonnet?

I wrote a generator a little while ago that can create jsonnet libraries from the TF schemas: https://github.com/Duologic/soysonnet

Example lib here: https://github.com/Duologic/soysonnet-aws

I only needed it for AWS so I didn't spend more time on it.

leetrout 12/11/2025||

By hand :( But I like your project. Do you use Tanka?

Duologic 12/11/2025||

I work at Grafana and did quite a bit of work on Tanka in the past, so yes.

joeduffy 12/10/2025|||

[Pulumi founder here] Sorry to hear you don't particularly like Pulumi---any/all feedback welcome. If nothing else, we do listen and we do try to get better. -Joe

here2learnstuff 12/11/2025||

What is it that you don't like about Pulumi? As I mentioned in another comment, my team of backend-engineers who took over an infra team went from Cloudformation -> CDK -> Terraform -> Pulumi and honestly find it the most approachable for other engineers familiar with normal programming languages (sorry HCL). We've been using it since 2021 and have a "what's on main is what's deployed" philosophy and adopted a RunAtlantis inspired workflow where previews are run as status checks on PRs and require explicit approvals, apply is run on merge to main and periodically, and drift checks run preview+refresh and alerts if what's checked in doesn't match what exists. We don't really use stacks, we just use a separate project for everything and write code to encapsulate modules (and luckily we can easily write unit tests and runtime assertions).

moltar 12/10/2025||

This is so sad. It’s a great project. Needs to be forked and maintained. If anyone forks please email me I’ll contribute.

rubenvanwyk 12/11/2025|

OpenTofu is already the de facto fork.

thayne 12/11/2025||

OpenTofu is a fork of terraform, not CDKTF.

Although, I would hope a fork of cdktf would target opentofu instead of terraform.

callumgare 12/10/2025||

As an alternative is anyone considering https://sst.dev/ (which uses Pulumi under the hood)? We use it at work and I’ve been quite happy with it

moltar 12/10/2025|

It’s not an alternative at all. Terraform CDK is basically TypeScript transpired to HCL. You can codegen TypeScript bindings for any provider. And then write normal TypeScript.

ptdorf 12/11/2025||

> Terraform CDK is basically TypeScript transpired to HCL

transpiled to JSON

dev_l1x_be 12/10/2025||

It would be great to have an alternative to Terraform that uses a bit more advanced provider (at last for AWS). Does OpenTofu use that same provider?

jpitz 12/10/2025||

The providers for tofu are by design the same as for terraform.

Also, for large providers like AWS, GCP, Azure, etc - these are often largely authored by the hyperscaler themselves, for better or worse.

lijok 12/10/2025||

It does. What are you looking for in a more advanced AWS provider?

dev_l1x_be 12/12/2025||

Have you ever debugged what goes on with lets say the aws provider during a tf apply?

kbar13 12/10/2025||

we're using cdk since 100% of our stuff is in aws but will soon need to hook up some external resources like cloudflare. looked at tfcdk a while back but didn't think it was a good idea (glad). still trying to figure out a good way forward and hoping it's not to rip the bandaid and migrate everything to terraform / pulumi

DangitBobby 12/10/2025||

Well that sucks for me.

lijok 12/10/2025||

Good move. They clearly didn't have the resources they needed. The design of the CDKs was atrocious.

lloydatkinson 12/10/2025|

What was the point of it? Terraform supports AWS anyway.