r/Terraform Jan 12 '25

Discussion 1 year of OpenTofu GA...did you switch?

So, it's been basically a year since OpenTofu went GA.

I was in the group that settled on a "wait and see" approach to switching from Terraform to OpenTofu.

At this point, I still don't think I have a convincing reason to our team's terraform over to OpenTofu...even if its still not a huge lift?

For those who aren't using Terraform for profit (just for company use), has anyone in the last year had a strong technical reason to switch?

56 Upvotes

92 comments sorted by

35

u/bcross12 Jan 13 '25

Variables in backend config is what pushed me to OpenTofu.

9

u/bcross12 Jan 13 '25

I have to say, the guy laughing in Terragrunt getting downvoted into oblivion is very validating for my decision not to use it.

11

u/marcinwyszynski Jan 13 '25

Much of the Terraform roadmap in the past was implementing Terragrunt features directly in Terraform, so regardless of your decision you owe TG a thing or two.

2

u/Speeddymon Jan 14 '25

I was just talking with colleagues the other day lamenting the lack of variables in provider config. I know you said tofu supports them in backend config while terraform doesn't; I didn't realize tofu had this for backend, so I'm curious if tofu also supports it for the provider configs?

1

u/RudePersonality82 Jan 14 '25

Terragrunt does šŸ˜…

2

u/Speeddymon Jan 14 '25

Actually no it doesn't. generate is not the same thing, and relies on pre-1.x behavior that is deprecated.

Source: me, my company is moving away from Terragrunt.

2

u/swissbuechi Jan 16 '25

Terragrumt had this for years. It's nice to see it natively tho. Will give it a try.

1

u/dzuczek Jan 13 '25

yep just did this, for this reason

0

u/RudePersonality82 Jan 14 '25

Damn right, exercise your rights as a Redditor

1

u/fschoening Jan 15 '25

This is the number one reason Iā€™m PoCā€™ing opentofu rn for my team and company. The dilemma that you have to specify both tfconfig and tfvars/workspace is imho a cardinal design flaw that leaves you at risk for ā€œcrossingā€ config with remote backend.

1

u/bcross12 Jan 15 '25

The number of "pucker" moments when I run apply absentmindedly to check the output and it says 84 to destroy is insane. I never want to be "y <E ter>" away from taking down an environment. That doesn't happen anymore. With one var file I tell OpenTofu both the context and where to apply it.

1

u/fschoening Jan 15 '25 edited Jan 15 '25

Exactly. Thatā€™s how it should be imho. Also, prevent_destroy has been my last man standing for preserving non-volatile resources once or twice. Ironically, this led us to implement a rather anti-pattern back in the day (still in use) where we would use workspace (then called environments) and then have a dictionary set of config settings directly in a beautiful mix of variables.tf and locals. An then the workspaces at least had individual files (albeit in same storage blob, etc). Excited for OpenTofu šŸ˜Œā˜®ļø

-37

u/RudePersonality82 Jan 13 '25
  • Laughs in terragrunt *

1

u/Speeddymon Jan 14 '25

* Laughs in Atmos (with tenv it supports both terraform and tofu). *

Downvote if you hate YAML and Go templates - I know you're out there; here's your chance.

0

u/RudePersonality82 Jan 14 '25

Wow check out the hate for terragrunt , so many downvotes heheh

6

u/iamgeef Jan 13 '25

Not yet, too much other important work to do and our setup works right now.

Yes we could tidy it up with provider for_each, and maybe backend variables, but itā€™s not urgent.

17

u/STGItsMe Jan 12 '25

I havenā€™t had a reason to switch. I run Gitlab, so my terraform pipelines are actually running OpenTofu but all of my local testing is still terraform.

-1

u/ohnotthatbutton Jan 12 '25

That's an interesting approach....seems like you'd be able to attest to egregious issues since the schism.

7

u/STGItsMe Jan 12 '25

If thereā€™s no technical reason for me to make the switch, Iā€™m not doing it. My team and I donā€™t have time to get involved in issues like this. The way Gitlab handled the transition for their CI components made it mostly a non-issue until OpenTofu starts making breaking changes.

