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

Pulumi vs. Terraform

    Pulumi and HashiCorp Terraform are both declarative infrastructure as code tools with overlapping capabilities and several meaningful differences. Pulumi lets you define infrastructure in general-purpose languages (Python, TypeScript, JavaScript, Go, .NET, Java, or YAML) and supports any cloud or SaaS provider through the Pulumi Registry; Terraform uses HashiCorp Configuration Language (HCL) with HashiCorp’s provider ecosystem.

    This page covers what each tool is, a feature-by-feature comparison, the most important differences in detail, and the available paths for adopting Pulumi alongside or instead of Terraform.

    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.

    Pulumi’s provider ecosystem covers the major hyperscalers and SaaS platforms. Several providers are generated directly from upstream API schemas, including Kubernetes, Azure Native, AWS Cloud Control, and Google Cloud Native, so new resources and API versions land without waiting for a hand-authored release.

    What is Terraform?

    Terraform is an infrastructure as code tool created by HashiCorp (acquired by IBM in February 2025). Programs are written in HashiCorp Configuration Language (HCL), a domain-specific language. Terraform supports many cloud and SaaS providers through its provider ecosystem. The Terraform CLI is distributed under the Business Source License 1.1, and HashiCorp also offers HCP Terraform (formerly Terraform Cloud) and Terraform Enterprise as commercial products for managed state, remote runs, policy, and team workflows.

    Detailed comparison

    FeaturePulumiTerraform
    Language supportPython, TypeScript, JavaScript, Go, .NET, Java, and YAML — general-purpose languages with familiar syntax for loops, conditionals, and abstractionsHashiCorp Configuration Language (HCL) — a configuration-focused DSL whose syntax for control flow and dynamic blocks grows harder to read as project complexity increases
    Cloud and service supportPulumi Registry of packages, including bridged, native, parameterized, and dynamic providers; schema-generated native providers include Kubernetes, Azure Native, AWS Cloud Control, and Google Cloud Native; any Terraform provider can be adapted into a Pulumi providerHashiCorp- and community-maintained providers in the Terraform Registry
    Transpiled to another format?No — programs run directly in their host languageNo — HCL is interpreted directly by the Terraform CLI
    State managementManaged by Pulumi Cloud by default; self-managed backends include S3, Azure Blob Storage, Google Cloud Storage, local files, and othersLocal files by default; remote backends include S3, Azure Blob Storage, Google Cloud Storage, Consul, and HCP Terraform’s managed state
    Secrets managementEncrypted in transit and at rest by default in the state file, with per-stack encryption keys; pluggable KMS providers (AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault)Sensitive values are not encrypted in the state file; HCP Terraform encrypts state at rest, and Vault integration is a separate product
    Execution modelLocal CLI, programmatic via Automation API, or remote runs in Pulumi Cloud DeploymentsLocal CLI or remote runs in HCP Terraform / Terraform Enterprise
    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 codeFailed applies leave the workspace in a partially-applied state; subsequent terraform apply runs reconcile toward the desired state, and you can roll forward by reverting program code
    Programmatic API for tools and platformsAutomation API — a programmatic SDK for building custom CLIs, internal developer platforms, and services that stand up ephemeral environments without shelling out to the Pulumi CLINo equivalent
    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 (npm, PyPI, NuGet, Maven, Go modules); and the Pulumi Registry for publicly available packagesTerraform modules (HCL) and the Terraform Registry for public modules
    Import existing resourcespulumi import and the import resource option, both of which generate code in your languageterraform import and import blocks; HCL must be hand-authored, though terraform plan -generate-config-out can emit a draft
    Policy as codePulumi Policies — open source, with rules written 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 SOC 2Sentinel (proprietary, HCP Terraform / Enterprise only) and Open Policy Agent
    Open sourceYes — Apache License 2.0No — Business Source License 1.1
    Commercial optionPulumi CloudHCP Terraform / Terraform Enterprise

    Key differences

    Language support and the authoring experience

    Terraform requires HCL, a domain-specific language designed for configuration. HCL fits compactly into small projects but lacks the abstractions of a general-purpose language: there are no classes, limited runtime logic, and reuse only through the module system. Pulumi programs are written in general-purpose languages, so authors get loops, conditionals, classes, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems. Pulumi also supports YAML for users who prefer a markup format.

    Provider and cloud coverage

    Both tools have large provider ecosystems. Pulumi can use any provider published in the Pulumi Registry, and it can adapt any existing Terraform provider into a Pulumi provider — see types of providers for the difference between bridged, native, parameterized, and dynamic providers. In addition, Pulumi maintains native providers for Kubernetes, Azure Native, AWS Cloud Control, and Google Cloud Native that are generated directly from each platform’s API schema, which lets them ship same-day support for new APIs and features rather than waiting for a hand-authored provider release.

    Execution and orchestration

    Both tools provide a CLI and a managed remote-run service: Pulumi Cloud Deployments for Pulumi, and HCP Terraform for Terraform. Pulumi additionally exposes the Automation API, a programmatic SDK that lets you drive up, preview, and destroy from inside another program — for example, to ship a CLI that wraps Pulumi, build a self-service portal for application teams, or orchestrate many stacks dynamically from a higher-level service. Terraform does not have a programmatic equivalent.

    Secrets handling

    Pulumi treats secrets as a first-class primitive. Values marked as secrets are encrypted in transit and at rest in the state file, anything derived from a secret is also encrypted, and each stack has its own encryption key. The default encryption provider can be replaced with AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. Terraform does not encrypt sensitive values in its state file; the recommended approach is to integrate with HashiCorp Vault, which is a separate product. HCP Terraform encrypts state at rest, but values inside that state are still readable to anyone with access to the workspace.

    Policy as code

    Pulumi Policies is open source and free. Policies can be written in Python, TypeScript, or Open Policy Agent Rego, and Pulumi Cloud adds centralized management, policy groups, and enforcement across stacks. Pulumi Cloud commercial plans also include Pulumi-maintained policy packs for common compliance frameworks (CIS, PCI DSS, SOC 2, HITRUST, NIST) so teams don’t have to author and maintain those rules themselves. Terraform’s first-party policy framework, Sentinel, is proprietary and only available in HCP Terraform and Terraform Enterprise. Open Policy Agent can also be used with Terraform via external tooling.

    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. Terraform modules are static HCL units that organize source code, with module instances appearing flat in state.

    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. Terraform is invoked through its CLI (or HCP Terraform’s remote runs) and does not provide an equivalent embeddable SDK.

    When to choose Pulumi vs. Terraform

    Choose Pulumi when you:

    1. Want to write infrastructure in a general-purpose language and use the testing frameworks, package managers, and IDE tooling that already exist in that ecosystem.
    2. Need an embeddable SDK (Automation API) to drive deployments from a host application (internal developer platforms, SaaS products, or ephemeral preview environments per pull request).
    3. Want built-in secrets encryption, pluggable KMS providers, and per-stack encryption keys without bolting on a separate service.
    4. Need open source policy as code (Pulumi Policies under Apache 2.0, with rules in Python, TypeScript, or Open Policy Agent Rego) rather than a proprietary framework gated behind a commercial tier.
    5. Prefer an Apache 2.0-licensed core (Pulumi CLI and SDKs) over Terraform’s Business Source License 1.1.

    Choose Terraform when you:

    1. Have a large existing investment in HCL, modules, and team expertise that you don’t want to migrate.
    2. Depend on HCP Terraform–specific features such as Sentinel policies, run tasks, or no-code provisioning that are tightly coupled to HashiCorp’s managed service.
    3. Want to standardize on a single tool when your scope is limited to providers that already exist in the Terraform Registry and you don’t need an embeddable SDK or cross-language module sharing.

    The two can also coexist; see Adoption below.

    Adoption: coexistence, conversion, and import

    There are several common paths for adopting Pulumi alongside or in place of Terraform, and they can be combined:

    1. Use Terraform alongside Pulumi. Pulumi programs can reference an existing Terraform state file (local or remote) and read outputs from it, which lets you keep some infrastructure in Terraform while you incrementally adopt Pulumi for new work.
    2. Use Pulumi Cloud as a Terraform state backend. Pulumi Cloud can store Terraform state for teams that want encrypted state, update history, state locking, RBAC, and audit policies while continuing to run Terraform or OpenTofu day-to-day.
    3. Use existing Terraform providers from Pulumi. The Terraform bridge lets Pulumi adapt any Terraform provider, so you can manage resources from a Terraform-only ecosystem in a Pulumi program. Many providers in the Pulumi Registry are built this way.
    4. Consume Terraform modules from Pulumi. Pulumi can use existing Terraform modules directly from a Pulumi program, so investments in module ecosystems (community modules, internal modules) carry forward.
    5. Convert HCL to Pulumi. pulumi convert --from terraform translates Terraform HCL into a Pulumi program in the language of your choice, preserving names, modules, and structure where possible.
    6. Import existing resources. pulumi import and the import resource option bring already-provisioned cloud resources under Pulumi management and generate the corresponding code in your chosen language.

    For a complete walkthrough including bulk conversion and state migration, see Migrating from Terraform to Pulumi.

    Frequently asked questions

    Can Pulumi use existing Terraform providers?

    Yes. The any-Terraform-provider feature lets Pulumi adapt any provider published in the Terraform Registry into a Pulumi provider, so resources from a Terraform-only ecosystem can be managed from a Pulumi program. Many providers in the Pulumi Registry are built this way — see types of providers for the differences between bridged, native, parameterized, and dynamic providers.

    Can Pulumi consume existing Terraform modules?

    Yes. Pulumi can use existing Terraform modules directly from a Pulumi program, so investments in community and internal HCL modules carry forward as you adopt Pulumi.

    How do I migrate from Terraform to Pulumi?

    You have three options that can be combined: convert HCL with pulumi convert --from terraform, bring already-provisioned resources under Pulumi management with pulumi import, or run both tools side by side and reference existing Terraform state from Pulumi until you’re ready to cut over. See the migration guide for a full walkthrough.

    Is Pulumi free and open source like Terraform used to be?

    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. Note that Terraform is no longer open source: since version 1.6 it has been distributed under the Business Source License 1.1. OpenTofu is the MPL-2.0 open source fork maintained by the Linux Foundation.

    Does Pulumi support remote state and state locking like Terraform?

    Yes. By default, Pulumi Cloud manages state with state locking, history, and access control. Self-managed backends include Amazon S3, Azure Blob Storage, Google Cloud Storage, and local files, with state locking supported on the cloud backends.

    Can I keep using Terraform but store state in Pulumi Cloud?

    Yes. Pulumi Cloud as a Terraform state backend stores Terraform state with encryption, update history, state locking, RBAC, and audit policies for teams that want a managed state experience while continuing to run Terraform or OpenTofu day-to-day.

    How does Pulumi handle drift detection?

    pulumi refresh compares the state file to the actual state in the cloud and reports differences, and pulumi preview --diff shows what would change on the next update. Pulumi Cloud commercial plans add scheduled drift detection and remediation that runs on a configurable cadence and can auto-remediate.

    Next steps