Pulumi vs CDK vs CDKTF

Pulumi, AWS CDK, and CDKTF all let you write infrastructure in TypeScript, Python, or Go instead of HCL or YAML — but they take very different approaches. CDK compiles to CloudFormation, giving you AWS's managed state but inheriting its 1-hour deployment times. CDKTF compiles to Terraform JSON, giving you access to Terraform's 3000+ provider ecosystem but requiring Terraform state management. Pulumi talks to cloud APIs directly, making it the fastest and most cloud-agnostic but requiring you to manage state yourself.

Pulumi wins when you're multi-cloud or Kubernetes-heavy. It deploys resources in parallel directly via cloud APIs, making it the fastest for large stacks. It has strong Kubernetes support, a growing provider ecosystem, and the best story for teams that want to use Go for infrastructure (CDK's Go support is limited; CDKTF's is decent). Pulumi's policy-as-code (CrossGuard) and secrets management are also more sophisticated than the alternatives. If you're starting fresh and not married to AWS, Pulumi is the strongest technical choice.

CDK wins for AWS-native teams that want the highest-level abstractions. CDK's L2 constructs for services like VPC, ECS, Lambda, and RDS apply sane production defaults — security groups, IAM roles, log groups — with minimal config. CDK's snapshot testing catches accidental CloudFormation changes before deployment. If your team is all-in on AWS and wants to move fast with opinionated defaults rather than configuring everything from scratch, CDK's L2/L3 construct library is genuinely excellent. The cdk diff command surfaces exact CloudFormation changeset diffs before you deploy, and CDK's native CodePipeline and CodeBuild integrations eliminate the glue code you'd otherwise write to connect your IaC to AWS CI/CD services.

⚠️ CDKTF was officially deprecated by HashiCorp on December 10, 2025 and is no longer maintained. Do not adopt CDKTF for new projects. Teams still running CDKTF should plan migration to either Pulumi (use pulumi convert --from terraform) or plain Terraform/OpenTofu HCL. Historically, CDKTF addressed the use case of writing Terraform configs in TypeScript/Python — that niche is now better served by Pulumi with its own native provider registry or by OpenTofu with HCL. If you depend on a specific Terraform provider unavailable in Pulumi, use OpenTofu directly rather than CDKTF.

Switching between any of these is a significant undertaking because state formats are incompatible. Pulumi → CDK or CDKTF requires reimporting all resources into the new state backend. CDK → Pulumi requires exporting CloudFormation stacks and reimporting. CDKTF → Pulumi is the easiest because both can use Terraform state. Budget 2–4 weeks per production account for migration. The safest approach is to provision new infrastructure in the target tool and gradually migrate existing resources during planned maintenance. Existing stacks cannot be imported wholesale — in practice, teams migrate module-by-module over 2–4 weeks, running old and new stacks in parallel until every resource has been re-provisioned and validated under the new toolchain.