Your involvement is crucial as we refine these features. If you have a non-production environment where you could test any of these new capabilities, we'd be grateful for your help. Even if everything works perfectly (which we hope it does!), your feedback via GitHub issues is invaluable to ensuring 1.10.0 becomes the rock-solid release our community deserves.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

After downloading one of the releases above, unpack the archive to find your tofu binary. For those who prefer verified downloads, you can also use the standalone installer with signature verification.

The Building Blocks of 1.10.0​

If you're just joining us for alpha 2, OpenTofu 1.10.0 is bringing several groundbreaking features to the table:

OCI Registry Integration​

OpenTofu now seamlessly integrates with OCI registries for both provider distribution and module installation (new for alpha 2). This is a game-changer for private, air-gapped environments and teams looking for more flexible ways to distribute their infrastructure components.

Configure provider installation from OCI Registries with a oci_mirror block:

provider_installation {
  oci_mirror {
    repository_template = "example.com/opentofu-providers/${namespace}/${type}"
    include             = ["registry.opentofu.org/*/*"]
  }
}

Or install modules directly using the new oci: source scheme:

module "vpc" {
  source = "oci://example.com/modules/vpc/aws"
}

For more information, see our alpha 1 blog post for provider instructions and our latest docs for module instructions.

Simplified State Management with Native S3 Locking​

Why use two services when one will do? The s3 backend now supports native locking without requiring DynamoDB, streamlining your state management in AWS environments with the simple addition of use_lockfile:

terraform {
  backend "s3" {
    bucket = "tofu-state-backend"
    key = "statefile"
    region = "us-east-1"
    use_lockfile = true
  }
}

Peek Behind the Curtain with OpenTelemetry Tracing​

Ever wondered what's happening under the hood during those long provider installations? Alpha 2 introduces experimental OpenTelemetry (OTel) tracing that gives you unprecedented visibility into OpenTofu's operations.

Getting started with tracing takes two steps. First, launch a tracing backend like Jaeger:

docker run -d --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  -p 5778:5778 \
  -p 9411:9411 \
  jaegertracing/jaeger:2.5.0

Then tell OpenTofu to use it with these environment variables:

# Required variables
export OTEL_TRACES_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_EXPORTER_OTLP_INSECURE=true

Now you can watch your OpenTofu operations unfold in real-time through the Jaeger UI at http://localhost:16686. Currently, tracing describes:

• Provider installation and downloads
• Lock file operations

This is just the beginning – future releases will expand tracing to cover even more of your OpenTofu workflow. Let us know what areas you want more insight into!

Deprecation for module variables and outputs​

It is now possible to communicate variable and output deprecation via the deprecated attribute! Module authors are able to mark variables and outputs as deprecated by including a suggestion on how to migrate. Module callers will receive a warning if their configuration is affected. Here is an example of configuration:

variable "examle" {
  type       = string
  deprecated = "'examle' variable must no longer be used due to a typo, use 'example' instead"
}

output "examle" {
  value      = "someval"
  deprecated = "'examle' output must no longer be used due to a typo, use 'example' instead"
}

For more information, see marking variable as deprecated and marking output as deprecated

Global Provider Cache Locking​

The Global Provider Plugin Cache allows OpenTofu to download providers into a shared cache directory. Prior to this release, it was not safe to use this with multiple instances of OpenTofu running in parallel as they could clobber each other. We now have added support for filesystem level locking to this cache!

export TF_PLUGIN_CACHE_DIR=/storage/tofu/cache

This now means the global provider plugin cache is safe for tofu to use concurrently:

• With your CI system that runs dozens of tofu inits in parallel
• With your orchestration tool that runs multiple pipelines at the same time
• With all of your Terragrunt projects and stacks

Multi-Project PostgreSQL State Management​

The pg backend gets a significant upgrade with the ability to specify custom table and index names, unlocking multi-project state management within a single database schema:

terraform {
  backend "pg" {
    conn_str    = "postgres://user:pass@db.example.com/database"
    schema_name = "opentofu"
    table_name  = "project_a_state"  # Default is "terraform_state"
    index_name  = "project_a_index"  # Default is "terraform_state_idx"
  }
}

We've also solved an issue that could cause state corruption when sharing a database between different OpenTofu versions, making your state storage more robust than ever.

Resource Migration with moved​

The moved block now supports migration between entirely different resource types:

moved {
    from=gpg_key.this
    to=gpg_key_pair.this
}

Fine-Grained Resource Removal with removed​

The removed block now supports lifecycle and provisioner configurations:

removed {
  from = aws_instance.example

  lifecycle {
    destroy = true  # Destroys the resource (default is false which just forgets it)
  }

  # Provisioners will run before destruction when destroy = true
  provisioner "local-exec" {
    when    = destroy
    command = "echo 'Cleaning up before destroying resource'"
  }
}

Streamlined Resource Planning​

The new -target-file and -exclude-file options transform how you manage complex deployments, allowing you to maintain consistent target and exclusion patterns across your team:

# Target specific resources listed in targets.txt
tofu plan -target-file=targets.txt

# Exclude specific resources listed in excludes.txt
tofu apply -exclude-file=excludes.txt

No more copy-pasting long resource addresses – just reference your carefully maintained resource lists.

Flexible State Encryption with External Key Providers​

Security-conscious teams will appreciate the new external key providers for state encryption, bringing unprecedented flexibility to your secret management approach:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./state_encryption_key.sh", "some_parameter"]
    }
  }
}

The PBKDF2 key provider now supports chaining, allowing you to compose multiple key providers:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./get_password.sh", "some_parameter"]
    }
    key_provider "pbkdf2" "passphrase" {
      chain = key_provider.external.password_manager
    }
  }
}

And That's Not All​

Alpha 2 packs numerous other quality-of-life improvements:

• The element function now accepts negative indices, with -1 selecting the last element
• Test run outputs can now be referenced in test provider blocks
• Force-unlock capability now extends to the HTTP backend
• Plan outputs now show forgotten resources count, improving visibility into state changes

Before You Upgrade​

As with any significant release, there are some key compatibility points to consider:

• On Linux, OpenTofu now requires kernel version 3.2 or later
• On macOS, OpenTofu now requires macOS 11 Big Sur or later
• OpenTofu 1.10 with the pg backend should not be used alongside older versions
• The ghcr.io/opentofu/opentofu image is no longer supported as a base image
• On Windows, symbolic links and junctions are now handled differently

For complete details, please review the full changelog.

Join the Testing Effort​

OpenTofu 1.10.0 is shaping up to be a landmark release, and your input can help make it truly exceptional. Whether you're intrigued by the OCI registry integration, excited about native S3 locking, or curious about OpenTelemetry tracing, we'd love your feedback.

Share your testing experiences through GitHub issues or join the conversation in the OpenTofu Slack. Every bit of feedback brings us closer to a rock-solid 1.10.0 release.

Thank you!

We have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider distribution through OCI registries​

One of OpenTofu's top-voted issues is to support distribution of providers and modules through OCI registries. This release brings the first part of it - now you can use OCI registries to install a copy of a provider through a special "provider mirror" location.

Creating a local mirror of some or all of the providers you use can reduce data transfer costs and can help with running OpenTofu in "air-gapped" environments that cannot access any services over the public internet.

Alternative provider installation methods are configured as part of the OpenTofu CLI Configuration. You can configure installation from OCI Registries using an oci_mirror block as part of your Explicit Installation Method Configuration:

provider_installation {
  oci_mirror {
    repository_template = "example.com/opentofu-providers/${namespace}/${type}"
    include             = ["registry.opentofu.org/*/*"]
  }
}

The above example specifies that any provider that belongs to the primary OpenTofu Registry should instead be installed from a repository in an OCI registry, constructing the repository address dynamically using the components of the provider source address.

We also prepared a full-featured guide on how to test OCI Registry Provider Mirrors.

For more information, please refer to the documentation. Also, you can check out our progress via the Provider and module packages from OCI registries RFC Tracker.

Native locking support for s3 backend​

Now, OpenTofu can leverage native s3 conditional writes to eliminate the need of DynamoDB to handle locks. This allows you to rely on a single cloud service to handle both storage and locking of the state file. Please, keep in mind, not all of the s3-compatible storage support this feature yet.

We introduced a new use_lockfile field, which makes OpenTofu create a separate lock file in the same bucket:

terraform {
  backend "s3" {
    bucket = "tofu-state-backend"
    key = "statefile"
    region = "us-east-1"
    use_lockfile = true
  }
}

For more information, please refer to the documentation of the s3 backend.

What else?​

This release brings a lot more other enhancements such as:

• External programs as key providers for state encryption;
• The element function now accepts negative indices;
• moved now supports moving between different types;
• Multiple enhancements for tofu test;
• Count of forgotten resources in plan and apply outputs;
• and much more!

You can find the detailed changelog here.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

• Provider iteration (for_each)
• The -exclude flag
• Improvements to early evaluation, encryption, AzureRM and HTTP backends
• Several new CLI options
• Significant performance improvements

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

