Skip to main content
  1. Docs
  2. Infrastructure as Code
  3. Comparisons
  4. CDKTF

Pulumi vs. CDKTF

    As of December 2025, CDK for Terraform (CDKTF) has been deprecated and its GitHub repository has been archived. This page is preserved for teams evaluating migration paths.

    Pulumi and CDK for Terraform (CDKTF, deprecated December 2025) are both infrastructure as code tools that let you author cloud resources in general-purpose programming languages. They differ in how programs are turned into provisioned infrastructure: Pulumi runs programs directly through its own deployment engine and supports any cloud or SaaS platform through the Pulumi Registry, while CDKTF transpiled programs into Terraform JSON for deployment by the Terraform CLI.

    This page covers what each tool is, a feature-by-feature comparison, the most important differences in detail, and the available paths for migrating from CDKTF to Pulumi.

    What is Pulumi?

    Pulumi is an infrastructure as code platform for provisioning and managing resources across any cloud or SaaS platform. Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as YAML. The Pulumi Registry covers all major clouds, including first-party native providers that are generated from upstream API schemas for same-day coverage of new platform features. The Pulumi CLI and SDKs are open source under the Apache 2.0 license. Pulumi Cloud is the commercial product that adds managed state, secrets, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale.

    Many of Pulumi’s most popular providers are derived from the same open-source Terraform provider schemas that CDKTF used, so their resource models are typically identical and migration is usually a code-shape change rather than a re-architecture.

    What is CDKTF?

    CDK for Terraform (CDKTF) was a HashiCorp project, released in 2020 and deprecated in December 2025, that let you define infrastructure in TypeScript, Python, Go, C#, and Java. CDKTF was a transpiler (a.k.a. source-to-source compiler): cdktf synth produced Terraform JSON, which was then deployed by the Terraform CLI against the open-source Terraform provider ecosystem. The GitHub repository is archived and no longer receives updates.

    Detailed comparison

    FeaturePulumiCDKTF
    Language supportPython, TypeScript, JavaScript, Go, C#, Java, and YAMLTypeScript, Python, Go, C#, Java
    Cloud and service supportPulumi Registry of packages, including bridged, native, parameterized, and dynamic providers; first-party native providers for Kubernetes and Azure Native; any Terraform provider can be adapted into a Pulumi provider, and Terraform modules can be consumed directlyTerraform providers only, accessed through project-specific SDKs generated on demand by cdktf get
    Transpiled to another format?No — programs run directly in their host languageYes — programs are synthesized into Terraform JSON and deployed by the Terraform CLI
    State managementManaged by Pulumi Cloud by default; self-managed backends include Amazon S3, Azure Blob Storage, Google Cloud Storage, local files, and othersLocal, remote, or cloud-hosted (the Terraform state model)
    Secrets managementEncrypted in transit and at rest in the state file by default, with per-stack encryption keys; pluggable KMS providers (AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault)No built-in secrets primitive
    Execution modelLocal CLI, programmatic via Automation API, or remote runs in Pulumi DeploymentsTerraform CLI only (invoked by the cdktf CLI)
    Rollback on failed operationFailed updates leave the stack in a partially-updated state; subsequent pulumi up runs reconcile toward the desired state, and you can roll forward by reverting program codeNo automatic rollback; reconciliation requires fixing code and re-running terraform apply
    Programmatic API for tools and platformsAutomation API — a programmatic SDK for building custom CLIs, internal developer platforms, and services that drive up, preview, and destroy without shelling out to the Pulumi CLINone
    Modularity and reuseComponent Resources authored in any supported language; Pulumi Packages let a component written in one language be consumed from any Pulumi language; language-native package managers; and the Pulumi Registry for publicly available packagesCDKTF constructs (built on the constructs library) and direct consumption of Terraform modules
    Import existing resourcespulumi import and the import resource option, both of which generate code in your languagecdktf import and terraform import, with hand-authored code wrappers
    Policy as codePulumi Policies — open source, with rules in Python, TypeScript, or Open Policy Agent Rego; Pulumi Cloud commercial plans add centralized policy management plus Pulumi-maintained policy packs for compliance frameworks like CIS, PCI DSS, and NISTNone first-party; teams typically integrated OPA or Sentinel (Terraform Cloud commercial plans) against the synthesized Terraform JSON
    Open sourceYes — Apache License 2.0The CDKTF framework was Mozilla Public License 2.0 until archived; the Terraform CLI that deployed its output moved to the Business Source License 1.1 in 2023
    Commercial optionPulumi CloudHashiCorp Cloud Platform (HCP Terraform, formerly Terraform Cloud); CDKTF itself had no separate commercial tier

    Key differences

    Language support and the authoring experience

    Pulumi and CDKTF both let you author infrastructure in general-purpose languages. Pulumi additionally supports YAML and runs programs directly through its deployment engine, so programs can be unit-tested against their own object graph using the Pulumi testing tools. CDKTF programs were always synthesized to Terraform JSON before deployment, so testing centered on assertions against the synthesized JSON.

    Cloud and service coverage

    CDKTF supported Terraform providers through project-specific SDKs generated on demand by cdktf get. Pulumi supports the Pulumi Registry of pre-built providers — including native providers for Kubernetes and Azure Native generated directly from each platform’s API schema for same-day coverage of new resources — and can additionally generate typed SDKs on demand for any Terraform provider. Pulumi also supports referencing Terraform modules directly without rewriting them, so existing module investment is preserved during migration.

    Execution and rollbacks

    CDKTF provisioned and managed exclusively through the Terraform CLI: cdktf synth produced Terraform JSON, then cdktf deploy invoked terraform apply on it. Pulumi runs deployments through the local CLI, programmatically through the Automation API, or remotely through Pulumi Deployments. Neither tool performs automatic rollback on failure; both leave failed updates in a partially-updated state for the operator to reconcile.

    Secrets handling

    Pulumi has built-in support for secrets management, encrypting sensitive data in the state file in transit and at rest with per-stack encryption keys. The default encryption provider can be replaced with AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. Pulumi ESC adds centralized secrets management, integration with third-party services, and dynamic credential retrieval via OpenID Connect. CDKTF had no built-in secrets management.

    Policy as code

    Pulumi Policies is open source and free, with rules written in Python, TypeScript, or Open Policy Agent Rego. Pulumi Cloud adds centralized management and Pulumi-maintained policy packs for frameworks like CIS, PCI DSS, and NIST. CDKTF had no first-party policy engine; teams typically wired up Open Policy Agent against synthesized Terraform JSON, or relied on Sentinel (commercial Terraform Cloud / HCP Terraform).

    Modularity and reuse

    Pulumi’s Component Resources are runtime objects with explicit parent/child relationships, so a component and the resources inside it form a coherent unit in plan output, deletion, and state. Components can be authored in one language and consumed from any other supported language by publishing them as a Pulumi Package. CDKTF offered constructs built on the constructs library and direct consumption of existing Terraform modules.

    Automation API

    The Automation API lets a host application drive Pulumi without shelling out to the CLI. Practical uses include embedding stack creation in a SaaS product, building an internal developer platform that provisions environments per team or per branch, generating ephemeral preview environments from CI, and orchestrating cross-cloud deployments where each step runs as part of a larger workflow. CDKTF had no equivalent embeddable SDK.

    When to choose Pulumi vs. CDKTF

    Choose Pulumi when you:

    1. Need an actively maintained, supported infrastructure as code platform — CDKTF was deprecated in December 2025 and no longer receives updates.
    2. Want one tool that targets the Pulumi Registry, Terraform providers, and Terraform modules from the same program.
    3. Need built-in secrets encryption, pluggable KMS providers, and per-stack encryption keys.
    4. Need an embeddable SDK (Automation API) to drive deployments from a host application.
    5. Want a free, open-source policy-as-code engine with rules in Python, TypeScript, or Rego.

    Choose CDKTF when you:

    1. Have an existing, working CDKTF deployment and are not yet ready to migrate. Because CDKTF is deprecated and unmaintained, the only durable choice in this case is to plan a migration — see Adoption below.

    Adoption: coexistence, conversion, and import

    There are several common paths for migrating from CDKTF to Pulumi, and they can be combined:

    1. Use Terraform/CDKTF state alongside Pulumi. Pulumi can reference local or remote Terraform state — including the state produced by a CDKTF deployment — from a Pulumi program. This lets you continue managing a subset of your infrastructure with CDKTF (or Terraform) while incrementally moving the rest to Pulumi.
    2. Consume Terraform modules directly. Pulumi can reference Terraform modules directly by generating language-specific SDKs on demand, so existing module investment is preserved.
    3. Convert with pulumi convert --from terraform. Run cdktf synth to produce Terraform JSON, then convert that JSON to Pulumi with pulumi convert --from terraform. For state, pulumi-terraform-migrate translates Terraform state into Pulumi state.
    4. Import existing resources. pulumi import and the import resource option bring already-provisioned resources under Pulumi management and generate the corresponding code in your chosen language.
    5. Automated migration with Pulumi Neo (recommended). Pulumi Neo automates code conversion and state migration, then runs pulumi preview to verify zero changes before you commit. See Migrating from Terraform/CDKTF to Pulumi.

    For a complete walkthrough, see Migrating from Terraform or CDKTF to Pulumi.

    Frequently asked questions

    Is CDKTF deprecated?

    Yes. HashiCorp deprecated CDKTF in December 2025 and archived its GitHub repository. The project no longer receives bug fixes, security updates, or new features.

    Pulumi is a direct replacement because it covers the same primary use case — defining infrastructure in TypeScript, Python, Go, C#, or Java — without a transpilation step, and it supports the same Terraform providers and Terraform modules that CDKTF relied on. See Migrating from Terraform or CDKTF to Pulumi.

    How do I migrate from CDKTF to Pulumi?

    You have several options that can be combined: use Pulumi Neo for automated conversion and import; run cdktf synth to produce Terraform JSON and convert with pulumi convert --from terraform; migrate state with pulumi-terraform-migrate; or use pulumi import to bring resources under Pulumi management resource-by-resource.

    Can I keep my Terraform state when migrating from CDKTF?

    Yes. pulumi-terraform-migrate translates an existing Terraform state file (including state produced by CDKTF) into Pulumi state, so the underlying resources are not destroyed or replaced. Pulumi can also reference local or remote Terraform state during incremental migrations.

    Does Pulumi support Terraform modules and providers?

    Yes. Pulumi can adapt any Terraform provider and can reference Terraform modules directly by generating language-specific SDKs on demand. Many of Pulumi’s most popular registry providers are also derived from upstream Terraform provider schemas, so resource models often map one-to-one with CDKTF code.

    Can Pulumi coexist with existing Terraform or CDKTF deployments?

    Yes. Pulumi programs can reference local or remote Terraform state, so you can continue running CDKTF (or Terraform) for a subset of infrastructure while building new work in Pulumi and incrementally migrating.

    Is Pulumi free like CDKTF was?

    The Pulumi CLI and SDKs are open source under Apache 2.0 and free to use. Pulumi Cloud has a free Individual tier and paid plans that add managed state, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale. CDKTF itself was free and open source under MPL 2.0; the Terraform CLI that deployed its output moved to the Business Source License 1.1 in 2023.

    Next steps