October 7, 2022
Terraform for DevOps in 2026: Why Teams Choose It, and What Has Changed
Enjoying this article?
Share it with the world!
Terraform vs OpenTofu for DevOps: What Changed in 2026
|
⚡ Quick Answer Teams choose Terraform for DevOps because it turns infrastructure into version-controlled code, shows a plan of every change before it runs, and uses one workflow across AWS, Azure, Google Cloud and hundreds of other providers. Three things have changed since 2022. HashiCorp moved Terraform to the Business Source License in August 2023, so it is no longer open source. The community forked the last open-source release as OpenTofu, now a Linux Foundation project. And IBM completed its acquisition of HashiCorp in February 2025. For most teams using Terraform to manage their own infrastructure, day-to-day use is unchanged — but licensing, vendor strategy and OpenTofu are now legitimate parts of the choice. |
Terraform has been the default answer to “how should we manage our cloud infrastructure as code?” for most of the last decade. When this article was first published in 2022, the question was mainly technical: why pick Terraform over the other infrastructure-as-code tools on the market?
That question still matters, and most of the answers still hold. But the decision now has a second layer. Terraform’s licence changed in 2023, an open-source fork called OpenTofu has matured into a credible alternative, and Terraform now sits inside IBM’s automation portfolio. None of that changes what Terraform does. It does change what a team should check before committing to it.
This is a full rewrite of the original piece, covering both layers: why DevOps teams choose Terraform, and what to weigh in 2026.
What Is Terraform in DevOps?
Terraform is an infrastructure-as-code (IaC) tool created by HashiCorp and first released as open-source software in 2014. It is written in Go. Instead of clicking through cloud consoles or writing one-off scripts, you describe the infrastructure you want in configuration files, and Terraform works out how to create, change or remove resources so that reality matches the description.
Those files are written in HCL, HashiCorp Configuration Language, which is declarative: you state the end result rather than the sequence of steps. A few core ideas make the model work:
|
▪ Providers — plugins that let Terraform talk to a platform’s API: AWS, Azure, Google Cloud, Kubernetes, and many SaaS tools such as DNS, monitoring and identity services ▪ Resources — the individual things you manage: virtual machines, storage volumes, networks, IP addresses, databases, load balancers ▪ State — a record of what Terraform has created, used to calculate the difference between the current and desired infrastructure ▪ Modules — reusable packages of configuration, so a standard network or cluster can be defined once and used many times |
In a DevOps context, that combination matters because it lets infrastructure move through the same workflow as application code: written, reviewed, tested, versioned and deployed through a pipeline.
Where Terraform Fits in a DevOps Workflow
The core Terraform loop is short, and each step maps onto a familiar DevOps practice.
|
The Terraform Workflow
terraform plan shows exactly what will change — before anything changes |
A change starts as an edit to a configuration file on a branch. terraform plan produces a preview of what will be created, modified or destroyed, and that preview can be posted to the pull request for review. Once approved, terraform apply makes the change, typically from a CI/CD pipeline rather than an engineer’s laptop, and Terraform updates its state.
|
Provisioning vs configuration Terraform is built for provisioning — creating and changing the infrastructure itself. Tools such as Ansible, Chef and Puppet are built for configuration management — installing and configuring software on machines that already exist. They are complementary rather than competing, which is why IBM now positions Terraform and Ansible together as one automation story. |
Six Reasons DevOps Teams Choose Terraform
The original version of this article listed the reasons below. They have held up well; here they are restated with current context.
|
Infrastructure becomes reviewable code Because infrastructure lives in files, it gets everything code gets: version history, pull-request review, automated checks and a clear record of who changed what and why. That is the foundation for applying policy and compliance checks automatically rather than through manual sign-off. |
|
You see the change before you make it The plan step is one of Terraform’s most valued features. Reviewers approve a concrete list of changes rather than a description of intent, which catches accidental deletions and unexpected replacements before they reach production. |
|
One workflow across many platforms Terraform’s provider model means the same language and workflow can manage AWS, Azure, Google Cloud, on-premises platforms and SaaS services. It is not the only multi-cloud IaC tool — OpenTofu, Pulumi and Crossplane are too — but its provider ecosystem is among the broadest, which matters for teams with a multi-cloud strategy. |
|
A declarative model built for provisioning Terraform was designed around describing infrastructure end states, which fits provisioning better than stretching a configuration-management tool to create cloud resources. You describe the target; Terraform calculates the steps and the dependency order. |
|
Reuse through modules Modules let a platform team publish approved building blocks — a standard VPC, a hardened cluster, a tagged storage bucket — that product teams consume without reinventing them. This is a common foundation for platform engineering and self-service infrastructure. |
|
A large ecosystem and talent pool Terraform has a very large community, a public registry of providers and modules, extensive documentation and a broad pool of engineers who already know it. For hiring and onboarding, that familiarity is often as important as any technical feature. |
|
Is your Terraform setup ready to scale? Most Terraform pain shows up later — in state management, module sprawl and pipelines that were never designed for multiple teams. Impressico can review your current setup and show where it will strain. |
What Has Changed Since 2022
|
Terraform Timeline
|
Figure 1 — The three changes since this article was first published: licence, fork and ownership.
1. Terraform is no longer open source
In August 2023, HashiCorp moved new Terraform releases from the Mozilla Public License to the Business Source License 1.1. The source code is still publicly available, but the BSL is not recognised as an open-source licence by the Open Source Initiative, and it restricts using Terraform in products that compete with HashiCorp’s own. Terraform 1.5.7 was the last release under the MPL.
|
Does the licence affect you? For most organisations using Terraform to manage their own infrastructure, the licence change does not restrict day-to-day use. The restrictions matter mainly to companies building commercial products or hosted services on top of Terraform. If there is any doubt about your use case, it is worth a check with your legal team rather than an assumption. |
2. OpenTofu is now a credible alternative
When HashiCorp did not reverse the change, a coalition of vendors and community members forked the last open-source version and placed it under the Linux Foundation as OpenTofu. It remains under the MPL, is governed by a multi-company technical steering committee, and keeps command-line and configuration compatibility with Terraform, so most existing code runs without changes. It has also begun adding its own features, such as built-in state file encryption introduced in version 1.7.
3. Terraform now belongs to IBM
IBM completed its acquisition of HashiCorp on 27 February 2025. IBM’s stated plan is to integrate Terraform with Red Hat Ansible for end-to-end infrastructure automation, and with its wider hybrid cloud portfolio. Since then, HashiCorp products have moved under IBM branding and the commercial packaging of HCP Terraform, the managed service, has been adjusted. Anyone on a paid Terraform plan should review current terms at renewal rather than assume earlier ones still apply.
Terraform vs OpenTofu: How They Compare
For most teams the practical question in 2026 is not whether to use infrastructure as code, but which of the two compatible tools to standardise on.
Figure 2 — Terraform and OpenTofu side by side.
Because the two share a common origin, the switching cost between them is currently low for most configurations. That cost is likely to rise over time as each project adds features the other does not have, which is a reason to make the choice deliberately rather than by default.
Other Infrastructure-as-Code Options Worth Knowing
Terraform and OpenTofu are not the only choices. Depending on your team and platform, one of these may fit better:
|
Pulumi Defines infrastructure in general-purpose languages such as TypeScript, Python, Go and C# instead of a configuration language. Popular with teams that want to use existing programming skills, tests and abstractions. |
|
Crossplane Manages cloud infrastructure through the Kubernetes control plane, treating infrastructure as Kubernetes resources. A natural fit for organisations already standardised on Kubernetes. |
|
Cloud-native tools AWS CloudFormation, Azure Bicep and Google Cloud Infrastructure Manager are tied to a single cloud but integrate tightly with it. Reasonable choices for teams committed to one provider, such as those modernising on AWS. |
How to Decide What Fits Your Team
Five questions usually settle it:
|
▪ Are you building a product or service on top of the tool? If so, review the BSL terms carefully; OpenTofu avoids the question. ▪ Do you need a vendor-managed platform and support? HCP Terraform is the most direct option; OpenTofu relies on third-party platforms. ▪ Is open-source licensing a policy requirement? Some organisations require OSI-approved licences for core tooling. ▪ How many clouds and SaaS services do you manage? The broader the estate, the more provider coverage matters. ▪ What does your team already know? Existing skills and code are a real switching cost, whichever way you go. |
For many teams the honest answer is that either Terraform or OpenTofu will work well technically, and the decision comes down to licensing policy, support preferences and appetite for vendor dependency.
Common Terraform Mistakes to Avoid
Whichever tool you choose, the same problems tend to surface as usage grows — several of them are among the DevOps automation mistakes that prove most expensive later.
|
Local or unlocked state State kept on a laptop, or shared without locking, leads to conflicting changes and lost history. Use remote state with locking from the start. |
|
Secrets in state and code State files can contain sensitive values. Restrict access to state, keep secrets in a dedicated secrets manager, and scan configuration as part of shift-left security checks. |
|
Unpinned provider and module versions Without version constraints, an upstream release can change behaviour between two runs of the same code. Pin versions and upgrade deliberately. |
|
One giant configuration A single root configuration for everything makes plans slow and every change risky. Split by environment and component, with shared modules. |
|
Changes made outside Terraform Console edits create drift between code and reality. Run regular plans to detect drift, and route changes through the pipeline so deployments stay predictable. |
|
Licensing · Support · Roadmap Weighing Terraform against OpenTofu? The technical difference is small today; the licensing, support and roadmap differences are not. We can assess your estate, your policies and your pipelines, and recommend which to standardise on — with a migration path if you need one. |
Frequently Asked Questions
|
Is Terraform still open source? No. Since August 2023, new Terraform releases use the Business Source License 1.1, which is source-available but not recognised as open source by the Open Source Initiative. Terraform 1.5.7 was the last release under the open-source Mozilla Public License. OpenTofu, a Linux Foundation fork of that code, remains open source. |
|
What is the difference between Terraform and OpenTofu? OpenTofu is a fork of Terraform created after the 2023 licence change. It is open source under the MPL and governed by the Linux Foundation, while Terraform is source-available and owned by HashiCorp, an IBM company. Both use the same configuration language and most code works in either, though the two are adding different features over time. |
|
Should I use Terraform or Ansible? Usually both, for different jobs. Terraform provisions infrastructure — networks, virtual machines, databases, managed services. Ansible configures software on machines that already exist. Many teams use Terraform to build the environment and Ansible to configure what runs on it, and IBM now positions the two as a combined automation toolset. |
|
Is Terraform multi-cloud? Yes. Through its provider model, Terraform can manage AWS, Azure, Google Cloud, on-premises platforms and many SaaS services from one workflow. It is one of several multi-cloud IaC tools, alongside OpenTofu, Pulumi and Crossplane, and its provider ecosystem is among the broadest available. |
|
Does the IBM acquisition change anything for Terraform users? The core tool works as before. What has changed is branding and commercial packaging: HashiCorp products now sit within IBM’s automation portfolio, and plans and terms for the managed HCP Terraform service have been adjusted since the deal closed in February 2025. Teams on paid plans should review current terms at renewal. |
Conclusion
The reasons DevOps teams choose Terraform are the same ones this article described in 2022: infrastructure as reviewable code, a plan before every change, one workflow across many platforms, reusable modules, and a large ecosystem of people who already know it.
What has changed is the context around the tool. Terraform is now source-available rather than open source, OpenTofu offers a compatible open-source path, and IBM owns the roadmap. None of that makes Terraform a worse choice. It means the decision deserves a deliberate look at licensing, support and vendor strategy — not just features.
|
Key Takeaways
|
|
Impressico · DevOps & Cloud Infrastructure as code that scales with your teams. Impressico designs Terraform and OpenTofu foundations — remote state, reusable modules, policy checks and pipeline-driven delivery — so infrastructure changes stay reviewable, repeatable and safe as your organisation grows. |
IBS
Similar articles
Shift-Left Security in CI/CD Pipelines: A Practical Playbook
September 4, 2026
DevSecOps: Shifting Security Left Without Slowing Delivery
September 2, 2026
Is Your Engineering Team Ready for Platform Engineering? A Readiness Checklist
August 12, 2026
Measuring Platform Engineering ROI: DORA and SPACE Explained
July 31, 2026
Internal Developer Platforms: Building a Golden Path for Engineering Teams
July 22, 2026
AIOps in Practice: Using AI to Cut Incidents and MTTR
July 6, 2026