In line with our support policy, this release also means that OpenTofu 1.6 is no longer supported and we will not release security updates for it anymore. If you are still using 1.6, please upgrade to at least 1.7.

Massive growth: ~300% increase in registry traffic, rising download numbers​

Yes, you read that right. While our previous release showed an increase of roughly 30% over a period of 4 months, in the current release the amount of registry requests have tripled to over 6 million requests per day, peaking at a data transfer of over 140 GB per day.

Similarly, the number of GitHub downloads has risen significantly by about 30% in the 1.8 release to almost 1.5 million downloads. Interestingly, we had over 5000 downloads on the 1.9 prerelease versions.

Apart from users, we also have a very active community helping out with reporting issues, fixing bugs, and helping newcomers with questions. The number of GitHub stars grew to over 23.000, we have received over 150 new issues and the community has been actively voting on them. For this release, our community has contributed over 200 pull requests with features and bugfixes from 49 contributors on the main repository alone.

OpenTofu Search (beta)​

Since our last release, we have indexed the documentation of over 4.000 providers and over 20.000 modules in the OpenTofu Search interface. This was a monumental effort producing over 146 GB of raw data and the project updates the documentation for new provider and module versions every 15-30 minutes. Thanks to the generous sponsorship by Cloudflare, our costs for maintaining this infrastructure are minimal. It took over 12.000 lines of combined Go and Typescript code to accomplish.

JetBrains support​

In their 2024.3 release, JetBrains has announced support for OpenTofu. The integration switches to OpenTofu when it detects a .tofu file in a project and provides OpenTofu-specific code completion, such as state encryption.

Visual Studio Code integration​

In parallel, the OpenTofu core team started working with the community on a possible port of the Visual Studio Code extension for OpenTofu.

Future plans​

With provider iteration now implemented, we are turning our attention to the other much-requested features. Most importantly, we already have a working prototype for the OCI provider registry and we are also looking for your input on the related RFCs. For more details on upcoming features take a look at the 1.10.0 planning milestone on GitHub.

If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and expand on the features presented in the 1.9.0-alpha2 blog post.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider iteration (for_each)​

One of the biggest challenges keeping the code clean in a multi-region or multi-zone deployment is the sheer number of providers and related configurations you have to juggle. Essentially, you will have to create duplicated code for each region or zone.

With provider iteration, you can now get rid of your code duplications by iterating over a set of providers instead of the duplicated code. If you have a small-scale setup with one of the cloud providers offering multiple zones, start by adding two variables:

variable "regions" {
  description = "A list of regions that should have a deployment."
  type        = set(string)
}

variable "disabled_regions" {
  description = "A list of regions that should be disabled and all resources removed."
  type        = set(string)
  default     = []
}

The regions variable serves as a list of regions you will want to deploy to. The disabled_regions variable will allow you to remove a region later without removing the provider. This feature is extremely important because if you remove the provider without removing its resources, OpenTofu will be unable to remove the resources in that region.

As a next step, you can create your provider declarations. As you can see, this is only a single declaration. The only restriction worth mentioning here is the alias. Due to technical limitations, in this version you can only use for_each in conjunction with alias.

provider "aws" {
  alias    = "by_region"
  region   = each.value
  for_each = var.regions
}

Finally, you can use the provider set to call a submodule. Note that in contrast to the provider block above, the for_each iterates only over the providers that are not disabled. This lets you deprovision a region properly and later completely remove the provider.

module "deploy" {
  source    = "./deploy"
  providers = {
    aws = aws.by_region[each.key]
  }
  for_each = setsubtract(var.regions, var.disabled_regions)
}

As this feature is very new, there are a few limitations in place you may want to observe:

1. You can only use for_each on variables and locals that can be obtained statically. Expressions that rely on data sources or resources are currently not usable.
2. If you have an already-deployed infrastructure, don't simply remove a provider from the list as this will make it impossible for OpenTofu to destroy the infrastructure in this region. Instead, you will need to implement removing that infrastructure first and then remove the provider from the list. See the disabled_regions variable for an example above.
3. Currently, each provider used in a for_each must have an alias. Providers without aliases are not supported for now due to internal technical reasons.
4. There is currently no way to pass a set of providers to a module, you can only pass individual providers.

The -exclude flag​

OpenTofu already has a -target option to only plan or apply certain resources. Why not apply everything except a certain resource? This was the thought behind the -exclude flag and, in fact, this was one of the highest upvoted feature requests for this release.

You can test it by creating the following simple configuration:

resource "local_file" "a" {
    filename = "a.txt"
    content  = "a"
}

resource "local_file" "b" {
    filename = "b.txt"
    content  = "b"
}

resource "local_file" "c" {
    filename = "c.txt"
    content  = "c"
}

If you run tofu apply -exclude local_file.b, you will see that OpenTofu creates a.txt and c.txt, but not b.txt.

Bugfixes and improvements​

Early evaluation improvements​

When using early evaluation introduced in OpenTofu 1.8, OpenTofu will now prompt you for the variables needed for evaluation.

The new encrypted_metadata_alias option for state encryption​

One of the tricky parts when using state encryption in previous versions is that OpenTofu needs to store the name of the key provider into the encrypted data alongside some metadata needed for decryption. This meant that changing the key provider name would involve using a fallback block and key provider naming for remote state data sources would have to be synchronized. With OpenTofu 1.9, we are introducing a new encrypted_metadata_alias option you can use to explicitly set the ID stored with the encrypted data:

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase               = "OpenTofu has encryption"
      # Note the fixed encrypted_metadata_alias here:
      encrypted_metadata_alias = "certificates"
    }
    method "aes_gcm" "mymethod" {
      keys = key_provider.pbkdf2.mykey
    }
    state {
      method = method.aes_gcm.mymethod
    }
  }
}

Logging and other improvements​

• You can now use the -consolidate-warnings and -consolidate-errors options to consolidate similar warnings and errors together.
• The HTTP backend now supports extended trace logging, including request and response bodies.
• OpenTofu will now prompt for values for input variables needed for early evaluation.
• tofu console now accepts expressions split over multiple lines, when the newline characters appear inside bracketing pairs or when they are escaped using a backslash.
• tofu test now throws errors instead of warnings for invalid override and mock fields.
• Several performance improvements for large graphs and large amounts of submodules.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

We have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider for_each​

Imagine you have to deploy an infrastructure that involves multiple regions using your cloud provider. In order to minimize code duplication, you created a module that you can use for each region. However, your main module still looks like this:

provider "aws" {
  alias  = "useast"
  region = "us-east-1"
}

provider "aws" {
  alias  = "uswest"
  region = "us-west-1"
}

provider "aws" {
  alias  = "eucentral"
  region = "eu-central-1"
}

module "deploy-useast" {
  source    = "./deploy"
  providers = {
    aws = aws.useast
  }
}

module "deploy-uswest" {
  source    = "./deploy"
  providers = {
    aws = aws.uswest
  }
}

module "deploy-eucentral" {
  source    = "./deploy"
  providers = {
    aws = aws.eucentral
  }
}

Starting OpenTofu 1.9, you can now use a for_each instead:

variable "regions" {
  description = "A list of regions that should have a deployment."
  type        = set(string)
}

variable "disabled_regions" {
  description = "A list of regions that should be disabled and all resources removed."
  type        = set(string)
  default     = []
}

provider "aws" {
  alias    = "by_region"
  region   = each.value
  for_each = var.regions
}

module "deploy" {
  source    = "./deploy"
  providers = {
    aws = aws.by_region[each.key]
  }
  // Here we make sure that all resources from a region are removed
  // if the region is disabled. This must be done before removing
  // a region entirely.
  for_each = setsubtract(var.regions, var.disabled_regions)
}

As you can see, you can pass in the set of regions using a variable and then call the module as many times as you need it.

However, there are some important considerations to remember when using for_each in this manner:

1. You can only use for_each on variables and locals that can be obtained statically. Expressions that rely on data sources or resources are currently not usable.
2. If you have an already-deployed infrastructure, don't simply remove a provider from the list as this will make it impossible for OpenTofu to destroy the infrastructure in this region. Instead, you will need to implement removing that infrastructure first and then remove the provider from the list. See the disabled_regions variable for an example above.
3. Currently, each provider used in a for_each must have an alias. Providers without aliases are not supported for now due to internal technical reasons.
4. There is currently no way to pass a set of providers to a module, you can only pass individual providers.

We are actively working on resolving these limitations and future OpenTofu versions will see this capability improved.

Exclude on plan and apply​

This flag is small but powerful: similar to -target, you can now tell OpenTofu to ignore a certain resource when applying your configuration.

For example:

tofu plan -exclude=kubernetes_manifest.crds

In this case, OpenTofu will ignore kubernetes_manifest.crds during planning.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

The Registry API​

OpenTofu and its predecessor Terraform rely on provider binaries created by the community to interact with various APIs. There are currently over 4,000 such providers in the OpenTofu Registry, enabling a wide range of integrations from cloud providers to managing your GitHub account. Anything that has an API to create some kind of resource can be integrated with OpenTofu.

