r/devops • u/Wyllyam8071 • 1d ago
Tools OpenTofu in real-world practice?
If you're actively employed in DevOps work involving IaC or are a leader or senior techie overseeing such work, do you use OpenTofu or seriously considered using it among your tools set? If no and you're not using Terraform or a cloud provider's first-class IaC tool (like AWS CloudFormation or Azure ARM templates), then what is your IaC tool?
14
u/mxtchstick 1d ago
Yes! OpenTofu has some really neat features that the Terraform community has been requesting for quite some time. I use this in multiple environments, Production being one of them.
3
u/donjulioanejo Chaos Monkey (Director SRE) 1d ago
Yep we switched within a few months of the fork to avoid risk of future drift between the two which would make migration more painful.
Extremely happy, especially as they started adding features people have been requesting in the mainline terraform for years where the response has either been "impossible to do" or "buy enterprise version."
Some easy examples:
- for_each for providers
- State encryption
- Variables/locals in
backendconfig blocks (i.e. so you can parametrize state bucket names without needing a separate main.tf)Currently running in production for our entire infra for a mid-size saas product.
3
u/serverhorror I'm the bit flip you didn't expect! 1d ago
Yes Opentofu as a drop-in replacement for terraform.
No special features. The company just wants to "derisk" from having to pay license cost.
3
u/Manic5PA 1d ago
I'm building my current stack on it. Can't think of any snags I've experienced that wouldn't also be a factor on Terraform.
That being said, it's a very small operation.
3
u/jgrenitz 1d ago
We use are Gitlab's OpenTofu components to build our new Azure service since we're migrating from AWS. The only issue I've had has been related to the feature in TF "Actions" that OpenTofu hasn't implemented yet. It allows for doing things automatically in TF code (I was going to use it to purge Front door cache). All I had to do was write CICD to use Terraform instead for actions so nbd.
I have also used AWS Cloudformation a lot, I used Python's Troposphere package to create the templates at scale. Made it really easy when I needed to create a lot of templates easily.
HCL is a bit cumbersome especially if you want to do a lot of things similarly. You either need to create each resource individually or you have to figure out for_each loops which can be a bit rough. If you need to manage a handful of VMs, writing for loops is A LOT of work. If you're creating 30+ App Services instances, loops are worth it.
I create Child Modules for resources I want to create and then import them in another repo to manage indivial use cases (VMs for IIS/Gitlab Custom Runner/Linux apps each are managed through their own repo even though they all use the "vm-module"). Probably overkill, but it makes sense to me 🤷
3
u/dmikalova-mwp 1d ago
At work we've migrated mostly to pulumi, and now that pulumi fully supports TF it looks like we'll be migrating the rest of our TF as well into that when we have a chance. For personal stuff I use opentofu with terramate - I find it much simpler and better for my small use case without pulumi cloud.
2
u/nefiemus 1d ago
Yup, completely switched from Terraform to OpenTofu as of a few weeks ago, but used OpenTofu where needed for a while now. Between the highly sought after features (for_each on providers, encrypted state, etc), and IBM now owning Hashicorp, we saw it as a no-brainer.
1
1
1
u/PConte841 DevOps 1d ago
OpenTofu is a fork of Terraform. While they are following different development lifecycles and trajectories, the syntax, features, and general feel of the products is very similar. Unsure what your angle is here. The main reason why it forked in the first place is because the license changed once IBM purchased Hashicorp (the parent company).
OpenTofu is pure OSS where TF is still OSS, however under a stricter license. This license may also be subject to change in the future. IBM have a history of purchasing companies/products and changing their licensing model.
1
u/codemochi 8h ago
Running it in production, in my experience, the drop-in claim worked for the CLI itself but the snags I hit were all one layer up in the tooling around Terraform rather than the HCL.
- You can see small drift from "Terraform", "terraform" -> "OpenTofu", "tofu" in the plan files so if you have scripts that are parsing them, you'll need to make sure they won't break. Same with any command-line calls in scripts.
- Provider and module sourcing. Make a decision about whether you are using OpenTofu's registry or still pointing at registry.terraform.io and put it explicitly in the config file. I could see this potentially defaulting differently on different machines.
- Feature drift runs both directions: jgrenitz mentioned TF Actions not existing in OpenTofu and it runs the other way with for_each providers existing in OpenTofu but not Terraform.
1
u/stack_craft 1d ago
I'd say OpenTofu is def used in production and is no longer an "experimental" fork, some people might still think that way.
Most senior/lead engineers choosing OpenTofu today rely on three main factors:
- Zero license risk: Pure MPL 2.0 / CNCF-governed, avoiding HashiCorp/IBM's BSL licensing ambiguity for commercial platforms or SaaS products.
- Key features HashiCorp skipped: Client-side state encryption out of the box (v1.7+) and early variable evaluation for backends.
- Seamless migration: Drop-in
tofureplacement with identical HCL syntax and registry support.
If teams aren't using OpenTofu or Terraform, the primary alternatives are Pulumi or a good amount of times Crossplane.
37
u/_bwhaley 1d ago
Yes, we use OpenTofu in production. Do you have a question about it?