By Pulumi went generally available on August 4 with three changes that reframe the Terraform vs. Pulumi argument: HCL is now a first-class Pulumi language, Pulumi Cloud is now a Terraform state backend, and Pulumi can run existing Terraform modules natively. The pitch is no longer “migrate from Terraform.” It is “keep everything you have and add Pulumi on top.”
Three Things That Went GA
The announcement bundles three distinct capabilities, each one aimed at a different kind of Terraform team.
HCL as a First-Class Language
Pulumi’s engine now runs HCL natively. Set runtime: hcl in Pulumi.yaml, point it at your existing .tf files, and run pulumi up. No syntax changes. No code rewrite. Your infrastructure deploys through Pulumi’s engine while you keep writing the HCL you already know.
This is the part that surprises people. Pulumi’s original value proposition was “write infrastructure in TypeScript, Python, or Go — not some proprietary DSL.” Adding HCL as an equal-status language inverts that. It is not a migration tool. It is a runtime. And from TypeScript or Python programs, you can import HCL modules at runtime via the @pulumi/hcl package, so mixed-language shops can consume shared Terraform modules without rewriting them.
Pulumi Cloud as Your Terraform State Backend
This is the lowest-friction option. You do not touch your Terraform code or your Terraform CLI workflow. You update the backend block in your configuration to point to tf.pulumi.com, export a token, and run terraform init -migrate-state. Three steps. State migrates from S3, Azure Blob, GCS, or local storage. Done.
What you get immediately: encrypted state, state locking, audit history, RBAC, and a unified view of your infrastructure alongside any Pulumi stacks you run. Teams evaluating HCP Terraform alternatives after IBM’s $6.4 billion acquisition of HashiCorp now have a concrete path that does not require rewriting a single .tf file.
Native Terraform Module Execution
Large organizations run shared Terraform module libraries — the modules handle VPC configs, IAM policies, database clusters, the stuff nobody wants to rewrite. Pulumi can now execute those modules directly from TypeScript, Python, or Go programs. The module library stays in HCL. The orchestration layer moves to a general-purpose language. Both work.
The AI Agents Angle
Here is why the timing matters beyond Terraform compatibility. Pulumi says over 40 percent of its users now manage infrastructure using AI agents. Pulumi Neo, its built-in infrastructure AI agent, can now govern Terraform-managed resources: it runs preventive policies after a terraform plan, blocks non-compliant resources before deployment, and surfaces drift across both Pulumi and Terraform stacks. Early adopters report cutting provisioning time from three days to four hours.
Terraform-only shops do not have this. OpenTofu does not have this. If AI-agent-driven infrastructure is where your team is heading — and the evidence suggests it is where the industry is heading — being Terraform-locked increasingly means being tool-locked.
Who Should Care
If you are a Terraform team on HashiCorp Cloud Platform and IBM’s acquisition has you looking at alternatives, the Pulumi Cloud state backend is the most direct swap. Three config lines, no rewrite, and you get encrypted state and RBAC on day one.
If you are on OpenTofu and things are working, there is no urgency here. OpenTofu is MPL-2.0 licensed, ships faster than Terraform, and sits at 95 percent feature parity. The grass is not obviously greener.
If you want AI agent governance over your infrastructure and you are currently running Terraform state in S3, migrating state to Pulumi Cloud is now the entry point — and it costs nothing on the individual tier.
What to Do Now
The lowest-risk first step is the state backend migration. It takes fifteen minutes and is fully reversible. From there, the question is whether HCL-on-Pulumi or a gradual conversion to TypeScript or Python makes more sense for new infrastructure modules. That decision does not need to be made today.
The official GA announcement covers all three capabilities in detail. The state backend migration guide walks through the three-step process. The Neo agent documentation covers policy enforcement across Terraform-managed state.