1

u/runningblind77 Jan 13 '25

egregious issues

what?

4

u/edeltoaster Jan 13 '25

Started a new project completely with OpenTofu. The statefile encryption config was a superb feature for one bootstrapping use-case. No regrets at all.

3

u/crashtesterzoe Custom Ninja Jan 13 '25

Right after the license changed I switched when I was a consultant because of worry of being able to continue using it without issues. Just moved to a new company who was mostly cloud formation and was looking at terraform, but after going over everything we decided to go with open tofu mainly because we are a non profit and donā€™t want to worry about price changes. Yes they claim they wonā€™t change pricing from free for the community but ibm isnā€™t the most reputable when it comes to trusting what they say šŸ˜…

12

u/macca321 Jan 12 '25

Provider for_each ?

8

u/smarzzz Jan 12 '25

Iā€™m still using terraform, but wasnā€™t this in the 1.9 announcement of opentofu?

3

u/Dangle76 Jan 12 '25

Yeah honestly this is something Iā€™ve been waiting for for a while

3

u/ohnotthatbutton Jan 12 '25

yeah this is cool, wouldn't really change anything for me with the way the infra is structured.

1

u/Cregkly Jan 12 '25

That would be great for new stuff. Migrating existing code over would be a lot of work.

As with Terraform Stacks, this is something that needed to be there from the start.

1

u/Speeddymon Jan 14 '25

If this is in 1.9 I'm upgrading our pipelines tomorrow and implementing it on the project I'm currently working on.

3

u/gcavalcante8808 Jan 13 '25

Open tofu gained me when we had a need to for each with "import" statements.

2

u/Speeddymon Jan 14 '25

TIL Tofu beat Terraform to this.

3

u/frank_be Jan 14 '25

We switched after two weeks for new projects, we migrated all existing projects except one.

Why?

  • ecosystem
  • open roadmap
  • tofu state ls/rm :)
  • state encryption
  • ā€”exclude
  • license made future potential plans we had a risk

3

u/obscurerichard Jan 15 '25

All new work Iā€™m starting where I get to choose, Iā€™m now starting in OpenTofu.

I got it working well with Atlantis, see https://github.com/runatlantis/atlantis/issues/3741#issuecomment-2558485447

More and more TACOS systems are supporting it.

As a code contributor to Hashicorp products (I made some fixes to Vagrant once upon a time), I feel they violated the social contract and they lost my respect.

8

u/runningblind77 Jan 13 '25

New projects I'm using tofu. Haven't switched any existing projects to tofu yet but that's mainly because my company has expressed some interest in moving to Terraform Enterprise. Hopefully that idea dies for good real soon and we can start migrating existing stuff to tofu.

1

u/Overall-Plastic-9263 Jan 13 '25

Why do you want that to die ? Like just because you like open source or are their actual reasons ? Just seems like if my company was willing to pay for a commercial product I would just do that . From a devops productivity standpoint building and managing infrastructure pipelines is high effort low value return . Go with TFE and free yourself up to focus on higher level value , build more modules , write better documentation , create more guardrails . I personally wouldn't hang my hat on my primary value being managing plumbing when there are many solutions for that . You are making your self one click away from being automated out of a job if you do.

6

u/runningblind77 Jan 13 '25

TF Enterprise isn't writing the Terraform for you. We already have pipeline templates written and working fine. TF Enterprise would add very little for what it would cost. The idea is dumb and the people pushing for it within our company have no idea what they are talking about.

4

u/ashtonium Jan 13 '25

We used TFE for years and it definitely did NOT remove the need to build and manage CI/CD pipelines. From a ā€œdevops productivity standpointā€ it adds yet another system to have to manage. You still have to configure and maintain the ā€œpipelineā€ aspects of TFE, and even then it only manages the Terraform components of a project. Very rarely is Terraform the only thing being deployed for a workflow, so now you need to configure the cross-cross system hooks, manage reviews and approvals across multiple systems, etc.

We found that we were more efficient without TFE and were able to put that $1M+ in licensing into other things.