Aside from providers, the community has also created well over 20,000 reusable modules that implement higher level functionality, such as provisioning an entire infrastructure with a cloud provider with only a few configuration options.

Since these providers and modules are created by the community, OpenTofu needs to know where to download them and what versions are available. This is where the Registry comes into play: it holds the information about available providers and modules, download URLs, checksums, and GPG keys for integrity verification.

Step 1: Service Discovery​

For both providers and modules, OpenTofu first requests the https://registry.opentofu.org/.well-known/terraform.json file, which has the following content:

{
  "modules.v1": "/v1/modules/",
  "providers.v1": "/v1/providers/"
}

This file lists the endpoints OpenTofu should query for information about modules and providers. For private registries there is also a third endpoint named login.v1, providing information about an OAuth endpoint to use for authentication. If you are interested in the details, you can read more about this protocol in the OpenTofu documentation.

Step 2: Version Listing​

With the endpoint information, OpenTofu can query the version listing endpoint for the desired provider or module.

• For providers this endpoint would be /v1/providers/NAMESPACE/NAME/versions (example).
• For modules it would be /v1/modules/NAMESPACE/NAME/SYSTEM/versions (example).

Step 3: Download Info​

Based on the information received, OpenTofu can request the information about the specific version, operating system and architecture.

• For providers, it would be located at /v1/providers/NAMESPACE/NAME/VERSION/download/OS/ARCH (example).
• For modules, it would be located at /v1/modules/NAMESPACE/NAME/SYSTEM/VERSION/download (example).

OpenTofu then downloads the provider from the supplied GitHub releases URL and verifies the checksum and signature, or clones the returned Git repository for modules.

Hosting the Registry (for free)​

As an open source project with a small core team working on developing OpenTofu itself, it was paramount that we kept the costs of running the Registry as low as possible both in terms of bandwidth and also in human cost. However, we also needed to make sure that the Registry had an uptime close to 100% since thousands upon thousands of developers would be left without a means to update their infrastructure if it went down.

Here we owe a big thanks to Cloudflare. Their very competitive pricing for R2 with no egress fees and their sponsorship of OpenTofu meant that we would be able to run the Registry essentially for free with no servers and scaling issues to worry about. The Registry codebase (written in Go) pre-generates all possible answers of the API above and uploads the static files to an R2 bucket.

Populating the Registry​

Alongside the Terraform license change, HashiCorp closed the Terraform Registry for software that isn't Terraform, so using it as a source of data for the OpenTofu Registry was out of the question. However, since the Terraform Registry was coupled exclusively to GitHub, it was relatively straight forward for us to use the GitHub search API to populate the Registry, if a little slow.

Updating the Registry, however, was a much harder problem. GitHub limits the API to ~5,000 requests per hour, which is not enough to update roughly 30,000 providers and modules in a speedy fashion, especially since some updates required multiple requests.

We could have requested provider authors to log in with their GitHub account, granting us an access token we could use for a higher rate limit, but that would have been impractical when we launched the Registry since we would have had to ask thousands of developers to log in at a time when OpenTofu wasn't even released yet.

The solution came by the way of the GitHub RSS feeds, which are not rate limited. The releases RSS located at http://github.com/USERNAME/REPO/releases.atom always contains the last 5 releases, which is sufficient if we only need to add the latest versions as it is unlikely that a provider or module would have more than 5 releases within an hour. For modules, we needed to query the tags instead of the releases, which was even easier because the git ls-remote command gave us all this information and was also not rate limited. (You are going to keep it that way, right, GitHub?)

The submission process​

Since we didn't need to ask provider and module authors for their credentials using OAuth, we were able to create a simple submission process that anyone with a GitHub account could use.

While anyone could submit a provider or a module, we still needed provider authors to submit their GPG keys so their binaries could be verified. Instead of asking for OAuth logins, we again decided to use the GitHub API in a creative way. In order to submit a GPG key for a provider, the author needed to set their organization membership to public for the repository of the provider and then submit a GitHub issue. We would verify their membership in the provider organization and process their GPG keys.

Having the submission process being as simple as opening a GitHub issue turned out to be quite popular. To date, the community has opened almost 1,000 pull requests and issues on the Registry repository. It also meant that provider and module authors working for larger organizations did not need to expend any organizational capacity to sign up for an OpenTofu account, resulting in quite a few high profile providers adding their GPG key.

Building a user interface​

After working on the Registry and taking a few months pause for some much-needed work on OpenTofu itself, we returned to building a search and documentation reading interface. As we would soon learn, this was a larger task and resulted in three times the amount of code needing to be written.

As before, we chose an architecture that would generate static files. Early on we had to make a decision between simply generating static HTML files or using a Single Page Application and load the data from an API. We chose the latter because we were concerned that a layout change would require a complete regeneration of all files, which would be cost-prohibitive to upload again and again.

Having made this decision we set out to build a backend and a frontend component, the former being responsible for producing the data the latter would consume. We built libregistry, a standardized Go library that would make it easier to access the metadata stored in the Registry repository and provide a useful abstraction layer on top of GitHub and the various creative API integrations we built to fetch the data.

Pre-processing the documentation​

While the Registry always regenerates all API responses from the raw metadata, this approach was not feasible for the documentation due to the sheer volume of data we needed to process. Not only would we have to produce documentation responses for tens of thousands of providers and modules, some of them also had several hundred versions, each of which needed their own copy of the documentation stored.

We decided that we would process the data from the source repositories directly into an R2 bucket without storing any intermediate data. This approach came with its own problems. While the Registry could make use of git to track changes in the intermediate data, we needed to make sure that our uploads to the R2 bucket were as close to atomic as possible so no partial uploads are left behind. While we have implemented a partial solution that can continue an upload, this still remains one of the unsolved issues with the Registry.

In order to simplify the necessary frontend logic for displaying the documentation, the backend's main job is to rename and move each of the documentation files into their standardized place. There is no formalized description on how providers can store their documentation, so the logic for extracting this information is only empirically known. We needed several iterations to work around various bugs as we expanded the number of repositories we ingested and discovered newer and newer edge cases.

Module schemas​

While providers typically have their own, explicit documentation, often generated by tools like terraform-docs, modules don't have such information readily available. This makes it difficult to generate information about their inputs, outputs and dependencies.

HashiCorp published terraform-schema for extracting this information, duplicating some of the module parsing logic from Terraform. However, we decided that maintaining duplicated codebases would likely cause a maintenance issue down the line and implemented this functionality directly into OpenTofu. This patch currently lives on a branch, but will be integrated into the main branch as an experimental feature at a later date.

Licenses​

During the ingestion process we also needed to concern ourselves with licenses: as we were unsure under what legal standard such a documentation dataset would fall, we deliberately chose a restricted set of licenses that we would accept into the Registry documentation. We performed automatic license detection on each provider and module repository to avoid ingesting content under potentially problematic licenses.

The OpenTofu Docs API (and how you can use it)​

Doing all this work on the backend and splitting the display logic from the data also had an unintended but very welcomed side effect: we were able to offer an API for provider and module documentation, which would come in handy as just a few weeks later Jetbrains requested just such an API for their OpenTofu integration.

The backend produces the dataset in this format and is easily runnable locally from the registry-ui repository, while the public API is available for anyone to build integrations with. We even made sure to include the correct CORS headers if you would like to build a browser-only integration. If you build something cool with it, let us know!

Search​

As we were building the backend, one issue was constantly on our minds: how do we make such a vast data set searchable? We hoped that it would be possible to simply generate a search index and let the client JavaScript deal with the entire search problem. As we were looking at lunr.js, a robust and mature library for search, it quickly became apparent that this path would be entirely unfeasible. Even with a limited data set, the download size of the search index quickly ballooned to several hundred megabytes, which is not exactly ideal for a snappy search functionality not to mention really upsetting to people with data caps.

Not wanting to run our own database server or involve any more service dependencies, we looked at Cloudflare's D1, a SQLite database service and a worker to handle search queries. While it initially looked promising, we discovered that we would have to submit all updates in a single HTTP request in order to run them in a transaction.

It would have been possible to work around it and still perform atomic search index updates, but we ended up using Neon, a database-as-a-service offering, instead. They don't explicitly sponsor OpenTofu, but their free tier was comfortably enough for our search index and the next tier was also quite affordable. Their tight integration with Cloudflare was also a very welcome addition.

To query the database hosted at Neon, we created a Cloudflare worker. This worker ended up handling all requests to api.opentofu.org, forwarding the static requests to R2 and handling the search queries itself.

The backend would prepare a line-delimited JSON (ndjson) file with a data feed at https://api.opentofu.org/registry/docs/search.ndjson, containing all recent updates to the search index that the worker could ingest and fill into the database.

Where do we go from here?​

The OpenTofu Registry Search is currently in beta, indicating that not everything is working yet. As we are expanding the amount of providers and modules indexed, we will certainly discover more edge cases that need to be fixed.

