Pulumi’s 2026 interoperability improvements let organizations retain Terraform workflows, share infrastructure modules across languages and run HCL through the Pulumi engine. The options reduce some migration barriers, but each has different implications for state, execution and resource ownership.
An infrastructure team may have years of work invested in Terraform modules, deployment pipelines and production state. Moving to another infrastructure-as-code platform can mean rewriting configuration, changing delivery processes and validating resources that already work.
Pulumi’s August 2026 release expands the ways teams can use Terraform, OpenTofu (an open-source Terraform-compatible implementation) and Pulumi together without replacing everything at once. The release brings together three capabilities: Terraform state and execution through Pulumi Cloud, Terraform module interoperability across languages, and HCL (HashiCorp Configuration Language, the language of Terraform configuration files) as a Pulumi programming language. These are different approaches. Understanding that distinction is more useful than treating the release as a single migration feature.
Three capabilities, three different changes
| Capability | What changes | What remains important |
|---|---|---|
| Terraform backend and remote execution | Terraform state and optional execution move to Pulumi Cloud | Terraform or OpenTofu workflows remain, with remote execution subject to Pulumi Cloud’s execution model |
| Terraform module interoperability | Existing modules can be published, consumed and reused across supported languages | Module execution, dependencies and compatibility still require validation |
| Pulumi HCL runtime | HCL configuration runs on the Pulumi engine | Pulumi state and resource ownership replace the Terraform execution model |
The difference begins with two concepts. Configuration describes the infrastructure a team wants. State records the real resources associated with an infrastructure management workflow.
Moving state storage does not necessarily change the engine that applies configuration. Running the same HCL through a different engine, however, changes more than the location of a state file.
Source: Pulumi, Full Support for Terraform State, Modules and HCL, August 2026.
1. Keep Terraform and use Pulumi Cloud for state
A team can continue writing HCL and running familiar Terraform or OpenTofu commands while storing state in Pulumi Cloud. The backend provides centralized state management, locking, access controls, update history and visibility into managed resources. This arrangement does not turn Terraform-managed resources into Pulumi-engine-managed resources. The existing workflow can remain largely intact.
Pulumi Cloud also offers remote execution, but this must be distinguished from using it only as a state backend. With local execution, the Terraform or OpenTofu CLI runs operations in the team’s own environment while Pulumi Cloud stores the state. With remote execution, the CLI sends configuration to Pulumi Cloud, where managed infrastructure performs the plan or apply.
An important implementation detail is that Pulumi Cloud’s remote runner uses OpenTofu as its execution engine, even when the operation was initiated through the Terraform CLI. The managed OpenTofu version is currently controlled by Pulumi Cloud rather than selected by the customer.
Remote execution also has specific limitations, including unsupported -var flags and the absence of configurable custom executor images. Those differences matter for teams whose existing pipelines depend on particular Terraform versions, command-line arguments or runner customization.
Local execution
A team can continue writing HCL and running familiar Terraform or OpenTofu commands while storing state in Pulumi Cloud. With local execution, the Terraform or OpenTofu CLI runs operations in the team’s own environment while Pulumi Cloud stores the state.
Remote execution
With remote execution, the CLI sends configuration to Pulumi Cloud, where managed infrastructure performs the plan or apply. An important implementation detail is that Pulumi Cloud’s remote runner uses OpenTofu as its execution engine, even when the operation was initiated through the Terraform CLI.
Limits to check
The managed OpenTofu version is currently controlled by Pulumi Cloud rather than selected by the customer. Remote execution also has specific limitations, including unsupported -var flags and the absence of configurable custom executor images.
Sources: Pulumi, Store Terraform State in Pulumi Cloud and Remote Execution for Terraform and OpenTofu.
2. Share Terraform modules across languages
Terraform modules often represent established infrastructure standards. A platform team might maintain modules for networks, databases, storage or access controls. Rewriting these components solely because another team wants to use Python or TypeScript creates work and introduces potential differences. Pulumi’s interoperability features provide two related approaches.
Module registry and generated components. Teams can publish Terraform modules to Pulumi Cloud’s private registry. The platform can expose them to Terraform and OpenTofu consumers and generate typed components for Pulumi-supported languages.
Any HCL Module integration. Pulumi programs can use existing Terraform modules through an integration that uses OpenTofu to execute the module, maps supplied inputs to Terraform variables and exposes the results as Pulumi outputs.
The Any HCL Module mechanism manages its module resources through the Pulumi state backend. It is not the same thing as independently running an existing Terraform root configuration with its original state. Generated SDKs can provide typed inputs and outputs, while dynamic module loading offers more flexibility at the expense of some type safety.
The practical benefit is reusing tested infrastructure definitions across teams with different programming preferences. The remaining responsibility is compatibility testing. Modules with complex provider dependencies or execution assumptions still need validation in their intended environment.
Module registry
Teams can publish Terraform modules to Pulumi Cloud’s private registry. The platform can expose them to Terraform and OpenTofu consumers and generate typed components for Pulumi-supported languages.
Any HCL Module
Pulumi programs can use existing Terraform modules through an integration that uses OpenTofu to execute the module, maps supplied inputs to Terraform variables and exposes the results as Pulumi outputs. The Any HCL Module mechanism manages its module resources through the Pulumi state backend.
What you still test
The remaining responsibility is compatibility testing. Modules with complex provider dependencies or execution assumptions still need validation in their intended environment.
Source: Pulumi, Use Terraform Modules in Pulumi.
3. Run HCL through the Pulumi engine
The third capability changes the infrastructure execution model. Pulumi supports HCL as a language for its engine. Teams can retain familiar .tf configuration syntax while using Pulumi’s resource lifecycle and state management. This may reduce the effort required to evaluate Pulumi without rewriting an entire configuration into another programming language.
However, Terraform state does not automatically become Pulumi state. Existing resources must be brought under Pulumi management through an explicit import process.
Pulumi documents the following mechanism for HCL migrations:
pulumi import --from hcl <statefile>
The import reads an existing Terraform state file and maps resources into the Pulumi stack. It is a migration operation, not an instruction to run two independent engines against the same infrastructure resources.
Before using this approach, teams must validate provider mappings, resource identities, dependencies and the resulting preview. They should avoid simultaneous management of the same resources by independent state systems.
There are also compatibility differences. For example, Terraform backend and certain other configuration settings are accepted but ignored with warnings because Pulumi manages state independently. A Terraform cloud block is not accepted. Provisioner connection support is limited, including no WinRM support.
HCL on the Pulumi engine
Pulumi supports HCL as a language for its engine. Teams can retain familiar .tf configuration syntax while using Pulumi’s resource lifecycle and state management.
Explicit import
However, Terraform state does not automatically become Pulumi state. Existing resources must be brought under Pulumi management through an explicit import process. The import reads an existing Terraform state file and maps resources into the Pulumi stack.
Check before switching
Before using this approach, teams must validate provider mappings, resource identities, dependencies and the resulting preview. They should avoid simultaneous management of the same resources by independent state systems.
Pulumi’s engineering team reported in Emulating Terraform on Pulumi’s Engine that its HCL interpreter ran 56 of the 58 most-used Terraform AWS modules, which is 96%, and that the failures were due to ephemeral resources. That is a vendor-reported result for a particular set of AWS modules, not evidence that 96% of every organization’s Terraform configurations will migrate successfully.
Sources: Pulumi, HCL Documentation, HCL Language Reference, and Emulating Terraform on Pulumi’s Engine.
What should teams choose?
Return to the infrastructure team from the opening, and suppose it operates an established Terraform environment but wants to introduce Pulumi for new application infrastructure. This is a hypothetical team, used here to compare the options. There is no requirement to migrate everything at once.
| Existing requirement | Approach to evaluate |
|---|---|
| Better centralized state management | Pulumi Cloud Terraform backend |
| Managed Terraform or OpenTofu execution | Pulumi Cloud remote execution, after validating its OpenTofu-based runner |
| Shared Terraform modules across language ecosystems | Pulumi Cloud module registry and generated components |
| Terraform modules inside Pulumi programs | Any HCL Module integration |
| HCL configuration managed by the Pulumi engine | Pulumi HCL with explicit state and resource import |
| Stable existing infrastructure with no compelling migration need | Retain the current Terraform workflow |
The right choice depends on the operational problem. A new state backend may help a team that needs centralized controls. Shared modules may help organizations supporting multiple programming languages. A different execution engine may make sense when a team wants Pulumi’s broader programming model.
None of those benefits automatically justifies migrating an established, working infrastructure estate.
Operational boundaries that still matter
Three areas deserve particular attention before production adoption.
Resource ownership. Each resource must have one clearly defined management path. Teams should know which engine applies changes and which state system records the resource.
Policy and drift detection. Pulumi Cloud can run audit policies against Terraform-managed stacks, which its documentation lists for the Essentials, Pro and Enterprise editions. Preventative policies that block a violating apply are available through remote execution, documented for the Pro and Enterprise editions. However, automated drift detection is not currently available for Terraform-managed stacks. Organizations may need scheduled plans or another existing monitoring process.
Cost and execution constraints. Terraform resources stored in Pulumi Cloud count toward resources under management. Remote execution consumes billable workflow minutes. Teams should also account for provider versions, runner limitations and existing deployment integration requirements. Provider upgrades are a common source of such constraints, as The Terraform AWS Provider Keeps Growing: Is Your Upgrade Process Ready? explains.
These are not reasons to reject interoperability. They are part of determining whether a particular integration improves the organization’s current operating model.
Sources: Pulumi, Remote Execution for Terraform and OpenTofu and Store Terraform State in Pulumi Cloud.
A practical adoption path
Teams can evaluate interoperability without launching a broad migration. If the objective is state management, test the backend with a representative non-production Terraform stack. Confirm that initialization, state migration, locking and planning work as expected.
If the objective is module reuse, select a module with meaningful dependencies and verify its behavior through the chosen integration. If the objective is Pulumi-engine adoption, test the HCL runtime with a controlled resource import and verify that the resulting preview contains no unintended changes.
These tests answer different questions. A successful backend migration does not prove HCL runtime compatibility. A reusable module does not prove the entire Terraform estate can move without redesign. The goal should be a verified improvement in the current workflow, not simply adoption of another tool.
What the release actually changes
Pulumi’s August 2026 interoperability improvements give infrastructure teams more ways to preserve existing Terraform investments while adopting selected Pulumi capabilities. They do not make Terraform, OpenTofu and Pulumi identical.
The important distinction is between where state is stored, how modules are reused and which engine manages resources. Organizations that understand those boundaries can adopt interoperability incrementally while maintaining clearer ownership and more predictable infrastructure changes.
References and further reading
- Pulumi, Full Support for Terraform State, Modules and HCL. August 2026.
- Pulumi, Now Generally Available: Store Terraform State in Pulumi Cloud. March 5, 2026.
- Pulumi, Store Terraform State in Pulumi Cloud. Official technical documentation.
- Pulumi, Remote Execution for Terraform and OpenTofu. Official execution behavior and limitations.
- Pulumi, Use Terraform Modules in Pulumi. Module interoperability.
- Pulumi, HCL Language Documentation. Engine and state compatibility.
- Pulumi, HCL Language Reference. Unsupported features and migration requirements.
- Pulumi, Emulating Terraform on Pulumi’s Engine. August 4, 2026.
Source verification: November 5, 2026. Capabilities and compatibility claims are based on Pulumi’s published documentation and engineering reports. TechiesJournal has not independently tested these production migrations. The 96 percent figure was checked against the footnote of Pulumi’s own post.