OpenTF Settings

The special opentf configuration block type is used to configure some behaviors of OpenTF itself, such as requiring a minimum OpenTF version to apply your configuration.

OpenTF Block Syntax​

OpenTF settings are gathered together into opentf blocks:

terraform {
  # ...
}

Each opentf block can contain a number of settings related to OpenTF's behavior. Within a opentf block, only constant values can be used; arguments may not refer to named objects such as resources, input variables, etc, and may not use any of the OpenTF language built-in functions.

The various options supported within a opentf block are described in the following sections.

Configuring an OpenTF Backend​

The nested backend block configures which state backend OpenTF should use.

The syntax and behavior of the backend block is described in Backend Configuration.

Specifying a Required OpenTF Version​

The required_version setting accepts a version constraint string, which specifies which versions of OpenTF can be used with your configuration.

If the running version of OpenTF doesn't match the constraints specified, OpenTF will produce an error and exit without taking any further actions.

When you use child modules, each module can specify its own version requirements. The requirements of all modules in the tree must be satisfied.

Use OpenTF version constraints in a collaborative environment to ensure that everyone is using a specific OpenTF version, or using at least a minimum OpenTF version that has behavior expected by the configuration.

The required_version setting applies only to the version of OpenTF CLI. OpenTF's resource types are implemented by provider plugins, whose release cycles are independent of OpenTF CLI and of each other. Use the required_providers block to manage the expected versions for each provider you use.

Specifying Provider Requirements​

The required_providers block specifies all of the providers required by the current module, mapping each local provider name to a source address and a version constraint.

terraform {
  required_providers {
    aws = {
      version = ">= 2.7.0"
      source = "hashicorp/aws"
    }
  }
}

For more information, see Provider Requirements.

Experimental Language Features​

The OpenTF team will sometimes introduce new language features initially via an opt-in experiment, so that the community can try the new feature and give feedback on it prior to it becoming a backward-compatibility constraint.

In releases where experimental features are available, you can enable them on a per-module basis by setting the experiments argument inside a opentf block:

terraform {
  experiments = [example]
}

The above would opt in to an experiment named example, assuming such an experiment were available in the current OpenTF version.

Experiments are subject to arbitrary changes in later releases and, depending on the outcome of the experiment, may change drastically before final release or may not be released in stable form at all. Such breaking changes may appear even in minor and patch releases. We do not recommend using experimental features in OpenTF modules intended for production use.

In order to make that explicit and to avoid module callers inadvertently depending on an experimental feature, any module with experiments enabled will generate a warning on every opentf plan or opentf apply. If you want to try experimental features in a shared module, we recommend enabling the experiment only in alpha or beta releases of the module.

The introduction and completion of experiments is reported in OpenTF's changelog, so you can watch the release notes there to discover which experiment keywords, if any, are available in a particular OpenTF release.

Passing Metadata to Providers​

The opentf block can have a nested provider_meta block for each provider a module is using, if the provider defines a schema for it. This allows the provider to receive module-specific information, and is primarily intended for modules distributed by the same vendor as the associated provider.

For more information, see Provider Metadata.