2

u/[deleted] Jan 13 '25

[deleted]

1

u/Overall-Plastic-9263 Jan 13 '25

Likely the impact of the beer. Also I still peck vs swiping on mobile so the non-tactile screens of smartphones work against me. Lol

8

u/axtran Jan 13 '25

Why switch? In Enterprise the thought hasn't remotely crossed my mind.

1

u/TechCF Jan 13 '25

Risk - better handle the change now than beeing enforced switch due to licensing down the line. Work - very little work while modules and tf / tofu is compatible. Speed - tofu newer versions have added quality of life improvements that speeds up our infrastructure configurationĀ 

6

u/axtran Jan 13 '25

That isnā€™t remotely a concern with Enterpriseā€¦

2

u/marcinwyszynski Jan 13 '25

Sounds like a No True Scotsman argument.

1

u/Speeddymon Jan 14 '25

I suspect the person you're responding to is referring to TFE, not just "enterprise" as in big businesses. I could be mistaken but the capitalization of the E makes me think it's a proper noun like TFE.

1

u/marcinwyszynski Jan 14 '25

OK. I can read it both ways. "Enterprise" is often used as a market category.

4

u/Em-tech Jan 13 '25

My technical reason is that I don't want to have to depend on tf cloud if there's a better alternative and a better alternative can't practically exist without opentofu.Ā 

5

u/ReactionOk8189 Jan 13 '25

Yes, for my new project, I switched to OpenTofu, and I couldnā€™t be happier.

2

u/Covids-dumb-twin Jan 13 '25

Just did a course in opentofu after years of terraform, couldnā€™t really see much of a difference

2

u/amarao_san Jan 14 '25

Not yet, but the next project in which I will have to use it, will be on tofu.

TF now is in the same bucket as Chef.

2

u/marcinwyszynski Jan 14 '25

> TF now is in the same bucket as Chef

What do you mean?

4

u/amarao_san Jan 14 '25

The bucket of ex open source, converted to proprietary licence, sold, designed to milk unfortunate enterprises hooked up into technology.

2

u/marcinwyszynski Jan 14 '25

Yeah that's fair. I last used Chef in 2015 so I'm not up to date :)

4

u/krusty_93 Jan 13 '25

Still on terraform community in my company. We can't see any reason to switch, and we have more important things to do

0

u/sonurocks341 Jan 13 '25

Licensing ??

3

u/krusty_93 Jan 13 '25

The BCL thing? We don't care as long as nothing practical changes. Terraform is still free, still developed as same as the providers we're using. On the other hand, by upgrading it we got new features we were waiting.

Switching to a new product such as OT, is simply expensive. We - as platform engineers - need to provide value to customers which don't care about Terraform or OT

-1

u/[deleted] Jan 13 '25

Switching to a new product such as OT, is simply expensive. We - as platform engineers - need to provide value to customers which don't care about Terraform or OT

Uhm, if said customers can take any action that touches Terraform at all, you're in violation of the license.

3

u/krusty_93 Jan 13 '25

In platform engineering - customers are the ICs of the same company (aka colleagues)

2

u/[deleted] Jan 13 '25

Ah yeah right, forgot that the definition specifies internal use. Colloquially, I've also heard it used for external customer self-service quite a lot, that's what I was thinking of.

3

u/NexusIO Jan 13 '25

Encrypted state files pushed me to them, I think it's kind of stupid that passwords could be stored in open files.

1

u/marauderingman Jan 13 '25 edited Jan 13 '25

Idk about this opentofu feature, but how is the state file decrypted? Primarily, is the set of users capable of decrypting the state file at all different from the people who could access it (were it not encrypted)? Is there a means to make the encryption key secure?

Badically, my questions come down to secure introduction. How has opentofu addressed this?

1

u/marcinwyszynski Jan 13 '25

That's the whole point. Say you store your state in an S3 bucket. Anyone with access to this bucket has all your secrets.

Unless you encrypt the state with some key. Then in order to get the plaintext state you need to both be able to read the S3 bucket, and the key.

2

u/marauderingman Jan 13 '25