The libregistry library also duplicates a lot of the functionality present in the registry codebase as well. We want to deduplicate this functionality, both for long-term maintenance and because libregistry would make it easier for people to run their own mirror or even independent copy of the Registry.

During this process your feedback is invaluable for prioritization. If you find a bug or have a use case we haven't considered, please use GitHub issues to let us know.

• 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.

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.

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!

If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and expand on the features presented in the 1.8.0-alpha1 blog post.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider mocking in tofu test​

Building on the existing ability to override specific data sources, resources, and module calls, tofu test now supports mocking entire provider definitions. This new feature allows you to automatically generate mock values for resources and data sources on a per-provider basis. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

// This block will prevent OpenTofu from configuring aws provider.
// All provider's resources and data sources will be mocked.
mock_provider "aws" {
  mock_data "aws_ami" {
    defaults = {
      id = "ami-12345"
    }
  }
}

run "test" {
  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account.

Resource overrides in tofu test​

First introduced in OpenTofu 1.8.0-alpha1, you can now override resources, data sources and entire modules from your tests, allowing you to create similar behavior to mocks in traditional software testing. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

provider "aws" {
  access_key = "foo"
  secret_key = "bar"

  skip_credentials_validation = true
  skip_region_validation      = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
}

# This block disables refreshing the aws_ami.ubuntu data source
# and lets you manually specify the values:
override_data {
  target = data.aws_ami.ubuntu
  values = {
    id = "ami-12345"
  }
}

run "test" {
  # This block disables provisioning the aws_instance.web resource:
  override_resource {
    target = aws_instance.web
    values = {
      # You can add values here.
    }
  }

  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account. Similarly, you can use override_module to override an entire module.

Early variable/locals evaluation​

Introduced in OpenTofu 1.8.0-alpha1, this feature lets you use variables and locals for backends, module sources and encryption configuration as long as they are not dependent on resources, data sources or module outputs. This works even if a local is referencing a variable, for example. This is only the first in a series of improvements that will make the .tf code more flexible with more improvements coming in future releases.

The tofu init command will now consume your .tfvars file and let you specify variables using the -var and -var-file options. Please note that this alpha release will not prompt you for missing variables, which is a feature we will add later. Note, that tofu init will fail if it is missing variables needed for static evaluation.

For example, if you wanted to use the same configuration for your S3 backend and your AWS provider, you can now do this:

variable "aws_region" {
  default = "us-east-1"
}

terraform {
  backend "s3" {
    region = var.aws_region
  }
}

provider "aws" {
  region = var.aws_region
}

You can also use this to manage module versions with both registry references and git URLs.

locals {
  aws_module_version = "5.6.1"
}

module "webserver" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = local.aws_module_version

  // Other ec2_instance options
}

module "db" {
  source  = "https://github.com/terraform-aws-modules/terraform-aws-ec2-instance?ref=v${local.aws_module_version}"

  // Other ec2_instance options
}

Finally, here's how you can set up encryption with a passphrase using a variable:

variable "passphrase" {
  type = string
}

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

Override files for OpenTofu: keeping compatibility​

Since we are now adding features to OpenTofu that are not present in Terraform, we want to give module authors the ability to write code for both OpenTofu and Terraform without needing to maintain two copies of their modules. You can now create files named .tofu that are exclusive to OpenTofu. If you create a file named foo.tofu, OpenTofu will ignore the similarly-named foo.tf file. You can use this functionality to put your Terraform-specific code in the .tf file and then override it for OpenTofu in the .tofu file.

Bugfixes and improvements​

Static Variable Planing​

Static variables are now handled correctly when embedded in plan files. This was reported as a bug found in 1.8.0-alpha1.

tofu plan -out=tofu.tfstate -var="param=value"
# Variables are correctly read from the given plan and should not be specified via CLI
tofu show tofu.tfstate
tofu apply tofu.tfstate

Improved provider error messages​

Also included in the beta is improvements in error messages produced by misconfigured providers. Some defaulted providers which require configuration blocks were able to generate error messages like:

╷
│ Error: Insufficient features blocks
│
│   on <empty> line 0:
│   (source code not available)
│
│ At least 1 "features" blocks are required.
╵

This error message will now include information about which provider is encountering the specific missing-block validation issue to help the user track it down.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

Additionally, we are bringing you a feature that lets you use new OpenTofu features while still keeping compatibility with Terraform as well as the ability to override resources and data sources in tofu test. The release also includes a host of smaller improvements and bugfixes to various parts of OpenTofu listed in the changelog.

Now we'd like to ask you for help: we have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Early variable/locals evaluation​

This feature lets you use variables and locals for backends, module sources and encryption configuration as long as they are not dependent on resources, data sources or module outputs. This works even if a local is referencing a variable, for example. This is only the first in a series of improvements that will make the .tf code more flexible with more improvements coming in future releases.

The tofu init command will now consume your .tfvars file and let you specify variables using the -var and -var-file options. Please note that this alpha release will not prompt you for missing variables, which is a feature we will add later. Note, that tofu init will fail if it is missing variables needed for static evaluation.

For example, if you wanted to use the same configuration for your S3 backend and your AWS provider, you can now do this:

variable "aws_region" {
  default = "us-east-1"
}

terraform {
  backend "s3" {
    region = var.aws_region
  }
}

provider "aws" {
  region = var.aws_region
}

You can also use this to manage module versions with both registry references and git URLs.

locals {
  aws_module_version = "5.6.1"
}

module "webserver" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = local.aws_module_version

  // Other ec2_instance options
}

module "db" {
  source  = "https://github.com/terraform-aws-modules/terraform-aws-ec2-instance?ref=v${local.aws_module_version}"

  // Other ec2_instance options
}

Finally, here's how you can set up encryption with a passphrase using a variable:

variable "passphrase" {
  type = string
}

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

Override files for OpenTofu: keeping compatibility​

Since we are now adding features to OpenTofu that are not present in Terraform, we want to give module authors the ability to write code for both OpenTofu and Terraform without needing to maintain two copies of their modules. You can now create files named .tofu that are exclusive to OpenTofu. If you create a file named foo.tofu, OpenTofu will ignore the similarly-named foo.tf file. You can use this functionality to put your Terraform-specific code in the .tf file and then override it for OpenTofu in the .tofu file.

Resource overrides in tofu test​

This version also brings an improvement for the tofu test command. You can now override resources, data sources and entire modules from your tests, allowing you to create similar behavior to mocks in traditional software testing. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

provider "aws" {
  access_key = "foo"
  secret_key = "bar"

  skip_credentials_validation = true
  skip_region_validation      = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
}

# This block disables refreshing the aws_ami.ubuntu data source
# and lets you manually specify the values:
override_data {
  target = data.aws_ami.ubuntu
  values = {
    id = "ami-12345"
  }
}

