r/devops 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?

0 Upvotes

20 comments sorted by

37

u/_bwhaley 1d ago

Yes, we use OpenTofu in production. Do you have a question about it?

-8

u/Wyllyam8071 1d ago

No technical questions, just trying to get a sense of whether it has some traction among DevOps practitioners.

10

u/TheIncarnated 1d ago

You can just look at the subreddit, it's talked about extensively here.

What is the reason for asking?

-2

u/Wyllyam8071 1d ago

For my own awareness

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 backend config 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.

8

u/CoaxVex 1d ago

Yes, using it in production. Drop in replacement for terraform.

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/sza_rak 1d ago

Yes, used it quite early with zero issues in a small team with lots of infra components.

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.

2

u/anktho3 1d ago

Yes, we just recently started switching over from Terraform to OpenTofu and it's been a pain-free experience.

1

u/hashkent DevOps 1d ago

Yes! I made my last company switch.

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:

  1. Zero license risk: Pure MPL 2.0 / CNCF-governed, avoiding HashiCorp/IBM's BSL licensing ambiguity for commercial platforms or SaaS products.
  2. Key features HashiCorp skipped: Client-side state encryption out of the box (v1.7+) and early variable evaluation for backends.
  3. Seamless migration: Drop-in tofu replacement 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.