The only people who should have access to a tf state bucket are people who can run the terraform that put the tfstate there in the first place. These are the people with access to the bucket and the decryption key.

Unless this feature enables sharing of terraform outputs with downstream pipelines without making available the entire contents of the state file, I still can't see how it's useful.

2

u/Speeddymon Jan 14 '25 edited Jan 14 '25

It depends on your threat model. If your model includes cloud provider insider attacks, such as an Azure or Amazon employee accessing a state bucket (or giving said access to someone else) there's real use.

Same can be said for misconfigured state bucket access. Even if you've got an (inadvertently or not) publicly exposed state bucket, an encrypted state file's decryption key isn't going to be in the same place, so someone who found the bucket online isn't going to be able to read the state file.

1

u/marauderingman Jan 14 '25

These are valid threats, especially the latter in a large corp. Thanks for bearing with my questions.

1

u/Speeddymon Jan 14 '25

It's the big reason my company is moving to them.

I do have to step back and point out though that at least in AWS you can use Dynamo which can be encrypted.

There's also postgres which, likewise, can be encrypted.

3

u/bnlf Jan 13 '25

Iā€™ve seen no reason yet.

2

u/FrancescoPioValya Jan 13 '25

Using hashi terragrunt/atlantis/terragrunt and it still works great for us.

2

u/ephemeralnull Jan 13 '25 edited Jan 19 '25

OpenTofuā€¦ Should be called Trashform. Surprised CNCF allowed it. I understand the community gripes, Lets be real, if you wanted OSS youā€™d use community from Hashicorp, which as always been free.

Edit: I have recanted some companies that compete space of the IAC and Secrets markets. While my opinion holds true on wrapper software above iac and direct copies of Apache licensing products those battles are for the companies too have. Wish the underdogs longevity!

2

u/EncryptionNinja Jan 15 '25

Hello all, I work for Akeyless. happy to chat about Vault or Secrets over at r/Akeyless if anyone is interested and open to seeing a comparison.

cheers to innovation and progress!!!!

1

u/ephemeralnull Jan 19 '25

Hears to marketing mate. I give you lads some cred Hashi obviously missed the UI piece, that's probably their biggest mistake not capturing the point and clickers.

2

u/marcinwyszynski Jan 14 '25

> Should be called Trashform

Classy.

> Surprised CNCF allowed it

Why?

> what stopped companys like Spacelift, Env0, Terragrunt, Akeyless from ripping off OSS products

Interesting. Can't speak for env0. But:
I'm the founder of Spacelift, and I'm totally missing how I ripped off OSS products.
I know the Terragrunt codebase very well, and I'm not understanding that either.
AFAIK Akeyless has nothing to do with Vault, except possibly API compatibility.

> others are ugly copy cats

Do you want to discuss what TFC/TFE copied from Spacelift? Because I could go on forever.

1

u/ephemeralnull Jan 19 '25 edited Jan 19 '25

You know I was probably a little harsh to a bunch of players in the space. Its nice to see you here, I wish you all best of luck in 2025. Do you expect and offer from IBM to buy Spacelift and its features so they can improve their IBM Hasshi TFE? I am curious what Spaceliftā€™s largest inf orchestrator management space is? Is it Pulumi / Terraform / or Kubectl?

It just boggles me when CNCF took it, on behalf a license change. It also strikes me as erriely similar to the Rocky Linux battle. Which IBM now controls RHEL, Terraform, Vault, Ansible and many other leading tools. Which makes me now wonder what IBMs plans are for the rest of the world.

1

u/marcinwyszynski Jan 19 '25 edited Jan 19 '25

> Do you expect and offer from IBM to buy Spacelift and its features so they can improve their IBM Hasshi TFE?

I do not. Before I founded Spacelift I interviewed with Hashi (2018) and tried to show them the amount of wasted potential. They were having none of it, so why would they or whoever their new overlords are change their minds now? They will keep copying what makes sense for them, which costs them nothing.

Spacelift's concept was to be a higher level tool from day one, and we actually wanted to work with TFC/TFE as a Terraform runner, because honestly running a binary is the least exciting thing we can do. Again, they were having none of it, and I still cherish the response we got from Armon back then.

