So what is Terraform? In plain terms, it is a tool that lets you write down the cloud infrastructure you want — servers, load balancers, databases, DNS records — in text files, then creates and updates that infrastructure for you. Instead of clicking through the AWS console for an hour, you write a config, run one command, and get a repeatable result. That idea is called infrastructure as code (IaC), and Terraform is still its most widely used implementation in 2026.
What changed in 2026
The biggest shifts are about ownership and licensing, not syntax.
- HashiCorp is now part of IBM. The acquisition that was announced in 2024 has closed, so Terraform sits inside IBM's software portfolio. Day to day this changes little for users, but it is worth knowing who steers the roadmap.
- The license is still the BSL, not open source. In 2023 HashiCorp moved Terraform from the open MPL license to the Business Source License (BSL 1.1). It stays free for the vast majority of users; the restriction targets companies building competing hosted products.
- OpenTofu is a real, maintained fork. The community response to the license change was OpenTofu, a Linux Foundation project that is a near drop-in replacement. By 2026 it has shipped features of its own, including client-side state encryption.
- Testing and multi-environment tooling matured. The built-in
terraform test framework and Stacks-style features for managing many environments are more usable than they were a couple of years ago.
Verify current license terms and versions yourself before standardising — this space still moves.
How Terraform actually works
Terraform is declarative. You do not write step-by-step instructions; you describe the end state and let the tool reconcile the difference. A tiny example in HCL, Terraform's config language:
resource "aws_s3_bucket" "logs" {
bucket = "byteledger-logs-2026"
}
The core pieces:
- Providers are plugins that talk to a platform's API — AWS, Azure, Google Cloud, Kubernetes, Cloudflare, and hundreds more. You are not limited to one cloud.
- Resources are the things you create: a bucket, a VM, a DNS record.
- Plan and apply is the workflow.
terraform plan shows you what will change; terraform apply makes it happen. The plan step is the safety net — always read it.
- Modules are reusable bundles of config so you are not copying the same VPC setup into ten projects.
The state file is the thing that bites you
Terraform keeps a state file that maps your code to the real resources it created. This is powerful and also the number one source of pain.
If you edit a Terraform-managed resource by hand in the console, the state drifts from reality and the next apply may try to "correct" your change. If two people run apply at once without locking, you can corrupt state. If you commit the state file to a public Git repo, you may leak secrets, because state can contain sensitive values in plain text.
The fix is a remote backend with locking — an S3 bucket plus DynamoDB, Terraform Cloud, an Azure storage account, or Google Cloud Storage. Set this up on day one, not after your first incident.
Terraform vs the alternatives
Terraform is not the only IaC option. A quick, honest comparison:
| Tool |
Language |
Scope |
Best when |
| Terraform |
HCL |
Multi-cloud |
You want the biggest ecosystem and provider list |
| OpenTofu |
HCL |
Multi-cloud |
You want an open-source license and Terraform compatibility |
| Pulumi |
TypeScript, Python, Go |
Multi-cloud |
Your team prefers real programming languages over HCL |
| CloudFormation |
YAML/JSON |
AWS only |
You are all-in on AWS and want native integration |
| Ansible |
YAML |
Config + some provisioning |
You lean toward configuration management over provisioning |
For most teams building across clouds, Terraform or OpenTofu is the default. Pulumi wins if HCL feels limiting; CloudFormation makes sense only in single-cloud AWS shops.
What to skip
- Skip hand-editing resources that Terraform manages. Change the code, not the console.
- Skip local-only state for anything shared. Use a remote backend with locking from the start.
- Skip giant single configurations. One monster file for your whole company makes every plan slow and every apply scary. Split by environment and domain.
- Skip pinning nothing. Always pin provider and module versions so an upgrade does not silently reshape production.
- Skip Terraform entirely if you have three resources and no team. A short script or the console is fine until repeatability actually hurts.
FAQ
Is Terraform free in 2026?
Yes for the vast majority of users. The BSL license only restricts building a competing hosted Terraform product. If that worries you, OpenTofu is licensed under the open MPL.
Do I need to know a programming language?
Not really. HCL is a configuration language, closer to structured settings than code. If you would rather use Python or TypeScript, look at Pulumi instead.
Terraform or OpenTofu — which should I pick?
For new projects, either works and the syntax is nearly identical. Choose OpenTofu if an open-source license matters to your org; choose Terraform for the largest provider ecosystem and vendor support.
What is the hardest part for beginners?
State management. Understand the state file, use a remote backend with locking, and never edit managed resources by hand.
Where to go next
If you are still building foundations, our guide on how to learn Python fast in 2026 pairs well with automating infrastructure. To decide where your Terraform code will actually deploy, read AWS vs Azure in 2026. And once your services are live, lock them down with API authentication explained for 2026.