run "test" {
  # This block disables provisioning the aws_instance.web resource:
  override_resource {
    target = aws_instance.web
    values = {
      # You can add values here.
    }
  }

  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account. Similarly, you can use override_module to override an entire module.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

• End-to-end state encryption protects your state file from prying eyes, no matter what storage backend you use. You can provide your encryption passphrase securely using environment variables, or use a key management system such as AWS KMS, GCP KMS, or OpenBao. This feature has been developed in collaboration with Stephan Bartels (Interhyp) and Alex Scheel from the OpenTofu community, whom we would like to thank for their work on this feature.
• Dynamic provider-defined functions let a provider not only provide resources, but also native functions you can use in your OpenTofu code. What's more, we added an OpenTofu-only feature to let providers dynamically define custom functions based on your configuration. This enhancement allows you to fully integrate other programming languages as shown in our live stream. You can try out this functionality with our experimental Lua and Go providers.
• The removed block lets you mark OpenTofu-created resources for removal from the state file, but still keep the infrastructure you created.
• Loopable import blocks let you bulk-import resources declaratively in your OpenTofu code, helping with large-scale migrations.

As with the previous version, OpenTofu remains a drop-in replacement for its predecessor Terraform™ 1.5 and has easy migration paths from later versions. Check out the overhauled migration guides for detailed migration instructions. You can find the full list of changes and comprehensive examples in the documentation.

The OpenTofu community grew significantly​

Since the first release, the OpenTofu community and adoption have been growing significantly. While we don't believe in tracking our users and don't have accurate numbers, we have seen a constant month-over-month growth in our registry usage since our launch only 4 months ago. Over just the last month our registry usage has more than doubled to well over a million requests per day.

Additionally, we had 65 unique contributors for this release alone and have recently reached 20,000 stars on GitHub. Since January, we have seen our community spread the word about OpenTofu, open over 200 new issues and file even more pull requests.

What is OpenTofu anyway?​

If you are new to OpenTofu, welcome! We started as a fork of HashiCorp's Terraform™ after its license was changed to the restrictive BUSL alongside a frequently changing licensing FAQ. OpenTofu is an infrastructure-as-code tool that lets you declaratively create cloud infrastructure with thousands of APIs by writing your own code or using one of the tens of thousands of community-provided modules.

For example, you could create an EC2 instance on AWS like this:

resource "aws_instance" "web" {
  ami           = "add AMI ID here"
  instance_type = "t3.micro"
}

OpenTofu's main advantage is that it records any changes to your cloud infrastructure in a state file, which allows it to later modify the same infrastructure, or tear it down if you created it as a test.

The future and beyond: OpenTofu 1.8 is waiting​

OpenTofu is first and foremost a community-driven project. We are looking forward to the continued tradition of working on issues the community deems important. For transparency and to encourage everyone to vote, we have created a list of the most upvoted issues.

While much of OpenTofu 1.8 is still in planning, we are currently finalizing a proposal for a feature that lets you use variables as module sources, backend configuration, and more. Early evaluation of variables has been requested in over 30 issues so far and is one of the most-requested features in OpenTofu.

If you have a feature you would like to see in OpenTofu, please don't hesitate to open an issue or reach out to us on Slack.

As with the alpha version, we did everything we could to test this version and would like to ask for the help of the community to help us test this version on non-production workloads. Grab your copy on GitHub and let us know what you think using a GitHub issue.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider-defined functions​

The new Terraform Plugin SDK added support for provider-defined functions that you can use directly in OpenTofu. This is a significant improvement over using data sources as provider-defined functions don't increase the size of your state file and require less code to write.

If you want to test provider-defined functions, you can use the corefunc provider by Ryan Parman:

terraform {
  required_providers {
    corefunc = {
      source = "northwood-labs/corefunc"
      version = "1.4.0"
    }
  }
}

provider "corefunc" {
}

output "test" {
  value = provider::corefunc::str_snake("Hello world!")
  # Prints: hello_world
}

Loopable import blocks​

We made several improvements to the declarative import blocks, most prominently you can now use the for_each instruction on the block. We have prepared a full documentation for this feature.

In previous OpenTofu versions, you could already use the import block to declaratively import resources, for example:

resource "random_id" "test_id" {
  byte_length = 8
}

import {
  to = random_id.test_id
  id = "Y2FpOGV1Mkk"
}

output "id" {
  value = random_id.test_id.b64_url
}

In this new version you can now also declaratively import resources in a loop:

variable "server_ids" {
  type = list(string)
}

resource "random_id" "test_id" {
  byte_length = 8
  count = 2
}

import {
  to = random_id.test_id[tonumber(each.key)]
  id = each.value
  for_each = {
    for idx, item in var.server_ids: idx => item
  }
}

output "id" {
  value = random_id.test_id.*.b64_url
}

The example above will let you specify some random IDs from a variable, and let others be automatically generated.

State encryption​

State encryption is one of the flagship features of this release. We have prepared a full documentation for this feature. Since the alpha release we overhauled the migration process from unencrypted to encrypted state files and the rollback mechanism to make the syntax more explicit.

Before you test this feature, please make a backup of your state file. You can then add the following block to enable state encryption:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      ## Enter a passphrase here:
      passphrase = ""
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    ## Remove this after the migration:
    method "unencrypted" "migration" {
    }

    state {
      method = method.aes_gcm.my_method

      ## Remove the fallback block after migration:
      fallback{
        method = method.unencrypted.migration
      }
      ## Enable this after migration:
      #enforced = true
    }
  }
}

You can migrate back using the following syntax:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      ## Enter a passphrase here:
      passphrase = ""
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    method "unencrypted" "migration" {
    }

    state {
      method  = method.unencrypted.migration
      enforced = false
      fallback{
        method = method.aes_gcm.my_method
      }
    }
  }
}

If you have access to an AWS, GCP account, or an OpenBao/MPL-licensed HashiCorp Vault installation, you can also test these key providers.

Removed block​

The removed block lets you remove a resource from the state file but keep it on the infrastructure. We have prepared a full documentation for this feature. You can test it by creating a resource first:

resource "local_file" "test" {
  content = "Hello world!"
  filename = "test.txt"
}

After applying, you can replace the resource with a removed block:

removed {
  from = local_file.test
}

After the next apply, you will see that the local_file.test resource no longer exists in your state file, but the test.txt file should still exist on your disk. You can now remove the removed block safely.

Built-in function changes​

This release also contains several new functions and changes to existing functions:

• New function: templatestring
• New function: base64gunzip
• New function: cidrcontains
• New function: urldecode
• New function: issensitive
• nonsensitive no longer returns an error when the applied values are not sensitive.
• templatefile now supports recursion up to a depth of 1024.

CLI changes​

There are also several changes to the CLI:

• tofu init now supports the -json flag for JSON output.
• tofu plan now has a -concise flag to shorten the plan output.
• tofu console now works on Solaris and AIX.
• The CLI now supports the XDG directory specification.
• Aliases for:
  • state list → state ls
  • state mv → state move
  • state rm → state remove

Testing feature changes​

• Tofu now reads the .tfvars file from the tests folder.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code. All such statements have zero basis in facts.

HashiCorp has made claims of copyright infringement in a cease & desist letter. These claims are completely unsubstantiated.

The code in question can be clearly shown to have been copied from older code under the MPL-2.0 license. HashiCorp seems to have copied the same code itself when they implemented their version of this feature. All of this is easily visible in our detailed SCO analysis, as well as their own comments which indicate this.

Documents​

• HashiCorp's C&D Letter
• Our Response
• Source Code Origin Document: [HTML, PDF] ⇐ For the detailed code analysis, see here.

To prevent further harassment of individual people, we have redacted any personal information from these documents.

Conclusion​

Despite these events, we have managed to carry out significant development on OpenTofu 1.7, including state encryption, “for_each” implementation for “import” blocks, as well as the all-new provider-defined functions supported by the recently released provider plugin protocol.

On that note, we will be releasing a new pre-release version next week, and we are eager to gather feedback from the community.

— The OpenTofu Team

We have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

State encryption​

State encryption is one of the flagship features of this release. We have prepared a full documentation for this feature.

To test this feature, please make a backup of your state file and then add the following configuration:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = "" # Enter a passphrase here
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
      fallback{} # Remove after the migration is complete.
    }
  }
}

You can migrate from an encrypted state file to an unencrypted one like this:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = "" # Enter a passphrase here
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      # Leave this block empty apart from the fallback block.
      fallback{
        method = method.aes_gcm.my_method
      }
    }
  }
}

If you have access to an AWS account, you can also test the AWS Key-Management Service key provider. (Please note the AWS KMS pricing.)

Removed block​

The removed block lets you remove a resource from the state file but keep it on the infrastructure. We have prepared a full documentation for this feature. You can test it by creating a resource first:

resource "local_file" "test" {
  content = "Hello world!"
  filename = "test.txt"
}

After applying, you can replace the resource with a removed block:

removed {
  from = local_file.test
}

After the next apply, you will see that the local_file.test resource no longer exists in your state file, but the test.txt file should still exist on your disk. You can now remove the removed block safely.

Built-in function changes​

This release also contains several new functions and changes to existing functions:

• New function: templatestring
• New function: base64gunzip
• New function: cidrcontains
• New function: urldecode
• New function: issensitive
• nonsensitive no longer returns an error when the applied values are not sensitive.
• templatefile now supports recursion up to a depth of 1024.

CLI changes​

There are also several changes to the CLI:

• tofu plan now has a -concise flag to shorten the plan output.
• tofu console now works on Solaris and AIX.
• The CLI now supports the XDG directory specification.
• Aliases for state list → state ls, state mv → state move, state rm → state remove.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

Roni Frantchi wrote a great article prior to the holidays, describing our road so far and up to the release candidate. It’s an excellent resource to learn more about how we got to where we are now.

I’ll be focusing on the now, and what we are up to in the near future.

New Features​

Starting with the release itself, OpenTofu 1.6.0 comes with a bunch of new stuff:

• The testing feature lets you test your OpenTofu configurations and lets module authors test those modules. It’s a great stability improvement and is now fully integrated with the core of OpenTofu.
• The S3 state backend was updated and includes many new authentication methods. Crucially, it still works with S3-compatible object storage.
• We have a new provider and module registry, which follows a Homebrew-like architecture and is fully based on a git repository. Hosted on CloudFlare R2, it’s snappy and highly-available. Publishing a new provider or module is now just a pull request away!

And many many more! Minor improvements, bug fixes, performance improvements, the changelog is huge! Just check it out, if you want all the details!

The Value of Open Source​

OpenTofu would be far from where it is without its active community support. The OpenTofu Slack community is growing and thriving. We’ve had almost 60 contributors help make OpenTofu great over the past few months.

Open-source is all about collaboration without borders, across the community, to the benefit of all.

Just to name an example, an RFC for client-side state encryption, a headline feature we wanted to have in OpenTofu, has been submitted by a community member - the same one who was trying to bring it to Terraform for years. Over the span of multiple months they worked to polish the PoC and RFC, involving many community members in the discussions. This RFC has recently been accepted and we’re collaborating with the RFC author to get it into OpenTofu 1.7. Thank you!