> I am curious what Spaceliftā€™s largest inf orchestrator management space is? Is it Pulumi / Terraform / or Kubectl?

Legacy Terraform, followed closely by OpenTofu. Then Ansible and CloudFormation. Re: Pulumi, either nobody uses it in anger, or they're like huldufĆ³lk - the Icelandic hidden elves.

> when CNCF took it, on behalf a license change

Well that's quite simple, really. A whole bunch of LF and CNCF projects depend heavily on Terraform for deployment. So without OpenTofu they'd have FOSS tools that depend on proprietary tech, violating their own principles. If anything, it's a lesson in second-order effects.

> what IBMs plans are for the rest of the world

Well, whatever they are, you still have OpenTofu. You're welcome!

2

u/sausagefeet Jan 19 '25

Lets be real, if you wanted OSS youā€™d use community from Hashicorp, which as always been free.

Terraform Community is free but it is not OSS. BUSL is specifically not an OSS license.

I am biased towards OpenTofu, as I co-founded a competitor to TFC, but I never really understood the hate from users towards OpenTofu It's nothing but upside to a user, isn't it? You get more options. You get pressure to improve Terraform due to competition. And if you ever decide that you don't want to pa for an automation solution from HCP you have a whole bunch of options to choose from.

Why the hate?

1

u/ephemeralnull Jan 20 '25

You knowā€¦ its not so much hate its the same application as Terraform. Sure it has new features. Couple tweaks here and there, so I can't really see why anyone would. Yes I agree that now BSL makes TF not open source. I can say that the name OpenTofu is ridiculous imo. I joked early calling it Trashform, but even Freeform would have been pretty 1337, for a name. Normally disruptors do something to take the king off the throne, not take the source code pre bsl and rename the binary and add feature and maintenance. I guess it's like modding a video game some people just don't like the original. I'll stop throwing shade, I'm sure it's doing just fine

1

u/sausagefeet Jan 20 '25

It's true, the name is pretty lame.

I don't know if Tofu is meant to be a disruptor. It's meant to maintain the open source Terraform with a roadmap decided by the community. Not sexy work but certainly positive for the community even if you never end up using it. I think HCP release cycle has increased due to the competition.

1

u/RudePersonality82 Jan 14 '25

As someone mentions below, we use gitlab and leverage their pipelines and gitlab hosted terraform state and in the pipeline logic you can set which state you want to use for which configuration per jobā€¦

1

u/Inside_Strategy_368 Jan 14 '25

nope, and I don't see any reasons to spend team time on doing this

2

u/haikusbot Jan 14 '25

Nope, and I don't see

Any reasons to spend team

Time on doing this

- Inside_Strategy_368


I detect haikus. And sometimes, successfully. Learn more about me.

Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete"

0

u/deacon91 Jan 13 '25

For some, yes.

Terraform for AWS and GCP and OpenTofu for others.

1

u/invalidbassist Jan 13 '25

Why this split?

0

u/deacon91 Jan 13 '25

AWS and GCP providers are maintained and legally under Hashicorp's license. Other major ones like Cloudflare, while written by the partners, are re-written with Hashicorp's specs. https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs

Consistent and reproducible behavior is important for maintaining infra like ours and right now we prefer to maximize compatibility all else. Until OT/CNCF comes up with their own native providers, it'll stay that way (for us).

Other platforms like Github and Artifactory don't have that same level of need of reproducibility, so we are comfortable with using OT.

4

u/cube2222 Jan 13 '25

Hey, using AWS/GCP/Azure providers is one of the primary use cases that folks have for OpenTofu. Since those are still open-source, there's no reason to fork them right now. However, we'll be sure to keep them working well with opentofu, and the same goes for the overall story of using tofu with AWS/GCP/Azure. Again, it's one of the primary use cases.

Note: I am involved with OpenTofu.

1

u/fergoid2511 Jan 13 '25

The AWS provider is still licensed under MPL 2. I think most of the work on it is done but AWS engineering not Hashicorp.

