github.com/hugorut/terraform@v1.1.3/website/docs/language/settings/index.mdx (about) 1 --- 2 page_title: Terraform Settings - Configuration Language 3 description: >- 4 The terraform block allows you to configure Terraform behavior, including the 5 Terraform version, backend, integration with Terraform Cloud, and required 6 providers. 7 --- 8 9 # Terraform Settings 10 11 The special `terraform` configuration block type is used to configure some 12 behaviors of Terraform itself, such as requiring a minimum Terraform version to 13 apply your configuration. 14 15 ## Terraform Block Syntax 16 17 Terraform settings are gathered together into `terraform` blocks: 18 19 ```hcl 20 terraform { 21 # ... 22 } 23 ``` 24 25 Each `terraform` block can contain a number of settings related to Terraform's 26 behavior. Within a `terraform` block, only constant values can be used; 27 arguments may not refer to named objects such as resources, input variables, 28 etc, and may not use any of the Terraform language built-in functions. 29 30 The various options supported within a `terraform` block are described in the 31 following sections. 32 33 ## Configuring Terraform Cloud 34 35 The nested `cloud` block configures Terraform Cloud for enabling its 36 [CLI-driven run workflow](/cloud-docs/run/cli). 37 38 - Refer to [Terraform Cloud Configuration](/language/settings/terraform-cloud) for a summary of the `cloud` block's syntax. 39 40 - Refer to [Using Terraform Cloud](/cli/cloud) in the 41 Terraform CLI documentation for complete details about how to initialize and configure the Terraform Cloud CLI integration. 42 43 ## Configuring a Terraform Backend 44 45 The nested `backend` block configures which state backend Terraform should use. 46 47 The syntax and behavior of the `backend` block is described in [Backend 48 Configuration](/language/settings/backends/configuration). 49 50 ## Specifying a Required Terraform Version 51 52 > **Hands-on:** Try the [Manage Terraform Versions](https://learn.hashicorp.com/tutorials/terraform/versions?in=terraform/configuration-language) or [Manage Terraform Versions in Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-versions?in=terraform/cloud) tutorials on HashiCorp Learn. 53 54 The `required_version` setting accepts a [version constraint 55 string,](/language/expressions/version-constraints) which specifies which versions of Terraform 56 can be used with your configuration. 57 58 If the running version of Terraform doesn't match the constraints specified, 59 Terraform will produce an error and exit without taking any further actions. 60 61 When you use [child modules](/language/modules), each module can specify its own 62 version requirements. The requirements of all modules in the tree must be 63 satisfied. 64 65 Use Terraform version constraints in a collaborative environment to 66 ensure that everyone is using a specific Terraform version, or using at least 67 a minimum Terraform version that has behavior expected by the configuration. 68 69 The `required_version` setting applies only to the version of Terraform CLI. 70 Terraform's resource types are implemented by provider plugins, 71 whose release cycles are independent of Terraform CLI and of each other. 72 Use [the `required_providers` block](/language/providers/requirements) to manage 73 the expected versions for each provider you use. 74 75 ## Specifying Provider Requirements 76 77 [inpage-source]: #specifying-provider-requirements 78 79 The `required_providers` block specifies all of the providers required by the 80 current module, mapping each local provider name to a source address and a 81 version constraint. 82 83 ```hcl 84 terraform { 85 required_providers { 86 aws = { 87 version = ">= 2.7.0" 88 source = "hashicorp/aws" 89 } 90 } 91 } 92 ``` 93 94 For more information, see [Provider Requirements](/language/providers/requirements). 95 96 ## Experimental Language Features 97 98 The Terraform team will sometimes introduce new language features initially via 99 an opt-in experiment, so that the community can try the new feature and give 100 feedback on it prior to it becoming a backward-compatibility constraint. 101 102 In releases where experimental features are available, you can enable them on 103 a per-module basis by setting the `experiments` argument inside a `terraform` 104 block: 105 106 ```hcl 107 terraform { 108 experiments = [example] 109 } 110 ``` 111 112 The above would opt in to an experiment named `example`, assuming such an 113 experiment were available in the current Terraform version. 114 115 Experiments are subject to arbitrary changes in later releases and, depending on 116 the outcome of the experiment, may change drastically before final release or 117 may not be released in stable form at all. Such breaking changes may appear 118 even in minor and patch releases. We do not recommend using experimental 119 features in Terraform modules intended for production use. 120 121 In order to make that explicit and to avoid module callers inadvertently 122 depending on an experimental feature, any module with experiments enabled will 123 generate a warning on every `terraform plan` or `terraform apply`. If you 124 want to try experimental features in a shared module, we recommend enabling the 125 experiment only in alpha or beta releases of the module. 126 127 The introduction and completion of experiments is reported in 128 [Terraform's changelog](https://github.com/hugorut/terraform/blob/main/CHANGELOG.md), 129 so you can watch the release notes there to discover which experiment keywords, 130 if any, are available in a particular Terraform release. 131 132 ## Passing Metadata to Providers 133 134 The `terraform` block can have a nested `provider_meta` block for each 135 provider a module is using, if the provider defines a schema for it. This 136 allows the provider to receive module-specific information, and is primarily 137 intended for modules distributed by the same vendor as the associated provider. 138 139 For more information, see [Provider Metadata](/internals/provider-meta).