When we were working on the registry, we had multiple RFCs submitted. We consulted numerous people all over the industry, including authors of previous similar registries like Homebrew, so that we could get the registry right on the first attempt. So far it has indeed been a success - it’s fast to tofu init, community members have already successfully submitted providers, and the whole thing is very cheap to run.

As an open-source project, OpenTofu also benefits from sponsorships from many companies and projects. Other than the companies who started the initiative and are supporting OpenTofu with dedicated full-time engineers, we also had Cloudflare support us with hosting the registry, and BuildKite supported us with hosting release artifacts.

This, and all the other discussions, issues, proposals, contributions - you name it - are the value of open-source, and what we believe will set OpenTofu apart long-term.

What’s Next?​

It took us a while to come out with this initial release. There has been a lot of one-time work that needed to be done to get this project set up for success. But that work is now done, and we’re ready to dive right into new development, with big new features ahead!

First, and we know that this is important to many, we’re aiming to maintain a reasonable amount of compatibility with Terraform where it makes sense. We’re not going to be pushing for big DSL changes, we’re not going to be pushing for provider protocol changes, nothing of the sort. We’ll keep the migration path both ways easy for the foreseeable future.

The biggest change coming soon, slated for 1.7, is the client-side state encryption. Asked for by many and for a long time now, it will let you encrypt both your state files and plan files end to end. This is valuable to projects working in a regulated environment, and ones going for maximum security. You can find the tracking issue here.

Initially, we’ll add support for user-provided keys and a couple of widely-used key management services. Long-term, depending on the usage we see and how the community responds, we might be introducing a plugin system so you can bring arbitrary key management services to it.

Parameterizable backends, providers, and modules have been a very common community request, e.g. parameterizing module versions using variables, maybe even instantiating providers using for_each parameters on a static list of values. This is something we’re looking into and hope to introduce an answer for eventually.

Other than that, we’ve seen many requests for adding new state backends - and that makes sense. After all, OpenTofu is really about the ecosystem it integrates with. However, instead of bringing it all to the core of OpenTofu, we’re looking into introducing a plugin system to state backends, similar to providers. Third-party extensibility is something we see as a selling feature of OpenTofu, and we want to continue improving on that.

Those are big improvements, but there are also numerous smaller improvements we’ll be introducing, many of them being suggestions or even full-blown contributions from the community. If there’s something you’re missing in OpenTofu, make sure to submit an issue, we’d love to hear about it!

Take it for a spin!​

Most crucially, with today’s release, OpenTofu is ready for prime time. In other words, it’s time to install it, and start porting your stuff over!

This release includes bug fixes, stability improvements, and updates to documentation. Importantly, this version highlights the stability of our new public registry, which debuted with the v1.6.0-beta1 release three weeks ago, and has been extensively tested by us and the early adopters from the OpenTofu community.

From Idea to Release Candidate in 4 Months​

The OpenTofu journey has been a whirlwind, spanning from a proposition to a release candidate in just four months.

This is a major milestone for us, but also a bittersweet moment. Looking back on the beginning of our journey, there was hope that HashiCorp would hear our appeal, reverse its decision and restore balance to the ecosystem.

Yet, here we are … and everything that transpired after those initial weeks of surprise, hope, and disappointment can only be characterized as a case study of collaboration. Peers, community, and competitors all united to work together to preserve an open-source option for Infrastructure-as-Code.

To recap, here are the major milestones so far:

As of December 18th, OpenTofu had surpassed 31,000 downloads, had 60 committers, and had seen over 1,000 pull requests and issues. The project’s main repository has also amassed over 16,450 GitHub stars on top of the 36,200+ GitHub stars for the manifesto.

Now, with that out of the way, let’s talk shop.

The Registry Challenge​

From the moment the OpenTF fork was announced, it was evident that a new public registry would be needed—an open-source substitute for the Terraform one, which is no longer accessible for non-Terraform projects following the TOS changes.

Similar to its predecessor in function, this new registry would have to be a highly available package resolution service for all providers and modules used by OpenTofu. Additionally, it had to meet other specific criteria, including:

• The registry had to be as self-sufficient as possible and require as little maintenance as possible.
• Anticipating increasing demand, it needed to be built for high availability and perform well at scale.
• It should smoothly transition from HashiCorp's registry, following the 'drop-in replacement' approach.
• Whatever we went with, it had to be open-source.

Brewing Together​

Homebrew is the de facto standard package manager on macOS – just as APK or RPM is to Linux or Chocolatey/Winget is to Windows. Its simple nature, open-source package database at its core, and efficiency for packaging applications inspired something similar that would be ideal for our needs, while its popularity served as evidence of its scalability.

As we were discussing this, Homebrew lead Mike McQuaid, who has been working on that project for more than 14 years, took notice of our conversation and joined the fray, contributing helpful insights about the repository structure:

For me, this experience highlighted the importance of the Open Source concept and reminded me that without its inherently collaborative nature, engagements like that would be few and far between.

This instinctive and uninhibited camaraderie is what Open Source is all about.

Implementation​

Amongst other things, Mike’s advice for us was to fragment the repo, to improve performance:

“We went through a ‘sharding’ process recently so that we have formulae/casks in our largest repositories split into subdirectories…The ‘git’ performance is dramatically better in this format.”

Following up on it, we built the registry (https://registry.opentofu.org) as a collection of alphabetized subdirectories broken down by namespace. These were hydrated with information from all providers and modules currently available on GitHub, each with its own JSON file with metadata and other specifics.

Importantly, using static files and hosting them on a Cloudflare R2 public bucket also lets us take full advantage of its CDN capabilities, ensuring performance and high availability with over 94% cache hit rates (on that note, huge THANKS to CloudFlare for sponsoring this project!).

Outside of our own tests, the four most requested files were:

• /.well-known/terraform.json
• /v1/providers/hashicorp/null/versions
• /v1/providers/hashicorp/template/versions
• /v1/providers/hashicorp/aws/versions

With the registry live, we set up a GitHub Action to scan for updates to indexed resources. We also introduced an IssueOps process for adding new providers. With it in place, new submissions would be auto-processed and auto-validated when they go into the registry, with Issues providing context and transparency.

We’re currently exploring a dedicated UI for package and documentation browsing.

Next Stop: Jan 10th​

With the holidays in full swing, we decided to roll out a release candidate first and schedule the GA for January 10th. Meanwhile, you can already start testing OpenTofu by simply following the directions provided here. It is a drop-in replacement so Terraform users will feel right at home, which is the whole idea.

If you are interested in contributing to the project, please check out these contribution guidelines, and don’t forget to join our Slack community.

Happy holidays!

P.S.​

While concluding the work on this post, and the upcoming release, we learned that Mitchell Hashimoto, HashiCorp’s legendary co-founder, announced that he will leave the company after 11 years.

Mitchell’s work on projects such as Vagrant, Consul, Vault, and of course Terraform is a source of inspiration for us and many others within the Open Source community.

The entire OpenTofu team extends its heartfelt gratitude to Mitchell for all of his numerous contributions, as we eagerly anticipate learning about the next steps in his already remarkable journey.

This is our journey with the OpenTofu testing feature.

It’s an interesting introduction to what’s going on behind the scenes at OpenTofu, as we work on our own pipelines. In this case, we are taking raw, experimental code and turning it into something that keeps up with (and possibly outperforms) Terraform v1.6.0 with the drop-in replacement, OpenTofu v1.6.alpha.

The Feature​

As part of HashiCorp Terraform License changes, we joined the OpenTofu initiative. And one of our first tasks is to get OpenTofu up-to-date with the upcoming Terraform 1.6.0, which means getting the testing feature from experimental to production-ready.

At the time of the fork, the testing feature did already exist in the codebase. However, it was still in an experimental state, without any documentation as to how the feature worked, and without much test coverage on the test feature’s own capabilities.

That meant we had to figure out the purpose of what seemed like a WIP testing feature, the pros and cons of this approach, and figure out what was missing to get the feature out of “development hell”

We started out mapping the feature by doing a few different things:

First, we read previous tests to understand how the feature behaves in different scenarios. Next, we thoroughly read through its code to get its ins and outs. Then, we tried it out ourselves to get a feel of using the new testing capability.

These are important, as you don’t want to just jump in and start changing code based on what you think it should look like. You need to understand the architecture and intent of the original implementer, so that the code you write complements it, rather than fighting it.

After this effort, we had a full grasp of the testing feature. It was a framework built to help the users test out their configuration in modules in an end-to-end manner, per module. It makes sure the modules act as expected in common cases, while predictably and safely responding to failure conditions, like a misconfiguration.

The testing feature introduces *.tftest.hcl files. These 1) describe your testing suite and 2) support a specific subset of HCL blocks. The most important block there is the new run block, which constitutes a test run.

When executing tofu test, each run block executes a tofu plan or tofu apply behind the scenes, running your module with the configuration specified for the test, and actually creating resources in your cloud (in the case of apply).

After each run, it performs validations; i.e., it makes sure that 1) all assertions pass, 2) none of the checks are failing, and 3) the plan/apply has finished successfully.