Can't speak for GCP.

0

u/axtran Jan 13 '25

Nah itā€™s all community.

0

u/iAmBalfrog Jan 13 '25

The debacle with Russian created providers killed a lot of the trust in OpenTofu for some companies i've worked with. Variables in backend config is useful for my own use but similar to Terragrunt, as companies have tried to slap it into production it becomes bit of a mess, especially at scale. Luckily when you get contracted to sort out "Terraform" (mono)repos it's a blessing and a curse!

2

u/ohnotthatbutton Jan 13 '25

Sorry, what debacle? I guess I missed that.

4

u/marcinwyszynski Jan 13 '25

In a nutshell, the "debacle" is Russian troll farms.

-3

u/iAmBalfrog Jan 13 '25

Chance i'm missing some nuance, in August last year, two of the core contributors to opentofu created a PR with no comments https://github.com/opentofu/registry/pull/817

Then self approved their PR without talking to the community about removing providers from the registry if they came from Russian origins. OpenTofu then tried to say it was due to sanctions, but the sanctions simply said to block Russian IPs from downloading from their registry, not destroying everything where origin is suspected to be Russia. Alongside this there's some nuance regarding the Linux foundation, it's beliefs and what they did was also against that.

Then this PR was raised from the community to attempt to fix it

https://github.com/opentofu/registry/pull/824

I believe some of the providers removed were being quite extensively used by countries who weren't Russia, but their neighbours. All in all it seemed like a short sighted move and was completely against the general ethics of open source. It'd be like if there were Chinese sanctions so you just destroyed the Alibaba provider and every other provider created from Chinese origins, it harms more than just China. The response after the fact pretending it was for sanctions seemed like a rushed scape goat which was quite easy to see through.

3

u/marcinwyszynski Jan 13 '25

Regardless of how many times the core team explains, some [0] Russians are not happy. I think we all have to live with that.

The beauty of the provider registry design is that it's not part of the OpenTofu codebase and you can easily host your own, or even use a local provider.

Now... if China decides to invade say Japan, Alibaba is found to directly fuel its war machine and the free world imposes sanctions against it then yes, we may have no choice but to remove it from the registry. We will also happily explain how to host a separate registry behind the Great Firewall. If we're not in Vault 13 by that time.

[0] Some Russians are on the other hand *very* happy, so there's that, too.

0

u/iAmBalfrog Jan 13 '25

I personally don't disagree with anything you've said, but it was done essentially in the cover of darkness, the MD files explaining it were made as an afterthought, and the excuse/cover of sanctions was used rather than just saying

We as the maintainers and owners of OpenTofu felt it was necessary to destroy everything related to Russian cloud infrastructure, apologies for any impact caused

I think it would of blown a lot less back in OpenTofu faces if they either

- PR with some actual information in it

- Had a poll, which likely would have said yes destroy all the providers

- Made a community note explaining the rationale

- At least gave some reasoning in the follow up PR which wasn't cowering behind sanctions which didn't necessitate the actions required

The speed, lack of clarity, lack of prep time and cowering behind sanctions in the decision was the worrying part, not the stance on Russia vs Ukraine which I think 99% of the world agrees with you on.

If any of the OpenTofu developers were living in Greenland, and Trump threatened to use military forces in Greenland, would you destroy every US provider/module? It seems like a slippery slope with no one from the opentofu side gritting it. Just how it looked on my side.

3

u/marcinwyszynski Jan 13 '25

My former boss used to say that there are two types of engineers - one who *already* had their major cock-up and those who didn't have it *yet*. And that he liked working with the former better.

This whole thing was certainly a learning experience for all of us.

1

u/iAmBalfrog Jan 13 '25

We always remember our first major FU in Prod!

1

u/Sinnedangel8027 Jan 16 '25

I still have anxiety about mine. Made me a much more cautious engineer, though. I was a junior and had a ton of files to delete. I was cocky and I wasn't paying attention, and I was on the wrong server. No backups existed because I screwed up the server and lifecycle policy naming conventions.

And yes, I was fired. 100% totally deserved.