HashiCorp released Terraform 1.1 earlier this month, and while the version number increment is modest, the features signal something important about where Infrastructure as Code is heading. The headline additions — moved blocks for state refactoring and convergence with Terraform Cloud workflows — address problems that have plagued real-world Terraform usage for years.
This release feels less like “here are cool new features” and more like “we listened to the pain points.” As someone who’s been managing infrastructure as code since the Puppet and Chef days, that kind of maturity is refreshing.
The Refactoring Problem, Finally Addressed#
If you’ve managed a non-trivial Terraform codebase, you’ve hit this wall: you need to rename a resource or move it to a different module, but Terraform interprets this as “destroy the old thing and create a new thing.” For a development environment, that’s annoying. For a production database, it’s terrifying.
The traditional workaround was terraform state mv — a manual, error-prone command that operates directly on the state file. In team environments with remote state, this meant coordinating state operations carefully and hoping nobody ran a plan in between. I’ve seen teams avoid perfectly reasonable refactoring for months because the risk of a state manipulation mistake was too high.
Terraform 1.1’s moved blocks solve this declaratively:
moved {
from = aws_instance.webapp
to = module.frontend.aws_instance.webapp
}This is checked into version control, reviewed in PRs, and applied as part of a normal terraform apply. No manual state surgery, no coordination issues, no late-night incidents because someone fat-fingered a state mv command.
It seems like a small thing, but in practice it removes one of the biggest barriers to keeping Terraform codebases clean over time. Technical debt in IaC is particularly dangerous because the consequences of a bad refactoring aren’t a degraded user experience — they’re accidentally destroying production infrastructure.
Terraform Cloud Integration#
The 1.1 release also deepens the integration between the open-source CLI and Terraform Cloud. The cloud block replaces the older remote backend configuration, and the workflow for running Terraform plans remotely is more streamlined.
This matters because HashiCorp is clearly positioning Terraform Cloud (and its enterprise offering) as the default way to run Terraform in organizations. The open-source CLI remains free and fully functional, but the gravitational pull toward their managed platform is increasing.
I have mixed feelings about this. On one hand, running Terraform in a managed environment with proper state locking, access controls, policy enforcement, and audit logs is genuinely better than the typical “someone runs terraform from their laptop” workflow. Terraform Cloud solves real operational problems.
On the other hand, the increasing coupling between the open-source tool and the commercial platform follows a pattern we’ve seen before in the DevOps space. Docker’s commercial pivot, Chef’s license change, and even HashiCorp’s own Vault Enterprise feature gating all follow similar trajectories. As users, we should be clear-eyed about the business model that supports the tools we depend on.
The Broader IaC Landscape in 2022#
Terraform’s continued evolution is happening in the context of a much broader IaC ecosystem. It’s worth stepping back and looking at where the alternatives stand:
Pulumi continues to gain traction with developers who prefer writing infrastructure in real programming languages (TypeScript, Python, Go) rather than HCL. Their recent Automation API is interesting — it lets you embed infrastructure provisioning inside application code. For teams that are already deeply invested in a specific programming language, Pulumi’s approach has clear ergonomic advantages.
AWS CDK has established itself as the go-to for AWS-centric shops. The construct model is powerful, and the ability to compose high-level abstractions over CloudFormation resources reduces boilerplate significantly. The limitation, obviously, is the AWS lock-in.
Crossplane is making a serious play for the Kubernetes-native infrastructure management space. If your team is already thinking in terms of Kubernetes resources and controllers, extending that model to infrastructure provisioning has a certain elegance.
Bicep is Microsoft’s answer for Azure infrastructure, offering a much more pleasant authoring experience than raw ARM templates.
The trend I see across all of these is convergence toward better developer experience. The early IaC tools required you to think like an infrastructure engineer. The current generation meets developers where they are — whether that’s their preferred programming language, their existing Kubernetes workflows, or their cloud provider’s native tooling.
State Management Remains the Hard Problem#
Despite all the progress in IaC tooling, state management remains the fundamental challenge. Terraform’s state file is both its greatest strength (enabling plan/apply workflows and drift detection) and its biggest operational burden (requiring locking, backup, and careful access control).
Every team I’ve worked with that uses Terraform at scale eventually builds custom tooling around state management. Whether it’s Atlantis for PR-based workflows, custom CI pipelines with state locking, or wrapper scripts that enforce safety checks, the raw Terraform CLI is rarely enough for production use.
The moved block in 1.1 is a step toward making state operations safer, but the underlying model — a single serialized state file that represents the truth about your infrastructure — has inherent scaling limitations. I’m curious to see whether the next generation of IaC tools will find better approaches to this problem.
My Take#
Terraform 1.1 is a solid, mature release that addresses real operational pain points. It’s not exciting in the way that a new language or framework launch is exciting, but it’s the kind of improvement that makes daily life better for infrastructure engineers.
If you’re starting a new project today, Terraform remains the safe default choice for multi-cloud infrastructure management. Its provider ecosystem is unmatched, the community knowledge base is deep, and the 1.x stability guarantee means you’re not going to hit breaking changes.
But I’d also encourage teams to evaluate Pulumi for greenfield projects, especially if your infrastructure team is more comfortable in TypeScript or Python than HCL. The IaC landscape is healthily competitive right now, and that competition is driving genuine innovation in developer experience.
This is part of my Infrastructure Notes series, exploring the tools and practices that keep modern systems running.