After tofu is done performing all the runs and tests, it attempts to destroy all the resources that were created as part of that tofu test run.

How did we approach it?​

Throughout our initial testing and code reading, we made a list of feature behaviors that were not covered with tests in the codebase, and also listed behaviors that we felt had the potential to not work properly.

We mostly relied on the code we read, and our knowledge of legacy Terraform and prior issues. For most of those, we ended up creating pull requests, adding test coverage, or actually fixing bugs.

During our time testing out the feature, we encountered some bugs, and came up with some suggestions to actually improve the feature on top of what was already in the pre-forked codebase. Below are some examples of such bugs that we ended up fixing:

Bug 1: Sensitive Value in run block​

Bug description: tofu test crashes when evaluating a sensitive value inside a run block’s assertions.

While playing around with our manual QA scenarios, we found out that running tofu test can, in a certain scenario, crash the program. Specifically, this happens when the configuration includes a run block that has an assertion, and that assertion itself relies on a sensitive value (see the code sample below for main.tftest.hcl).

This isn’t ideal, as a crash in tofu test means that there are now resources in your cloud, for which tofu has no recollection.

You could achieve this crash by running the following configuration:

main.tf:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "5.14.0"
    }
  }
}

resource "aws_secretsmanager_secret" "my_secret" {
  name = "my_secret"
}

resource "aws_secretsmanager_secret_version" "my_secret_version" {
  secret_id = aws_secretsmanager_secret.my_secret.id
  secret_string = "secret_value"
}

main.tftest.hcl:

run "secret_test" {
	assert {
		condition = aws_secretsmanager_secret_version.my_secret_version.secret_string == "secret_value"
		error_message = "bad secret"
	}
}

Running this configuration with tofu test would actually crash tofu. aws_secretsmanager_secret_version.my_secret_version.secret_string is a sensitive value, and OpenTofu crashed while attempting to evaluate if it was true or false. (You can follow the thread on GitHub).

Debugging this was a simple manner of running the CLI in a debugger (using the debug-opentofu script which uses delve for debugging), then following the code and the crash stack trace in order to figure out the source of the issue. Finally, in order to figure out how to fix the issue, we checked how this issue was solved for other types of conditions in the codebase.

The issue stemmed from how the evaluation of values in HCL works, using the go-cty library. We won’t get into too much detail about how this evaluation works, but certain values can be “marked” with additional information (such as marking the value as sensitive), and certain actions cannot be made on marked values, causing this panic.

This is intentional, to make sure that the code authors always handle those marks explicitly, instead of relying on some (potentially unwanted) implicit behavior.

In this case, simply unmarking the value prior to checking the boolean value of it was the way to go: resultVal, _ = resultVal.Unmark(). You can see the full code here.

It’s interesting to note that this issue had already occurred for other such conditions before in the legacy codebase, such as the precondition block or for a variable’s custom validation rules which have similar behavior.

Bug 2: Null Output Reference​

Bug description: tofu test crashes when referencing a null output.

Similarly to the previous bug, we went over our manual QA scenarios and found a scenario where tofu test crashes: When a run condition references an output that has a null value.

You could achieve this crash by running the following configuration (More info here):

main.tftest.hcl:

output "my_output" {
  value = null
}


run "test_run" {
  assert {
    condition = output.my_output != "something"
    error_message = "good"
  }
}

For this one, after some debug work, we found out that this is due to tofu not serializing null outputs as actual outputs. They will not appear as outputs in the state, for example.

However, for the tofu test feature, the assertions had to evaluate those null outputs as having nil value, even though those outputs are not serialized.

The code was as follows:

output := d.Evaluator.State.OutputValue(addr.Absolute(d.ModulePath))
val := output.Value
if val == cty.NilVal {
   // Not evaluated yet?
   val = cty.DynamicVal
}

if output.Sensitive {
   val = val.Mark(marks.Sensitive)
}

return val, diags

OutputValue returns nil if no output was found in the address, including the case where the output value was null and therefore was not serialized. So, for the fix, we made sure we return a nil value in this case

if output == nil {
   return cty.NilVal, diags
}

You can see the full code here

Other Test Feature Improvements and Suggestions​

Other than those crash fixes, we found it mostly lacking in test coverage (which makes sense, it was still in alpha). For the testing feature, we saw a bunch of scenarios not being covered by any kind of test, and bug fixes were also often missing test coverage.

As a consequence, we’ve added many new test cases to the integration test suite of the testing feature. We felt higher test coverage was quintessential for an open-source project that will be widely used, considering most of its existing codebase is already pretty old. More info on those test cases can be found here.

Also, we’ve started creating issues for suggestions to better stabilize the feature. For example, a failure during the resource cleanup at the end of a tofu test run might fail, causing resources to still exist in your cloud provider. If such a scenario happens, OpenTofu simply lists the names of the resources (in HCL) that have not been deleted properly.

This is probably not good enough, as it could be very hard to find those resources later inside your cloud provider without further information. So, we’ve suggested to at least print out the IDs of those resources, so you can find them more easily in your cloud provider for deletion.

What we’ve learned​

This blog walked through what we learned while working on and troubleshooting OpenTofu’s new testing feature. We used code debugging and black box testing to build out the feature’s functionality for the alpha release of OpenTofu.

Through this adventure we’ve had, of learning the code of a mid-development feature and stabilizing it, we’ve gotten more familiar with the codebase and how to debug it. Beyond that, we’ve learned how to completely build the specs of a feature just by reading the code and playing around with it.

It’s also given us a new appreciation for the criticality of testing for open-source projects of this scale (both for documentation, and for making sure a feature works in the long run), and we intend to increase the coverage in the project as we go.

Of course, this is only a small example of the work put in, but it gives you an idea of how we have gone about creating something new for OpenTofu. It will not only maintain parity with past features of open source Terraform, but keep pace with newer features, and even go beyond just serving as a drop-in replacement for Terraform, developing capabilities that it can call its own.

Please check out OpenTofu version 1.6.alpha, plus our blog on getting OpenTofu started and installed.

These sessions will be held every two weeks over a Zoom. Expect to see developers and regular contributors, with a rotation of different contributors over time. To accommodate everyone, we’ll adjust the timings each session, catering to different time zones.

The next office hour is this Wednesday at 10am PT. For all future dates, subscribe to our Google calendar by clicking this link, or importing the following URL:

c_3f2dd3c1fe0ef4e93ef3fc456ca2dd219a2e8fd85f6b40750af16c3df370bf93@group.calendar.google.com

... or downloading the attached ICS file:

Over the last few weeks we received overwhelming support from people all over the world. We have also received criticism for the decisions we've been making. We are very happy to see that people care about the project so deeply that they are willing to share their feelings with us. Please keep doing that!

There's been one particular line of criticism that questions the very premise of our project, and that's the one I'd like to address in this post. It's the line of criticism that goes like this: "The license change does not affect me, so why should I care?".

It is not my intention at this point to convince you that the license change affects you now or will affect you in the future. Maybe it does, maybe it doesn't. Maybe it will, maybe it won't. I don't know, you don't know, and only the future will tell. What I will argue though is that the very existence of this project positively affects you, and that's why you should care.

Si vis pacem, para bellum or why having options is good​

During my Google days, I worked for a few years as an SRE on tape storage. We operated a significant number of large LTO libraries in many data centers across the world. The best available solution at the time came from Oracle, hands down. Their hardware was great, their software was best in class, their support was always helpful and competent. And yet we would still go to great lengths to support a much, much smaller vendor who offered at least a resemblance of an alternative.

In similar vein we used multiple vendors for each and every hardware and software component we depended on. This was a crucial step in de-risking our supply chain. This was a pragmatic thing to do on many levels - it protected us from technical failures and changing business strategies, gave us a better position in negotiations, and fostered healthy competition among suppliers we depended on.

When the news of the HashiCorp license change broke out, some folks were quick to dismiss Terraform entirely and declare their vocal support for alternatives like Pulumi. And don't get me wrong, Pulumi is a great technology, and I support them with all my heart. In fact, Spacelift was the first vendor to offer an integration with Pulumi, way before they built their Cloud offering.

And while using Pulumi for any new projects is surely a viable alternative, you probably still have thousands upon thousands of lines of Terraform that currently drive the value of your business. Rewriting all of it in Pulumi (or Crossplane, or Winglang - all great products BTW) may be lots of fun for the team but the practical utility of that for your business is limited.

In similar vein, tapes were never the only offline storage option for Google. We could have used optical (like Meta did), or slow spinning drives like what we thought Glacier did. But each of these solutions would require building new capabilities in terms of software, human expertise and processes. All of that was an order of magnitude more expensive and disruptive than just supporting multiple vendors' tape libraries.

OpenTofu promises to be compatible with legacy Terraform, promises better governance and better features than the current commercial offering. But even taking all that aside, you should still support OpenTofu (or some other viable fork if one appears) if you care about your existing investment in the Terraform ecosystem. Because having options is always better than not having options. It's a smart, mature, pragmatic approach.

Competition is good​

