Pulumi now runs your Terraform as-is and makes HCL a first-class language

August 4, 2026. January 2026, private beta. August 2026, general availability. Pulumi announced that its engine now runs HCL and Terraform state as first-class citizens, and converts Terraform modules into multilingual components. No syntactical difference from Terraform or OpenTofu. Why it matters: Pulumi’s historical pitch — “write your infrastructure in a real language” — is inverting. The new message is “bring your Terraform estate as-is.” The IaC war is no longer about syntax; it is about who runs the state and the automation around it.

The strategic pivot

Since its founding, Pulumi has built its identity against Terraform: where the latter imposed the HCL DSL, Pulumi offered TypeScript, Python, Go, .NET, Java, and YAML. The argument held — loops, typing, standard libraries — but it carried a cost: any migration from Terraform required a rewrite, and the vast Terraform module ecosystem stayed at bridge’s reach, never native.

The August 2026 release closes that gap from the top. The launch post, signed Daniel Perlovsky and titled “Bring Your Terraform Estate Into the Agentic Era,” no longer talks about replacing Terraform: it talks about absorbing it. The product is built on three pillars that read as one strategic move.

Three pillars, one direction

First pillar: Terraform state in Pulumi Cloud. Pulumi Cloud becomes a full Terraform backend, compatible with Terraform and OpenTofu. plan and apply run remotely on hosted runners, with logs streamed back to your terminal and persisted in the console, plus support for manual approvals. Configuration and secrets go through ESC, which injects OIDC credentials at apply time and exposes outputs to downstream stacks. On top sit preventive policies, which block a non-compliant resource before it reaches production, and Neo code reviews, the infrastructure agent that judges whether a pull request is safe to merge — compatible with Terraform and OpenTofu.

Second pillar: Terraform modules for everyone. The Pulumi Cloud private registry now accepts Terraform modules natively and automatically converts them into typed Pulumi components, usable from TypeScript, Python, Go, .NET, Java, or YAML. A module written once becomes consumable by any team, in any language — the language boundary disappears at the module level, not just the configuration level.

Third pillar: HCL joins the family. HCL becomes a fully supported Pulumi language alongside the other six. HCL programs get the full ecosystem — thousands of providers, Pulumi Cloud, ESC, policies, Neo — and the runtime is OpenTofu-compatible, with published compatibility tests and no syntactical differences.

# An HCL program executed natively by the Pulumi engine
resource "aws_s3_bucket" "assets" {
  bucket = "assets-acme-prod"
  tags = {
    owner = "platform"
  }
}

output "bucket_arn" {
  value = aws_s3_bucket.assets.arn
}

The technical scope is twofold. On one side, Pulumi emulates Terraform’s data model on its own engine — an engineering post by Ian Wahbe details that mapping. On the other, it tests its HCL runtime’s compatibility against OpenTofu. The result is an engine that claims to run Terraform without being a fork of it.

What it changes for existing Terraform users

The proposition is aimed first at organizations heavily invested in Terraform. Instead of rewriting, they point Pulumi Cloud at their existing state and immediately gain three things historical Terraform charges dearly for: remote execution (no more apply from a laptop), preventive policies on the plan, and automated code reviews from Neo. The state stays theirs, but the execution infrastructure around it changes hands.

The switch is not neutral, though. State is the most sensitive piece of an IaC chain: it holds implicit credentials, the exact topology of the estate, sometimes poorly filtered secrets. Handing it to Pulumi Cloud is a platform choice, with the same sovereignty, availability, and cost questions as any move to a vendor. That is precisely the calculation the announcement tries to tip: in exchange for a hosted backend, the team delegates execution, policies, and AI review.

What it changes for those who have not adopted it yet

For a greenfield project, the announcement removes Pulumi’s main objection: “I prefer HCL.” That preference no longer forces you to stay on Terraform. A team can write OpenTofu-compatible HCL, run on the Pulumi engine, consume the community’s Terraform modules, and switch to TypeScript or Go when loops and typing become necessary — without changing its state platform or engine.

It is also an answer to the question posed since the fork: after Terraform’s BSL license and HashiCorp’s acquisition by IBM, where does the community go? OpenTofu offered open governance; Pulumi now offers an alternative engine that accepts HCL and Terraform state without depending on either. The two paths no longer exclude each other: a Pulumi backend can run OpenTofu.

A second, quieter consequence is tooling consolidation. Teams that today juggle Terraform for some projects and Pulumi for others can collapse both onto one engine, one state backend, and one review workflow. That consolidation carries an operational cost the announcement does not mention — the state backend becomes a single point of failure and a single trust boundary — but for organizations already paying for two sets of runners, policies, and review bots, it is a real simplification.

What the announcement does not fix

Keep both feet on the ground on two points. First, running Terraform on the Pulumi engine changes nothing about the license question: existing HCL configurations remain what they are, and the BSL subject does not disappear because a third-party engine executes them. The guarantee of open governance remains the preserve of OpenTofu, not of a proprietary hosted backend.

Second, Pulumi’s HCL runtime is young. Its compatibility is announced and tested against OpenTofu, but the gap between “compatible” and “proven in production across thousands of stacks” closes in months, not in press releases. A team that migrates a sensitive estate will discover it on edge cases — an exotic provider, a twisted dynamic block, an inherited state dependency. Prudence says migrate a non-critical perimeter first, measure, then extend.

Verdict

If you already run Terraform and the rewrite was what held you back, try pointing the state of a non-critical estate at Pulumi Cloud: you gain remote execution, plan-level policies, and Neo reviews without touching your code. Measure before extending — the cost and sovereignty of a hosted backend are calculated, not assumed.

If you are starting a project and your team prefers HCL, Pulumi is now a complete option: an OpenTofu-compatible HCL runtime, consumable Terraform modules, and a growth path toward general-purpose languages if the need arises. Syntax preference is no longer the deciding criterion.

If you are an existing Pulumi team, the win is the ecosystem: the private registry imports Terraform modules and converts them into typed components, closing the coverage gap on niche providers without abandoning your languages.

References

• Full support for Terraform state, modules, and HCL — Pulumi Releases, August 2026
• Bring Your Terraform Estate Into the Agentic Era — Pulumi Blog, Daniel Perlovsky, August 4, 2026
• Emulating Terraform on Pulumi’s Engine — Pulumi Blog, Ian Wahbe, August 4, 2026
• Compatibility Testing Pulumi HCL — Pulumi Blog, Ian Wahbe, August 14, 2026
• Pulumi Adds Native Support for Terraform and HCL — InfoQ, January 2026