Why did a licence change reshape this entire category?
Because infrastructure code is the most expensive code an organisation owns to rewrite. A Terraform estate describes every network, database, cluster and permission in production, accumulated over years, and there is no incremental path off it — which is precisely the position that makes a licence change consequential rather than annoying.
HashiCorp moved Terraform to the Business Source Licence, and OpenTofu was forked in response, now governed by the Linux Foundation under MPL 2.0. The distinction that matters is governance rather than licence text: MPL 2.0 under a foundation with many participating companies cannot be relicensed by any one of them, because no one of them owns it.
OpenTofu is a drop-in replacement for Terraform 1.5+, so migration is changing the binary rather than rewriting the code. It has also shipped features HashiCorp has not, including state encryption and for_each on providers.
The lesson generalises past Terraform. When evaluating any tool that will hold your infrastructure definitions, the question is not what the licence says today but who is able to change it — and a foundation with distributed governance answers that differently from a company with an owner.
Who holds your cloud credentials, and does it have to be a vendor?
An infrastructure-as-code platform needs credentials that can create and destroy anything in your cloud account. That is the most powerful access in the organisation, and handing it to a SaaS vendor is a decision most teams make without noticing they made it.
Digger is built on refusing that trade. It runs Terraform and OpenTofu plans inside your own GitHub Actions or GitLab CI, so the credentials never leave infrastructure you already secure, audit and control — and you get the pull-request plan-and-apply workflow, OPA policies, drift detection and state locking that Terraform Cloud offers. Apache 2.0, with no per-run platform pricing.
Terramate takes the same approach from the orchestration side: the CLI is open source and runs in your existing CI, so there are no new credentials to issue and Terramate Cloud is optional rather than required.
Spacelift compromises deliberately with self-hosted worker pools: the control plane is SaaS but the workers run in your VPC, so credentials stay local while you still get the policy engine and dependency management. For a team that wants the platform without the exposure, that is the middle ground.
When does an orchestration layer become necessary?
Around the point where a single Terraform state becomes several dozen, and applying a change means knowing which stacks depend on which others.
Below that, plain OpenTofu in CI is correct and anything more is overhead. Terramate is explicit that it is unnecessary for small estates.
Above it, the problems are real. Terramate solves boilerplate with code generation — hundreds of stacks stop being copy-paste, and the generated output is plain reviewable Terraform rather than an abstraction — plus change detection so CI only runs what actually changed, which is the difference between a five-minute pipeline and a fifty-minute one.
Spacelift solves governance: OPA policies that actually block a non-compliant plan, approval flows, drift detection and stack dependencies, across OpenTofu, Terraform, Pulumi, CloudFormation and Ansible. That breadth matters in an organisation that did not standardise, which is most of them.
The honest cost is that both add a concept the team must learn, and Spacelift starts around $400 a month, which is real money for a small team.
What does declarative actually buy you at the operating-system level?
A rollback that works. Most configuration management converges a system towards a desired state by mutating it, so reverting means running the old configuration and hoping it undoes what the new one did. NixOS does not mutate: a new configuration builds a new system generation alongside the old, and switching between them is atomic.
The practical consequence is that a bad upgrade is a reboot away from being undone, with certainty rather than optimism. For anyone who has watched a failed Ansible run leave a machine in a state described by neither the old nor the new configuration, that is the whole argument.
The second property is reproducibility. A Nix development shell gives every machine byte-identical dependencies, which eliminates the "works on my machine" class of problem at the root rather than papering over it with containers.
The costs are genuine and NixOS does not hide them: the learning curve is steep, the language is unusual, documentation is uneven, and the non-standard filesystem layout breaks software that assumes ordinary paths. NixOS is a considerable investment that pays back at scale and rarely below it.
Where does infrastructure code stop and application operations begin?
At the point where deploying is easy and running is not. Terraform and OpenTofu are excellent at provisioning — creating the cluster, the database, the network — and say nothing about what happens on day two when the database needs a backup verified, a version upgraded or a replica promoted.
Canonical Juju exists for that gap. Charmed operators encode operational knowledge rather than installation steps, so an operator knows how to upgrade, back up and scale the thing it manages. Relations wire applications together automatically: relate an application to a database and the credentials, connection strings and configuration are exchanged without anyone writing glue.
The same model runs across public cloud, Kubernetes and bare metal, which is unusual and useful for organisations with mixed infrastructure. It is AGPLv3 with commercial support through Ubuntu Pro.
The trade is ecosystem size and familiarity: the concepts are unfamiliar, the learning curve is real, the charm ecosystem is far smaller than Helm or Terraform, and it is strongly tied to the Canonical stack. Juju is the right answer for complex multi-component applications and the wrong one for provisioning a VPC.
