Infrastructure as code was never one tool — it was always a practice, and Terraform became the default syntax for that practice across AWS, GCP, Azure, and Kubernetes simultaneously. That dominance now has a competitor from inside its own community. The Terraform latest trends in 2026 infrastructure as code teams are tracking include a genuine community fork, new language features, AI-assisted plan generation, and a workflow tooling ecosystem that has matured significantly.
This article covers where the Terraform ecosystem stands today: the OpenTofu split, what Terraform 1.9 and 1.10 shipped, how AI fits into the plan/apply workflow, which orchestration tools have pulled ahead, and how Clanker Cloud connects to all of it.
1. Why IaC Still Matters in 2026 — and Why Terraform Won
Most infrastructure decisions that happen once at a terminal get repeated hundreds of times across environments. IaC converts those decisions into version-controlled, reviewable, diffable files. That property did not become less valuable as infrastructure grew more complex — it became essential.
Terraform won the portability argument. A single HCL module that provisions an EKS cluster, a GKE cluster, and their supporting IAM roles with no change to core logic is genuinely useful. Competing tools either required provider-specific syntax or sacrificed the state management model that makes terraform plan output meaningful.
The plan/apply split — inspecting intended changes before executing them — is the deepest idea in Terraform. You do not run terraform apply without reading the plan. That discipline keeps IaC teams out of incidents that start with "I thought it was going to do something else."
That discipline is the foundation of Clanker Cloud's PLAN step: gather context, inspect resources, generate a reviewed plan, and only then execute. Both systems separate intent from execution with a human review point.
2. The OpenTofu Split — What Happened and Where the Ecosystem Is Now
In August 2023, HashiCorp changed Terraform's license from MPL 2.0 to the Business Source License (BSL). BSL restricts use in competitive SaaS products — a move targeting Spacelift, env0, and similar platforms that had built businesses on the open-source binary.
OpenTofu forked from Terraform 1.6 under the Linux Foundation and shipped its first stable release within months. As of 2026, OpenTofu is at approximately version 1.9.x with active development, over 20,000 GitHub stars, and solid enterprise adoption.
The migration is deliberately frictionless:
# OpenTofu is a drop-in replacement
tofu init
tofu plan
tofu apply
Every Terraform provider works with OpenTofu. Every .tf file is valid. The state format is compatible. Teams switching from terraform to tofu typically do so in a single PR that updates CI pipeline commands.
Who moved: Spacelift and env0 announced first-class OpenTofu support and default to it for new workspaces. Gruntwork formally endorsed OpenTofu. The pattern is consistent: companies whose products competed with HashiCorp's commercial offerings moved quickly, both for compliance reasons and community alignment.
Who stayed: Organizations with existing HashiCorp Enterprise contracts, teams on HCP Terraform, and companies that evaluated the BSL and concluded it did not affect their use case. IBM's acquisition of HashiCorp in 2024 introduced some uncertainty but did not reverse the BSL.
Both tools are production-ready in 2026. The decision is mostly organizational: no HashiCorp contract means OpenTofu is the default for many new projects; existing HCP Terraform or Sentinel users are not migrating today.
3. Terraform 1.9 and 1.10 Features That Matter for Production Teams
HashiCorp has continued shipping meaningful features through the BSL era. Two releases are worth understanding before your next module refactor.
Ephemeral Values (1.10)
Ephemeral resources are used during a Terraform run but never written to state. The canonical example is a Vault-issued AWS credential that exists only for the duration of terraform apply:
ephemeral "vault_aws_access_credentials" "deploy" {
backend = "aws"
role = "deploy-role"
}
The credential never appears in terraform.tfstate. If your state file is compromised, temporary credentials from past runs are not exposed. This addresses a real attack surface with no clean prior solution.
Provider-Defined Functions
Providers can now ship custom functions callable in HCL — parsing ARNs, validating CIDR ranges, formatting resource tags — moving domain-specific logic out of regex-heavy locals {} blocks and into well-tested provider code.
The terraform test Framework
The .tftest.hcl format lets you write unit tests for modules:
run "creates_bucket_with_versioning" {
command = plan
assert {
condition = aws_s3_bucket_versioning.this.versioning_configuration[0].status == "Enabled"
error_message = "Versioning must be enabled"
}
}
terraform test runs assertions against plan output without applying. Teams maintaining shared module libraries now have a first-class regression-prevention workflow.
Stacks (Preview) and Import with Config Generation
Stacks orchestrate multiple deployments as a unit — useful for deploying one module across 12 environments in dependency order. As of early 2026, Stacks remain in preview via HCP Terraform.
The -generate-config-out flag writes HCL for existing resources during terraform plan:
terraform plan -generate-config-out=generated.tf
Generated configs need manual cleanup but significantly reduce the friction of bringing unmanaged resources into state.
4. AI + Terraform: The New IaC Workflow in 2026
The most significant shift in IaC practice over the past 18 months is not a Terraform feature — it is the arrival of LLMs that write correct, production-quality HCL on the first attempt for well-understood architectures.
A prompt like "write a Terraform module for an EKS cluster with three managed node groups, one per AZ, with separate IAM roles and IRSA enabled for the cluster autoscaler" now produces usable code from GPT-5.4 Thinking, Claude Opus 4.6, or Codex. The module still needs review — hardcoded values, missing tags, suboptimal lifecycle rules — but the structural work is complete.
The AI-assisted IaC workflow:
- Generate — LLM produces a Terraform module or configuration
- Plan —
terraform planor Clanker Cloud's PLAN step produces the diff - Review — a human or approval-gated agent reads the plan before apply
- Apply — changes execute only after explicit approval
The review step is not optional. AI-generated Terraform that skips terraform plan has caused real incidents: accidental resource replacements, security group deletions, IAM policy overwrites. The plan output is what catches these.
Clanker Cloud's Maker Mode formalizes this. Use BYOK with GPT-5.4 Thinking, Claude Code, Gemma 4 via Ollama (gemma4:31b), or Hermes (hermes3:70b) to generate a plan, inspect the diff in Clanker Cloud, and gate execution. Codex handles module generation cleanly; Claude Opus 4.6 is stronger on complex multi-provider configurations.
For drift detection, instead of parsing terraform plan output manually, query: "Show me all Terraform-managed resources with configuration drift." Clanker Cloud runs that analysis across AWS, GCP, Azure, and Kubernetes and returns a prioritized list of resources where live state diverges from what Terraform last recorded.
5. Workflow Tooling: Atlantis, Spacelift, and env0
Running terraform apply from a developer's laptop is an anti-pattern in production environments. The standard approach in 2026 uses PR-based workflows where plan output is reviewable before merge and apply happens in a controlled, auditable environment.
Atlantis
Atlantis is the open-source standard for PR-driven Terraform. It runs as a server receiving webhooks from GitHub or GitLab, executes terraform plan on every PR, and posts the plan output as a comment. Apply is gated on approval:
atlantis plan -d environments/prod
atlantis apply -d environments/prod
The plan diff appears in the PR alongside the HCL change — the same philosophy behind Clanker Cloud's PLAN step. Atlantis is self-hosted: you manage the server, credentials, and state backend.
Spacelift
Spacelift adds policy-as-code via Open Policy Agent (OPA). You write policies that block applies — for example, preventing any plan that deletes a production database or creates a public S3 bucket. It supports both Terraform and OpenTofu as a managed service, removing Atlantis's operational overhead.
env0 and Scalr
env0 differentiates on per-environment cost estimation: PR comments include estimated monthly cost change alongside the plan diff, catching "this change adds $4,000/month in NAT gateway costs" before apply.
Scalr targets enterprises with hierarchical workspace management — policies and variables cascade from organization to account to workspace, with OpenTofu support.
6. Terraform vs Kubernetes-Native: When to Use Each
The Terraform Kubernetes provider manages K8s resources as HCL:
resource "kubernetes_deployment" "api" {
metadata {
name = "api-deployment"
namespace = "production"
}
spec {
replicas = 3
# ...
}
}
The argument for this approach: consistency. If your team already manages all infrastructure in Terraform, adding K8s resources to the same state file and the same review workflow reduces cognitive overhead.
The argument against: Kubernetes already has a declarative reconciliation loop. Crossplane and the AWS Controllers for Kubernetes (ACK) provision cloud resources directly through K8s manifests using CRDs, keeping your infrastructure control plane inside the cluster. Drift detection is continuous rather than on-demand. Rollbacks use kubectl rather than terraform state.
The 2026 practical answer: use Terraform for the infrastructure that K8s runs on (VPCs, node groups, IAM roles, RDS instances, ElastiCache clusters) and use Kubernetes-native tools (Crossplane, ACK, or Helm) for resources that live within the cluster boundary. The Terraform Kubernetes provider works best for initial cluster bootstrapping, not for ongoing workload management.
For visibility into either pattern, see the Clanker Cloud use cases for deep research — querying "which K8s namespaces have resources not tracked in any Terraform state file" surfaces the shadow resources that the above decision boundary tends to create.
7. State Management in 2026
Terraform state is the source of truth for your infrastructure. Corrupted or out-of-sync state causes incorrect plans and dangerous applies. The standard backends in 2026:
S3 + DynamoDB locking remains the most common self-managed pattern for AWS teams. The DynamoDB lock table prevents concurrent applies from conflicting. This pattern is well-understood, has no additional cost beyond AWS usage, and is compatible with every CI/CD system.
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "environments/prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
State encryption (new in TF 1.9 / OpenTofu): Both tools now support encrypting state at rest using provider-managed keys or KMS. This is now a recommended default for any state file containing sensitive outputs — database connection strings, API keys written as resource attributes.
HCP Terraform (formerly Terraform Cloud) handles state storage, locking, and run history as a managed service. If your team already uses it, the upgrade path to new features (Stacks, ephemeral values) is straightforward.
Self-hosted Atlantis manages state through whatever backend you configure — typically S3 — while adding the PR workflow layer on top. The state backend is separate from the orchestration layer.
8. Clanker Cloud + Terraform: Plan Before You Apply, Every Time
The parallel between Terraform's plan/apply model and Clanker Cloud's four-step workflow (ASK, INSPECT, PLAN, APPLY) is structural, not cosmetic. Both are built around the same assumption: changes to infrastructure are irreversible enough that they require a review step between intent and execution.
In practice, Clanker Cloud extends the Terraform workflow into the live environment:
Drift query: "Show me all Terraform-managed resources with configuration drift" — Clanker Cloud compares live resource configuration across AWS, GCP, and Azure against last-known state. No local
terraform planrun required.Shadow IT audit: "Which resources in production are not tracked in any Terraform state file?" The Deep Research feature fans out across all connected providers and returns a severity-graded list of unmanaged resources — the shadow IT problem made visible.
Maker Mode with BYOK: Generate a complex Terraform module using GPT-5.4 Thinking or Claude Opus 4.6, inspect the plan in Clanker Cloud, and gate execution. Gemma 4 via Ollama (
gemma4:31b) keeps generation local when credentials must stay off the network. Hermes (hermes3:70b) handles iterative module refinement. Clanker Cloud is a desktop-first application — credentials never leave your machine per the AI DevOps for teams architecture.
The Clanker Cloud documentation covers provider setup for AWS, GCP, Azure, and Kubernetes. The demo shows the query interface against a live environment. For agents running Terraform workflows autonomously, the for-agents page covers the MCP integration.
Create an account — the Beta tier is free.
FAQ
What is the difference between OpenTofu and Terraform in 2026?
OpenTofu is a fork of Terraform created in response to HashiCorp's 2023 BSL license change, governed by the Linux Foundation. It is drop-in compatible — same HCL syntax, same provider ecosystem, same state format, with CLI commands differing only in name (tofu vs terraform). Terraform is now governed by HashiCorp (IBM). Both are production-ready. The choice is organizational: teams with HashiCorp enterprise contracts stay on Terraform; teams that want a fully open-source license use OpenTofu.
What are the most important Terraform 1.10 features for production teams?
Ephemeral values are the most impactful: resources used during a run but never written to state, eliminating sensitive credentials persisting in state files. Provider-defined functions reduce boilerplate in complex modules. The terraform test framework enables unit testing for module libraries without provisioning real infrastructure. State encryption, added in 1.9, is now a recommended default for any state containing sensitive outputs.
How does Atlantis work for Terraform GitOps workflows?
Atlantis is a self-hosted server that receives GitHub or GitLab webhooks. When a PR modifies .tf files, Atlantis runs terraform plan and posts the diff as a comment. Apply is blocked until reviewed and approved. The typical flow: atlantis plan -d environments/prod to trigger planning, atlantis apply -d environments/prod to execute after approval. This keeps apply off developer workstations and creates an audit trail in the PR history.
When should you use Crossplane instead of the Terraform Kubernetes provider?
Use Crossplane (or ACK) when you want continuous reconciliation of cloud resources through the Kubernetes control plane. Use the Terraform Kubernetes provider when you want all infrastructure in a single state file and review workflow. The practical 2026 boundary: Terraform for infrastructure Kubernetes runs on (VPCs, node groups, IAM, managed databases), Kubernetes-native tools for resources inside the cluster boundary. Mixing both for the same resource type creates drift problems.
Start with a Plan
The most expensive IaC incidents share a common pattern: someone applied without reading the plan. The tooling in 2026 — Atlantis, Spacelift, ephemeral values, AI-generated modules — does not change that constraint. It makes the plan easier to generate and harder to skip.
See the demo to watch Clanker Cloud run drift detection and resource queries against live infrastructure. Check the FAQ for common questions about provider setup and BYOK configuration. When you are ready, create an account and run your first infrastructure query.
Plan before you apply. Every time.
Ask Clanker Cloud what your cluster is doing
Install the local app, connect your kubeconfig, and turn cluster state, workload health, cost context, and safe next steps into one readable answer.