After our acceptance to the Linux Foundation another line of criticism appeared - that somehow OpenTofu is a "fuck capitalism" project. This could not be farther away from the truth. It's a project supported by a number of companies who often compete with HashiCorp for at least part of their business. Most of us took VC funding at one point or another, we all run sales teams, we all generate revenue and yes, we fiercely compete with one another. While obviously challenging for us, this competition is great for our customers because it keeps us on our toes, makes us innovate all the time, grows the market, drives the prices down and the quality up.

Even if you are a happy user of commercial HashiCorp products, you might want to give some credit to folks at competing companies who collectively came up with ideas and improvements in technology, process and pricing. Some of these found their way back to Terraform Cloud / Enterprise and vastly improved the user experience. If you - like me - had a chance to use TFC/TFE before the dawn of TACOs (some time around 2020) then you've probably noticed the amazing progress they've made in terms of functionality, product design and overall stability. And I'm happy to take credit for at least some of that.

The license change that prompted our response now introduced the same element of competition to the CLI layer where HashiCorp previously enjoyed its uncontested status as an obviously privileged (primus inter pares) but otherwise benevolent guardian of the ecosystem.

The outcome of this is easy to predict for anyone familiar with the basics of the market economy. At the very minimum, the incentive to further tighten the license restrictions is greatly diminished or even entirely removed. In a more optimistic scenario, the legacy product will improve, the support quality will improve, there will be quicker bug fixes, quicker PR reviews and new exciting features will flow from both sides. Suddenly the commercial vendor has a new reason to care, and we're hoping to see an increased level of effort, leading to value add for the entire community. And hopefully for HashiCorp, too, uncomfortable as it may be in the beginning. Fast forward a year or two, I will be happy to take credit for at least some of that.

And this is why you should care. Regardless of your position (or the lack thereof) on the BSL drama. Regardless of your sympathy for HashiCorp or Spacelift. Regardless of whether you stay or migrate. And regardless of whether you like tofu or not.

Working in the open​

Our goal with OpenTofu is to create a project that is truly open source, community-driven, and impartial. To that end, going forward, we'll be developing OpenTofu in the open. We had to do some work on the repo and the OpenTofu foundation in private to get everything ready for public consumption, but now that that's done, and the OpenTofu repo is publicly available, you'll be able to see everything we're working on—and start to participate yourself!

What OpenTofu currently does and doesn't support​

Currently, OpenTofu supports local testing and development: you can build the code, run the tests, build tofu binaries, and so on. That means you can now start experimenting with OpenTofu and contributing back via Issues, PRs, and RFCs.

However, a few items are not done yet, and as a result, official OpenTofu releases are not yet available. To understand what's left to do before the releases are available, let's take a look at the roadmap.

An open roadmap: the path to stable OpenTofu releases​

A key part of working in the open is making our roadmap open. So here's a quick snapshot of what we already got done, what's in progress now, and what's coming up in the future, all with the initial goal of getting to the first stable OpenTofu release (for a more detailed and up-to-date look at the roadmap, see the milestones and issues in the OpenTofu repo).

✅ What we already got done​

• Publish the OpenTofu manifesto. We published the OpenTofu manifesto at opentofu.org.
• Wait on HashiCorp's response. We reached out to HashiCorp publicly and privately and requested a response by August 25th.
• Start working on the OpenTofu fork. With no response from HashiCorp, we created the OpenTofu fork, and started working on it in private.
• Apply to join the Linux Foundation. We want OpenTofu to be part of an impartial, community-driven foundation, so we submitted all the paperwork to join the Linux Foundation.
• Open up community Slack discussions. We created the OpenTofu Community Slack to give the community a way to have discussions, provide feedback, ask questions, etc.
• Prepare the OpenTofu repo for collaboration. Rename everything to OpenTofu; pick steering committee members; define contribution guidelines; get CI / CD and testing working; etc.
• Release the OpenTofu repo. As per this announcement, we are making the OpenTofu repo public at github.com/opentofu/opentofu!

🔄 What's currently in progress​

• Create initial OpenTofu Registry. HashiCorp recently made some (unannounced) changes to the terms of the Terraform Registry, saying it may only be used with Terraform. To unblock the alpha release, we are launching an initial OpenTofu Registry. We'll develop the official OpenTofu Registry solution via an official RFC process later.
• Release process. Put in place a process for creating OpenTofu releases.
• Alpha release. Once the above items are done, we will create the first OpenTofu release. This will be an alpha release, meant for testing by the community.

⏳ What's coming soon​

• Create an official OpenTofu Registry via an RFC process. Go through an RFC process to create the official OpenTofu Registry solution (replacing the initial solution).
• Stable release. Create the first stable OpenTofu release. This is meant for production usage, as a drop in replacement for Terraform, so we'll only do this release after sufficient testing and community feedback.

Join the OpenTofu community​

The response from the community so far has been incredible. In just a few weeks, more than 130 companies and 680 individuals have pledged support to the OpenTofu manifesto, and the OpenTofu manifesto repo has gotten more than 33,000 stars! By comparison, the Terraform repo took nearly 10 years to reach 38,000 stars:

This sort of growth is unprecedented, and we're humbled by all of your support. As per the roadmap in the previous section, we're working hard on getting OpenTofu to the point where we can start doing official releases.

In the meantime, you can follow our progress at github.com/opentofu/opentofu, contribute to the project by following the contribution guidelines, and provide feedback in the OpenTofu Community Slack. We are thrilled to be working with the whole community in making OpenTofu a truly open, community-driven project!

FAQ​

Where can I find the OpenTofu repo?​

The OpenTofu repo is now available at github.com/opentofu/opentofu.

Where can I find OpenTofu releases?​

Releases are not yet available. See our open roadmap for the work remaining.

When will a stable OpenTofu release be available?​

See our open roadmap for the work remaining to get to a stable release. Contributions are very welcome!

Why is it taking so long?​

It has only been a couple weeks! And there is a lot to do, including technical, legal, process, and other changes. See our open roadmap for what we've gotten done already, what's currently in progress, and what's coming up next.

Will I be able to use OpenTofu as a drop-in replacement for legacy Terraform?​

Yes.

Will OpenTofu work with all the providers and modules Terraform works with?​

Yes.

What will be the first release of OpenTofu?​

The first release will be 1.6.0-alpha, forked from the most recent commit that was still MPL-licensed.

How can I contribute to OpenTofu?​

Please see the contribution guidelines!

The manifesto outlined the intent of the OpenTofu initiative in two steps — the first was to appeal to HashiCorp to return Terraform to the community and revert the license change they were making for this project. The second, in case the license was not reverted, was to fork the Terraform project as OpenTofu.

The time is now!​

Since no reversal has been done, and no intent to do one has been communicated, we’re proud to announce that we have created a fork of Terraform called OpenTofu. Many engineers across a number of companies, sometimes even competing companies, have been working together over the last week to make this possible. It’s been an incredible experience, really!

As outlined in our manifesto, we are keeping OpenTofu:

• Truly open source - under a well-known and widely-accepted license that companies can trust, that won't suddenly change in the future
• Community-driven - so that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit, and changes are proposed through a public RFC process
• Impartial - so that valuable features and fixes are accepted based on their value to the community, regardless of their impact on any particular vendor
• Layered and modular - with a programmer-friendly project structure to encourage building on top, enabling a new vibrant ecosystem of tools and integrations
• Backwards-compatible - so that the existing code can drive value for years to come

Becoming part of a foundation​

We completed all documents required for OpenTofu to become part of the Linux Foundation with the end goal of having OpenTofu as part of the Cloud Native Computing Foundation. By making a foundation responsible for the project, we will ensure the tool stays truly open-source and vendor-neutral.

If Terraform wasn’t open-source from the beginning, many of the tools that you are using right now for your Terraform workflows simply wouldn’t exist, thus, we believe the future for Terraform is OpenTofu, developed fully in the open.

Roadmap​

As previously outlined, we’ve been working on this fork for several days already, with over 10 engineers across multiple companies working on it.

In short, here’s the current status:

• Almost done with the repository-wide rename to OpenTofu
• Selected initial steering committee members
• Performed initial adjustments and cleanup of community documents.
• Got CI/CD pipelines and multiple testing harnesses of end-to-end and snapshot tests to work and be green, to make sure that we stay backwards-compatible.

Expect the repository to be published very soon, once we’re officially part of a foundation and have some basic community guardrails and processes in place.

You might wonder why we already started work on this project so early? It’s quite simple, really. If HashiCorp were to reverse their decision, worst case we’d just lose a week of work. But if, and that is what indeed happened, HashiCorp wasn’t to reverse their decision, we didn’t want to lose any time, so that we could have a working OpenTofu 1.6.0 release ready for you as soon as possible. And that’s why we started work on this over a week ago.

In the spirit of being as open as possible, we’ve created a public repository tracking our progress towards important milestones. You can subscribe to the issues there to be notified as soon as the fork is public. If you have any questions, feel free to create additional issues on that repository - we’ll try to respond as quickly as possible.