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).

Please expand on your experiences, because I've had great luck with Pulumi at my company since October 2021. No engineer liked HCL, our demographic was engineers who were familiar with programming languages who wanted to self service basic infrastructure (AWS SecretsManager, IRSA roles, Databricks Service Principals, etc). We were pretty easily able to shim in a RunAtlantis inspired system that displayed previews that required explicit approval when a PR was raised, performed apply on merge to main, and ran drift checks periodically.

Their stack builds a lot of abstractions on top of each other and this works only well as long as you don't deviate from the beaten path.

One example:

You can't really build custom TS providers for AWS resources.

Why?

Because this feature is built using the compilation magic that makes inline lambdas work.

But the compilation step omits the AWS SDKs since these are present in a lambda anyways. So you can't use the AWS SDK in custom providers.

For me, the ideal is each team owns its own config/lifecycle mgmt, and does it in the language they wrote the rest of the system in.