Skip to main content

OpenTofu 1.8.0 is out with Early Evaluation, Provider Mocking, and a Coder-Friendly Future

OpenTofu 1.8.0 is out with Early Evaluation, Provider Mocking, and a Coder-Friendly Future

Since the 1.7 release, the OpenTofu community and core team have been hard at work on much-requested features, making .tf code easier to write, reducing unnecessary boilerplate, improving performance, and more. We are happy to announce the immediate availability of OpenTofu 1.8 with the following main features:

  • You can now use variables and locals in places that were not previously available, such as module sources, backend configuration and state encryption. Being able to assign variables more dynamically will eliminate code duplication and boilerplate code, making projects easier to maintain. However, we are not stopping there: future releases will see dynamic provider configuration assignments and more.
  • Since Terraform doesn't support these new language features, OpenTofu now supports the .tofu file extension. When a file with the .tofu extension is present, OpenTofu will ignore the identically named .tf file. Using this new file extension, module authors can use the new features of OpenTofu and still keep older code around for compatibility.
  • You can now use provider mocking as well as resource overrides with tofu test. This allows for more flexible testing similar to traditional software testing methods.

You can find the full list of improvements and changes on the What's new in OpenTofu 1.8? page.

Growth continues: ~30% increase in registry traffic

While we don't believe in tracking our users and OpenTofu does not have phone-home telemetry, we can observe a trajectory based on registry usage. In our last release post 3 months ago we recorded a peak of roughly 1.4 million daily requests to the registry. We are happy to report that this number has increased by roughly 30% to almost 1.8 million peak daily requests.

A graph showing the OpenTofu registry requests per day.

As before, the OpenTofu community is very active in reporting and voting on issues, fixing bugs, and helping out with testing. The number of GitHub stars grew by ~10% to almost 22.000, the top-voted issues received hundreds of votes and quite a few comments in the discussions. This release has also seen significant contributions from outside the core team, ranging from small fixes to large performance overhaul PRs. In total, over 100 issues and over 150 pull requests were opened since the last release. 26 people contributed to this release on the main repository alone, with several significant contributions added to other repositories as well.

Finally, we'd like to direct your attention to Awesome OpenTofu, a community page containing a host of tools, platforms, registry implementations and learning material for OpenTofu.

Better documentation for the future: the new RFC process

As the community kept working hand-in-hand with the core team it became clear that our previous RFC process based on GitHub Issues wasn't detailed enough. The linear nature of issue comments didn't encourage discussing specific parts of an RFC and the RFCs themselves did not contain enough context for someone in a few months or years to fully understand why the change was necessary.

Our new pull request-based RFC process fills this gap by using PR reviews to discuss parts of a document and the document itself encourages creating a historical record. We have trialled this process during the development of the early (static) evaluation feature and also the upcoming dynamic provider assignment functionality. We hope that these documents will provide a better view into the new features coming to OpenTofu and also help create a historical record on why engineering decision were made the way they were.

Coming soon: the OpenTofu Registry UI

In parallel to this release, we have been hard at work on a web-based user interface for the OpenTofu Registry. This user interface will allow you to browse and search for providers, resources and modules and read their documentation in a convenient format. We are aiming to release this user interface in the next few weeks.

A preview screenshot of the OpenTofu Registry UI

Fulfilling promises: our first Go libraries

OpenTofu was founded on the principle of openness and modularity. While it is not always easy to modularize a codebase with a long history, we have released our first Go libraries for interoperability.

TofuDL encodes the process of fetching the latest version of OpenTofu, verifying the signature and extracting the binary for local use into an easy-to-use Go library. Tool authors can use this library to cut down on the complexity of downloading the Tofu binary when needed. Furthermore, this library contains a full release mirroring tool, allowing you to build a release server with OpenTofu releases for air-gapped infrastructure that TofuDL-based tools can use to obtain the mirrored binaries.

The currently experimental libregistry provides structured access to the data stored in the OpenTofu registry using the metadata API. In the future, we will transition the processes currently written for GitHub Actions into this library, allowing you to execute all registry processes independently of GitHub. You can use this library as a basis for writing your own registry, although the batteries are definitely not included.

Please give these libraries a go (pun totally intended) and let us know what functionality you would like to see in them.

The future: more dynamic functionality, even more community-focussed development

Ever since we created our top-ranking issues list, new votes from the community started pouring in, giving us a strong signal on where you want us to take OpenTofu. By a large margin, the top-requested issue was one we partly solved in this release by introducing early evaluation for variables and locals. However, this is only the first step. As you helped us test the early alpha and beta of this release, one of the most commonly asked questions was: “When can I use early evaluation to dynamically configure providers?”

The top-voted enhancement reflects a similar sentiment. In 1.9 and beyond, we aim to bring you dynamic provider assignments and more early-evaluation features, which let you cut down on the unnecessary code repetition even further. If you are interested in this topic, give the corresponding RFC a read.

An ask for help: GPG keys for providers

Finally, we have a favor to ask. The OpenTofu registry currently contains GPG signing keys only for a small number of providers as these keys are not publicly available on GitHub. If you are a provider author, please submit your signing key here. It takes only a few minutes and does not require you to sign any legal documents or grant us access to your GitHub organization. If you are an OpenTofu user and you see that your providers are not signed, please let your provider author know that they can submit their keys and help secure the OpenTofu ecosystem.

You can identify a missing signing key by running tofu init and keeping an eye out for the following message:

Signature validation was skipped due to the registry not containing GPG keys for this provider

Thank you for your help!