Merge pull request #27560 from hashicorp/jan21_language_and_cli_urls

website: Update language and CLI docs URLs

README.md

@@ -36,7 +36,7 @@ Show off your Terraform knowledge by passing a certification exam. Visit the [ce
 Developing Terraform
 --------------------
 
-This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins that each have their own repository in [the `terraform-providers` organization](https://github.com/terraform-providers) on GitHub. Instructions for developing each provider are in the associated README file. For more information, see [the provider development overview](https://www.terraform.io/docs/plugins/provider.html).
+This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins, and Terraform can automatically download providers that are published on [the Terraform Registry](https://registry.terraform.io). HashiCorp develops some providers, and others are developed by other organizations. For more information, see [Extending Terraform](https://www.terraform.io/docs/extend/index.html).
 
 To learn more about compiling Terraform and contributing suggested changes, please refer to [the contributing guide](.github/CONTRIBUTING.md).
 

backend/remote-state/s3/backend.go

@@ -327,7 +327,7 @@ func (b *Backend) configure(ctx context.Context) error {
 		AssumeRoleExternalID:      data.Get("external_id").(string),
 		AssumeRolePolicy:          data.Get("assume_role_policy").(string),
 		AssumeRoleSessionName:     data.Get("session_name").(string),
-		CallerDocumentationURL:    "https://www.terraform.io/docs/backends/types/s3.html",
+		CallerDocumentationURL:    "https://www.terraform.io/docs/language/settings/backends/s3.html",
 		CallerName:                "S3 Backend",
 		CredsFilename:             data.Get("shared_credentials_file").(string),
 		DebugLogging:              logging.IsDebugOrHigher(),

command/import.go

@@ -343,7 +343,7 @@ func (c *ImportCommand) Synopsis() string {
 }
 
 const importCommandInvalidAddressReference = `For information on valid syntax, see:
-https://www.terraform.io/docs/internals/resource-addressing.html`
+https://www.terraform.io/docs/cli/state/resource-addressing.html`
 
 const importCommandMissingResourceFmt = `[reset][bold][red]Error:[reset][bold] resource address %q does not exist in the configuration.[reset]
 

command/init.go

@@ -714,7 +714,7 @@ func (c *InitCommand) getProviders(config *configs.Config, state *states.State,
 			if thirdPartySigned {
 				c.Ui.Info(fmt.Sprintf("\nPartner and community providers are signed by their developers.\n" +
 					"If you'd like to know more about provider signing, you can read about it here:\n" +
-					"https://www.terraform.io/docs/plugins/signing.html"))
+					"https://www.terraform.io/docs/cli/plugins/signing.html"))
 			}
 		},
 		HashPackageFailure: func(provider addrs.Provider, version getproviders.Version, err error) {
@@ -968,7 +968,7 @@ Options:
   -no-color            If specified, output won't contain any color.
 
   -plugin-dir          Directory containing plugin binaries. This overrides all
-                       default search paths for plugins, and prevents the 
+                       default search paths for plugins, and prevents the
                        automatic installation of plugins. This flag can be used
                        multiple times.
 

command/testdata/013upgrade-implicit-not-found/expected/versions.tf

@@ -10,7 +10,7 @@ terraform {
       #
       # For more information, see the provider source documentation:
       #
-      # https://www.terraform.io/docs/configuration/providers.html#provider-source
+      # https://www.terraform.io/docs/language/providers/requirements.html
     }
   }
   required_version = ">= 0.13"

command/testdata/013upgrade-provider-not-found/expected/main.tf

@@ -16,7 +16,7 @@ terraform {
       #
       # For more information, see the provider source documentation:
       #
-      # https://www.terraform.io/docs/configuration/providers.html#provider-source
+      # https://www.terraform.io/docs/language/providers/requirements.html
       version = "~> 2.0.0"
     }
     foo = {

commands.go

@@ -103,7 +103,7 @@ func initCommands(
 
 	// The command list is included in the terraform -help
 	// output, which is in turn included in the docs at
-	// website/docs/commands/index.html.markdown; if you
+	// website/docs/cli/commands/index.html.markdown; if you
 	// add, remove or reclassify commands then consider updating
 	// that to match.
 

docs/README.md

@@ -4,7 +4,7 @@ This directory contains some documentation about the Terraform Core codebase,
 aimed at readers who are interested in making code contributions.
 
 If you're looking for information on _using_ Terraform, please instead refer
-to [the main Terraform CLI documentation](https://www.terraform.io/docs/cli-index.html).
+to [the main Terraform CLI documentation](https://www.terraform.io/docs/cli/index.html).
 
 ## Terraform Core Architecture Documents
 

help.go

@@ -41,7 +41,7 @@ func helpFunc(commands map[string]cli.CommandFactory) string {
 	sort.Strings(otherCommands)
 
 	// The output produced by this is included in the docs at
-	// website/source/docs/commands/index.html.markdown; if you
+	// website/source/docs/cli/commands/index.html.markdown; if you
 	// change this then consider updating that to match.
 	helpText := fmt.Sprintf(`
 Usage: terraform [global options] <subcommand> [args]

internal/legacy/terraform/resource_address.go

@@ -92,7 +92,7 @@ func (r *ResourceAddress) String() string {
 
 // HasResourceSpec returns true if the address has a resource spec, as
 // defined in the documentation:
-//    https://www.terraform.io/docs/internals/resource-addressing.html
+//    https://www.terraform.io/docs/cli/state/resource-addressing.html
 // In particular, this returns false if the address contains only
 // a module path, thus addressing the entire module.
 func (r *ResourceAddress) HasResourceSpec() bool {

website/docs/backends/config.html.md

@@ -1,147 +0,0 @@
----
-layout: "language"
-page_title: "Backends: Configuration"
-sidebar_current: "docs-backends-config"
-description: |-
-  Backends are configured directly in Terraform files in the `terraform` section.
----
-
-# Backend Configuration
-
-Backends are configured directly in Terraform files in the `terraform`
-section. After configuring a backend, it has to be
-[initialized](/docs/backends/init.html).
-
-Below, we show a complete example configuring the "consul" backend:
-
-```hcl
-terraform {
-  backend "consul" {
-    address = "demo.consul.io"
-    scheme  = "https"
-    path    = "example_app/terraform_state"
-  }
-}
-```
-
-You specify the backend type as a key to the `backend` stanza. Within the
-stanza are backend-specific configuration keys. The list of supported backends
-and their configuration details can be found [here](/docs/backends/types/index.html).
-
-Only one backend may be specified and the configuration **may not contain
-interpolations**. Terraform will validate this.
-
-## First Time Configuration
-
-When configuring a backend for the first time (moving from no defined backend
-to explicitly configuring one), Terraform will give you the option to migrate
-your state to the new backend. This lets you adopt backends without losing
-any existing state.
-
-To be extra careful, we always recommend manually backing up your state
-as well. You can do this by simply copying your `terraform.tfstate` file
-to another location. The initialization process should create a backup
-as well, but it never hurts to be safe!
-
-Configuring a backend for the first time is no different than changing
-a configuration in the future: create the new configuration and run
-`terraform init`. Terraform will guide you the rest of the way.
-
-## Partial Configuration
-
-You do not need to specify every required argument in the backend configuration.
-Omitting certain arguments may be desirable to avoid storing secrets, such as
-access keys, within the main configuration. When some or all of the arguments
-are omitted, we call this a _partial configuration_.
-
-With a partial configuration, the remaining configuration arguments must be
-provided as part of
-[the initialization process](/docs/backends/init.html#backend-initialization).
-There are several ways to supply the remaining arguments:
-
-  * **Interactively**: Terraform will interactively ask you for the required
-    values, unless interactive input is disabled. Terraform will not prompt for
-    optional values.
-
-  * **File**: A [backend configuration file](#backend-configuration-file) may be specified via the
-    `init` command line. To specify a file, use the `-backend-config=PATH`
-    option when running `terraform init`. If the file contains secrets it may be
-    kept in a secure data store, such as [Vault](https://www.vaultproject.io/),
-    in which case it must be downloaded to the local disk before running
-    Terraform.
-
-  * **Command-line key/value pairs**: Key/value pairs can be specified via the
-    `init` command line. Note that many shells retain command-line flags in a
-    history file, so this isn't recommended for secrets. To specify a single
-    key/value pair, use the `-backend-config="KEY=VALUE"` option when running
-    `terraform init`.
-
-If backend settings are provided in multiple locations, the top-level
-settings are merged such that any command-line options override the settings
-in the main configuration and then the command-line options are processed
-in order, with later options overriding values set by earlier options.
-
-The final, merged configuration is stored on disk in the `.terraform`
-directory, which should be ignored from version control. This means that
-sensitive information can be omitted from version control, but it will be
-present in plain text on local disk when running Terraform.
-
-When using partial configuration, Terraform requires at a minimum that
-an empty backend configuration is specified in one of the root Terraform
-configuration files, to specify the backend type. For example:
-
-```hcl
-terraform {
-  backend "consul" {}
-}
-```
-
-## Backend Configuration File
-A backend configuration file has the contents of the `backend` block as
-top-level attributes, without the need to wrap it in another `terraform`
-or `backend` block:
-
-```hcl
-address = "demo.consul.io"
-path    = "example_app/terraform_state"
-scheme  = "https"
-```
-
-The same settings can alternatively be specified on the command line as
-follows:
-
-```
-$ terraform init \
-    -backend-config="address=demo.consul.io" \
-    -backend-config="path=example_app/terraform_state" \
-    -backend-config="scheme=https"
-```
-
-## Changing Configuration
-
-You can change your backend configuration at any time. You can change
-both the configuration itself as well as the type of backend (for example
-from "consul" to "s3").
-
-Terraform will automatically detect any changes in your configuration
-and request a [reinitialization](/docs/backends/init.html). As part of
-the reinitialization process, Terraform will ask if you'd like to migrate
-your existing state to the new configuration. This allows you to easily
-switch from one backend to another.
-
-If you're using multiple [workspaces](/docs/state/workspaces.html),
-Terraform can copy all workspaces to the destination. If Terraform detects
-you have multiple workspaces, it will ask if this is what you want to do.
-
-If you're just reconfiguring the same backend, Terraform will still ask if you
-want to migrate your state. You can respond "no" in this scenario.
-
-## Unconfiguring a Backend
-
-If you no longer want to use any backend, you can simply remove the
-configuration from the file. Terraform will detect this like any other
-change and prompt you to [reinitialize](/docs/backends/init.html).
-
-As part of the reinitialization, Terraform will ask if you'd like to migrate
-your state back down to normal local state. Once this is complete then
-Terraform is back to behaving as it does by default.

website/docs/backends/index.html.md

@@ -1,45 +0,0 @@
----
-layout: "language"
-page_title: "Backends"
-sidebar_current: "docs-backends-index"
-description: |-
-  A "backend" in Terraform determines how state is loaded and how an operation such as `apply` is executed. This abstraction enables non-local file state storage, remote execution, etc.
----
-
-# Backends
-
-A "backend" in Terraform determines how state is loaded and how an operation
-such as `apply` is executed. This abstraction enables non-local file state
-storage, remote execution, etc.
-
-By default, Terraform uses the "local" backend, which is the normal behavior
-of Terraform you're used to. This is the backend that was being invoked
-throughout the [introduction](/intro/index.html).
-
-Here are some of the benefits of backends:
-
-  * **Working in a team**: Backends can store their state remotely and
-    protect that state with locks to prevent corruption. Some backends
-    such as Terraform Cloud even automatically store a history of
-    all state revisions.
-
-  * **Keeping sensitive information off disk**: State is retrieved from
-    backends on demand and only stored in memory. If you're using a backend
-    such as Amazon S3, the only location the state ever is persisted is in
-    S3.
-
-  * **Remote operations**: For larger infrastructures or certain changes,
-    `terraform apply` can take a long, long time. Some backends support
-    remote operations which enable the operation to execute remotely. You can
-    then turn off your computer and your operation will still complete. Paired
-    with remote state storage and locking above, this also helps in team
-    environments.
-
-**Backends are completely optional**. You can successfully use Terraform without
-ever having to learn or use backends. However, they do solve pain points that
-afflict teams at a certain scale. If you're an individual, you can likely
-get away with never using backends.
-
-Even if you only intend to use the "local" backend, it may be useful to
-learn about backends since you can also change the behavior of the local
-backend.

website/docs/backends/init.html.md

@@ -1,31 +0,0 @@
----
-layout: "language"
-page_title: "Backends: Init"
-sidebar_current: "docs-backends-init"
-description: |-
-  Terraform must initialize any configured backend before use. This can be done by simply running `terraform init`.
----
-
-# Backend Initialization
-
-Terraform must initialize any configured backend before use. This can be
-done by simply running `terraform init`.
-
-The `terraform init` command should be run by any member of your team on
-any Terraform configuration as a first step. It is safe to execute multiple
-times and performs all the setup actions required for a Terraform environment,
-including initializing the backend.
-
-The `init` command must be called:
-
-  * On any new environment that configures a backend
-  * On any change of the backend configuration (including type of backend)
-  * On removing backend configuration completely
-
-You don't need to remember these exact cases. Terraform will detect when
-initialization is required and error in that situation. Terraform doesn't
-auto-initialize because it may require additional information from the user,
-perform state migrations, etc.
-
-The `init` command will do more than just initialize the backend. Please see
-the [init documentation](/docs/commands/init.html) for more information.

website/docs/backends/operations.html.md

@@ -1,32 +0,0 @@
----
-layout: "language"
-page_title: "Backends: Remote Operations (plan, apply, etc.)"
-sidebar_current: "docs-backends-operations"
-description: |-
-  Some backends support the ability to run operations (`refresh`, `plan`, `apply`, etc.) remotely. Terraform will continue to look and behave as if they're running locally while they in fact run on a remote machine.
----
-
-# Remote Operations (plan, apply, etc.)
-
-Most backends run all operations on the local system — although Terraform stores
-its state remotely with these backends, it still executes its logic locally and
-makes API requests directly from the system where it was invoked.
-
-This is simple to understand and work with, but when many people are
-collaborating on the same Terraform configurations, it requires everyone's
-execution environment to be similar. This includes sharing access to
-infrastructure provider credentials, keeping Terraform versions in sync,
-keeping Terraform variables in sync, and installing any extra software required
-by Terraform providers. This becomes more burdensome as teams get larger.
-
-Some backends can run operations (`plan`, `apply`, etc.) on a remote machine,
-while appearing to execute locally. This enables a more consistent execution
-environment and more powerful access controls, without disrupting workflows
-for users who are already comfortable with running Terraform.
-
-Currently, [the `remote` backend](./types/remote.html) is the only backend to
-support remote operations, and [Terraform Cloud](/docs/cloud/index.html)
-is the only remote execution environment that supports it. For more information, see:
-
-- [The `remote` backend](./types/remote.html)
-- [Terraform Cloud's CLI-driven run workflow](/docs/cloud/run/cli.html)

website/docs/backends/types/index.html.md

@@ -1,25 +0,0 @@
----
-layout: "language"
-page_title: "Backend: Supported Backend Types"
-sidebar_current: "docs-backends-types-index"
-description: |-
-  Terraform can store the state remotely, making it easier to version and work with in a team.
----
-
-# Backend Types
-
-This section documents the various backend types supported by Terraform.
-If you're not familiar with backends, please
-[read the sections about backends](/docs/backends/index.html) first.
-
-Backends may support differing levels of features in Terraform. We differentiate
-these by calling a backend either **standard** or **enhanced**. All backends
-must implement **standard** functionality. These are defined below:
-
-  * **Standard**: State management, functionality covered in
-    [State Storage & Locking](/docs/backends/state.html)
-
-  * **Enhanced**: Everything in standard plus
-    [remote operations](/docs/backends/operations.html).
-
-The backends are separated in the left by standard and enhanced.

website/docs/cli/auth/index.html.md

@@ -25,5 +25,5 @@ Terraform Cloud user account.
 
 For details, see:
 
-- [The `terraform login` command](/docs/commands/login.html)
-- [The `terraform logout` command](/docs/commands/logout.html)
+- [The `terraform login` command](/docs/cli/commands/login.html)
+- [The `terraform logout` command](/docs/cli/commands/logout.html)

website/docs/cli/code/index.html.md

@@ -5,7 +5,7 @@ page_title: "Writing and Modifying Code - Terraform CLI"
 
 # Writing and Modifying Terraform Code
 
-The [Terraform language](/docs/configuration/index.html) is Terraform's primary
+The [Terraform language](/docs/language/index.html) is Terraform's primary
 user interface, and all of Terraform's workflows rely on configurations written
 in the Terraform language.
 
@@ -13,18 +13,18 @@ Terraform CLI includes several commands to make Terraform code more convenient
 to work with. Integrating these commands into your editing workflow can
 potentially save you time and effort.
 
-- [The `terraform console` command](/docs/commands/console.html) starts an
+- [The `terraform console` command](/docs/cli/commands/console.html) starts an
   interactive shell for evaluating Terraform
-  [expressions](/docs/configuration/expressions/index.html), which can be a faster way
+  [expressions](/docs/language/expressions/index.html), which can be a faster way
   to verify that a particular resource argument results in the value you expect.
 
 
-- [The `terraform fmt` command](/docs/commands/fmt.html) rewrites Terraform
+- [The `terraform fmt` command](/docs/cli/commands/fmt.html) rewrites Terraform
   configuration files to a canonical format and style, so you don't have to
   waste time making minor adjustments for readability and consistency. It works
   well as a pre-commit hook in your version control system.
 
-- [The `terraform validate` command](/docs/commands/validate.html) validates the
+- [The `terraform validate` command](/docs/cli/commands/validate.html) validates the
   syntax and arguments of the Terraform configuration files in a directory,
   including argument and attribute names and types for resources and modules.
   The `plan` and `apply` commands automatically validate a configuration before
@@ -32,8 +32,8 @@ potentially save you time and effort.
   workflow, but it can be very useful as a pre-commit hook or as part of a
   continuous integration pipeline.
 
-- [The `0.13upgrade` command](/docs/commands/0.13upgrade.html) and
-  [the `0.12upgrade` command](/docs/commands/0.12upgrade.html) can automatically
+- [The `0.13upgrade` command](/docs/cli/commands/0.13upgrade.html) and
+  [the `0.12upgrade` command](/docs/cli/commands/0.12upgrade.html) can automatically
   modify the configuration files in a Terraform module to help deal with major
   syntax changes that occurred in the 0.13 and 0.12 releases of Terraform. Both
   of these commands are only available in the Terraform version they are

website/docs/cli/commands/0.12upgrade.html.md

@@ -71,13 +71,13 @@ the change.
 Once upgraded the configuration will no longer be compatible with Terraform
 v0.11 and earlier. When upgrading a shared module that is called from multiple
 configurations, you may need to
-[fix existing configurations to a previous version](/docs/configuration/blocks/modules/syntax.html#version)
+[fix existing configurations to a previous version](/docs/language/modules/syntax.html#version)
 to allow for a gradual upgrade. If the module is published via
 [a Terraform registry](/docs/registry/), assign a new _major_ version number
 to the upgraded module source to represent the fact that this is a breaking
 change for v0.11 callers. If a module is installed directly from a version
 control system such as Git,
-[use specific revisions](https://www.terraform.io/docs/modules/sources.html#selecting-a-revision)
+[use specific revisions](https://www.terraform.io/docs/language/modules/sources.html#selecting-a-revision)
 to control which version is used by which caller.
 
 The command-line options are all optional. The available options are:

website/docs/cli/commands/0.13upgrade.html.md

@@ -23,7 +23,7 @@ providers are in use for a module, detect the source address for those
 providers where possible, and record this information in a
 [`required_providers` block][required-providers].
 
-[required-providers]: /docs/configuration/provider-requirements.html
+[required-providers]: /docs/language/providers/requirements.html
 
 ~> Note: the command ignores `.tf.json` files and override files in the module.
 

website/docs/cli/commands/apply.html.md

@@ -56,27 +56,27 @@ The command-line flags are all optional. The list of available flags are:
   apply.
 
 * `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used. This setting
+  Ignored when [remote state](/docs/language/state/remote.html) is used. This setting
   does not persist and other commands, such as init, may not be aware of the
   alternate statefile. To configure an alternate statefile path which is
-  available to all terraform commands, use the [local backend](/docs/backends/types/local.html).
+  available to all terraform commands, use the [local backend](/docs/language/settings/backends/local.html).
 
 * `-state-out=path` - Path to write updated state file. By default, the
   `-state` path will be used. Ignored when
-  [remote state](/docs/state/remote.html) is used.
+  [remote state](/docs/language/state/remote.html) is used.
 
 * `-target=resource` - A [Resource
-  Address](/docs/internals/resource-addressing.html) to target. For more
+  Address](/docs/cli/state/resource-addressing.html) to target. For more
   information, see
-  [the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
+  [the targeting docs from `terraform plan`](/docs/cli/commands/plan.html#resource-targeting).
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [literal expressions](/docs/configuration/expressions/types.html) in the
+  [literal expressions](/docs/language/expressions/types.html) in the
   Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
+  a [variable file](/docs/language/values/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files
@@ -100,6 +100,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
+[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/cli/commands/console.html.md

@@ -10,27 +10,27 @@ description: |-
 # Command: console
 
 The `terraform console` command provides an interactive console for
-evaluating [expressions](/docs/configuration/expressions/index.html).
+evaluating [expressions](/docs/language/expressions/index.html).
 
 ## Usage
 
 Usage: `terraform console [options]`
 
 This command provides an interactive command-line console for evaluating and
-experimenting with [expressions](/docs/configuration/expressions/index.html).
+experimenting with [expressions](/docs/language/expressions/index.html).
 This is useful for testing interpolations before using them in configurations,
 and for interacting with any values currently saved in
-[state](/docs/state/index.html).
+[state](/docs/language/state/index.html).
 
 If the current state is empty or has not yet been created, the console can be
 used to experiment with the expression syntax and
-[built-in functions](/docs/configuration/functions.html).
+[built-in functions](/docs/language/functions/index.html).
 
 The supported options are:
 
 * `-state=path` - Path to a local state file. Expressions will be evaluated
   using values from this state file. If not specified, the state associated
-  with the current [workspace](/docs/state/workspaces.html) is used.
+  with the current [workspace](/docs/language/state/workspaces.html) is used.
 
 You can close the console with the `exit` command or by pressing Control-C
 or Control-D.
@@ -50,6 +50,6 @@ $ echo "1 + 5" | terraform console
 
 ## Remote State
 
-If [remote state](/docs/state/remote.html) is used by the current backend,
+If [remote state](/docs/language/state/remote.html) is used by the current backend,
 Terraform will read the state for the current workspace from the backend
 before evaluating any expressions.

website/docs/cli/commands/destroy.html.md

@@ -19,13 +19,13 @@ Infrastructure managed by Terraform will be destroyed. This will ask for
 confirmation before destroying.
 
 This command accepts all the arguments and options that the [apply
-command](/docs/commands/apply.html) accepts, with the exception of a plan file
+command](/docs/cli/commands/apply.html) accepts, with the exception of a plan file
 argument.
 
 If `-auto-approve` is set, then the destroy confirmation will not be shown.
 
 The `-target` flag, instead of affecting "dependencies" will instead also
-destroy any resources that _depend on_ the target(s) specified. For more information, see [the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
+destroy any resources that _depend on_ the target(s) specified. For more information, see [the targeting docs from `terraform plan`](/docs/cli/commands/plan.html#resource-targeting).
 
 The behavior of any `terraform destroy` command can be previewed at any time
 with an equivalent `terraform plan -destroy` command.

website/docs/cli/commands/env.html.md

@@ -9,5 +9,5 @@ description: |-
 # Command: env
 
 The `terraform env` command is deprecated.
-[The `terraform workspace` command](/docs/commands/workspace/)
+[The `terraform workspace` command](/docs/cli/commands/workspace/index.html)
 should be used instead.

website/docs/cli/commands/fmt.html.md

@@ -10,7 +10,7 @@ description: |-
 
 The `terraform fmt` command is used to rewrite Terraform configuration files
 to a canonical format and style. This command applies a subset of
-the [Terraform language style conventions](/docs/configuration/style.html),
+the [Terraform language style conventions](/docs/language/syntax/style.html),
 along with other minor adjustments for readability.
 
 Other Terraform commands that generate Terraform configuration will produce

website/docs/cli/commands/get.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: get
 
 The `terraform get` command is used to download and update
-[modules](/docs/modules/index.html) mentioned in the root module.
+[modules](/docs/language/modules/develop/index.html) mentioned in the root module.
 
 ## Usage
 

website/docs/cli/commands/import.html.md

@@ -11,7 +11,7 @@ description: |-
 > **Hands-on:** Try the [Import Terraform Configuration](https://learn.hashicorp.com/tutorials/terraform/state-import?in=terraform/state&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn.
 
 The `terraform import` command is used to
-[import existing resources](/docs/import/index.html)
+[import existing resources](/docs/cli/import/index.html)
 into Terraform.
 
 ## Usage
@@ -21,7 +21,7 @@ Usage: `terraform import [options] ADDRESS ID`
 Import will find the existing resource from ID and import it into your Terraform
 state at the given ADDRESS.
 
-ADDRESS must be a valid [resource address](/docs/internals/resource-addressing.html).
+ADDRESS must be a valid [resource address](/docs/cli/state/resource-addressing.html).
 Because any resource address is valid, the import command can import resources
 into modules as well as directly into the root of your state.
 
@@ -37,7 +37,7 @@ itself having created all objects. If you import existing objects into Terraform
 be careful to import each remote object to only one Terraform resource address.
 If you import the same object multiple times, Terraform may exhibit unwanted
 behavior. For more information on this assumption, see
-[the State section](/docs/state/).
+[the State section](/docs/language/state/index.html).
 
 The command-line flags are all optional. The list of available flags are:
 
@@ -75,12 +75,12 @@ in the configuration for the target resource, and that is the best behavior in m
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [literal expressions](/docs/configuration/expressions/types.html) in the
+  [literal expressions](/docs/language/expressions/types.html) in the
   Terraform language, so list and map values can be specified via this flag.
   This is only useful with the `-config` flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
+  a [variable file](/docs/language/values/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files
@@ -139,7 +139,7 @@ $ terraform import module.foo.aws_instance.bar i-abcd1234
 ## Example: Import into Resource configured with count
 
 The example below will import an AWS instance into the first instance of the `aws_instance` resource named `baz` configured with
-[`count`](/docs/configuration/meta-arguments/count.html):
+[`count`](/docs/language/meta-arguments/count.html):
 
 ```shell
 $ terraform import 'aws_instance.baz[0]' i-abcd1234
@@ -148,7 +148,7 @@ $ terraform import 'aws_instance.baz[0]' i-abcd1234
 ## Example: Import into Resource configured with for_each
 
 The example below will import an AWS instance into the `"example"` instance of the `aws_instance` resource named `baz` configured with
-[`for_each`](/docs/configuration/meta-arguments/for_each.html):
+[`for_each`](/docs/language/meta-arguments/for_each.html):
 
 Linux, Mac OS, and UNIX:
 

website/docs/cli/commands/index.html.md

@@ -101,7 +101,7 @@ will be read or written in the given directory instead.
 There are two exceptions where Terraform will use the original working directory
 even when you specify `-chdir=...`:
 
-* Settings in the [CLI Configuration](cli-config.html) are not for a specific
+* Settings in the [CLI Configuration](/docs/cli/config/config-file.html) are not for a specific
   subcommand and Terraform processes them before acting on the `-chdir`
   option.
 
@@ -154,7 +154,7 @@ Checkpoint itself can be entirely disabled for all HashiCorp products by
 setting the environment variable `CHECKPOINT_DISABLE` to any non-empty value.
 
 Alternatively, settings in
-[the CLI configuration file](/docs/commands/cli-config.html) can be used to
+[the CLI configuration file](/docs/cli/config/config-file.html) can be used to
 disable checkpoint features. The following checkpoint-related settings are
 supported in this file:
 

website/docs/cli/commands/init.html.md

@@ -75,7 +75,7 @@ activating credentials) before running `terraform init`.
 ## Backend Initialization
 
 During init, the root configuration directory is consulted for
-[backend configuration](/docs/backends/config.html) and the chosen backend
+[backend configuration](/docs/language/settings/backends/configuration.html) and the chosen backend
 is initialized using the given configuration settings.
 
 Re-running init with an already-initialized backend will update the working
@@ -91,14 +91,14 @@ when the working directory was already previously initialized for a particular
 backend.
 
 The `-backend-config=...` option can be used for
-[partial backend configuration](/docs/backends/config.html#partial-configuration),
+[partial backend configuration](/docs/language/settings/backends/configuration.html#partial-configuration),
 in situations where the backend settings are dynamic or sensitive and so cannot
 be statically specified in the configuration file.
 
 ## Child Module Installation
 
 During init, the configuration is searched for `module` blocks, and the source
-code for referenced [modules](/docs/modules/) is retrieved from the locations
+code for referenced [modules](/docs/language/modules/develop/index.html) is retrieved from the locations
 given in their `source` arguments.
 
 Re-running init with modules already installed will install the sources for
@@ -123,13 +123,13 @@ third-party provider registry, `terraform init` will automatically find,
 download, and install the necessary provider plugins. If you cannot or do not
 wish to install providers from their origin registries, you can customize how
 Terraform installs providers using
-[the provider installation settings in the CLI configuration](./cli-config.html#provider-installation).
+[the provider installation settings in the CLI configuration](/docs/cli/config/config-file.html#provider-installation).
 
 For more information about specifying which providers are required for each
-of your modules, see [Provider Requirements](/docs/configuration/provider-requirements.html).
+of your modules, see [Provider Requirements](/docs/language/providers/requirements.html).
 
 After successful installation, Terraform writes information about the selected
-providers to [the dependency lock file](/docs/configuration/dependency-lock.html).
+providers to [the dependency lock file](/docs/language/dependency-lock.html).
 You should commit this file to your version control system to ensure that
 when you run `terraform init` again in future Terraform will select exactly
 the same provider versions. Use the `-upgrade` option if you want Terraform
@@ -145,15 +145,15 @@ You can modify `terraform init`'s plugin behavior with the following options:
 - `-get-plugins=false` — Skip plugin installation.
 
     -> Note: Since Terraform 0.13, this option has been superseded by the
-    [`provider_installation`](./cli-config.html#provider-installation) and
-    [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) settings.
+    [`provider_installation`](/docs/cli/config/config-file.html#provider-installation) and
+    [`plugin_cache_dir`](/docs/cli/config/config-file.html#plugin_cache_dir) settings.
     It should not be used in Terraform versions 0.13+, and this option
     was removed in Terraform 0.15.
 - `-plugin-dir=PATH` — Force plugin installation to read plugins _only_ from
   the specified directory, as if it had been configured as a `filesystem_mirror`
   in the CLI configuration. If you intend to routinely use a particular
   filesystem mirror then we recommend
-  [configuring Terraform's installation methods globally](./cli-config.html#provider-installation).
+  [configuring Terraform's installation methods globally](/docs/cli/config/config-file.html#provider-installation).
   You can use `-plugin-dir` as a one-time override for exceptional situations,
   such as if you are testing a local build of a provider plugin you are
   currently developing.
@@ -187,6 +187,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
+[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/cli/commands/login.html.md

@@ -15,7 +15,7 @@ API token for Terraform Cloud, Terraform Enterprise, or any other host that offe
 where it is possible to launch a web browser on the same host where Terraform
 is running. If you are running Terraform in an unattended automation scenario,
 you can
-[configure credentials manually in the CLI configuration](https://www.terraform.io/docs/commands/cli-config.html#credentials).
+[configure credentials manually in the CLI configuration](https://www.terraform.io/docs/cli/config/config-file.html#credentials).
 
 ## Usage
 
@@ -34,7 +34,7 @@ not as desired.
 
 If you don't wish to store your API token in the default location, you can
 optionally configure a
-[credentials helper program](cli-config.html#credentials-helpers) which knows
+[credentials helper program](/docs/cli/config/config-file.html#credentials-helpers) which knows
 how to store and later retrieve credentials in some other system, such as
 your organization's existing secrets management system.
 

website/docs/cli/commands/logout.html.md

@@ -26,5 +26,5 @@ the remote server, so it will remain valid until manually revoked.
 
 By default, Terraform will remove the token stored in plain text in a local CLI
 configuration file called `credentials.tfrc.json`. If you have configured a
-[credentials helper program](cli-config.html#credentials-helpers), Terraform
+[credentials helper program](/docs/cli/config/config-file.html#credentials-helpers), Terraform
 will use the helper's `forget` command to remove it.

website/docs/cli/commands/output.html.md

@@ -31,7 +31,7 @@ The command-line flags are all optional. The list of available flags are:
     for processing complex data types.
 * `-no-color` - If specified, output won't contain any color.
 * `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
-    Ignored when [remote state](/docs/state/remote.html) is used.
+    Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 ## Examples
 

website/docs/cli/commands/plan.html.md

@@ -70,19 +70,19 @@ The available options are:
 * `-refresh=true` - Update the state prior to checking for differences.
 
 * `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 * `-target=resource` - A [Resource
-  Address](/docs/internals/resource-addressing.html) to target. This flag can
+  Address](/docs/cli/state/resource-addressing.html) to target. This flag can
   be used multiple times. See below for more information.
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [literal expressions](/docs/configuration/expressions/types.html) in the
+  [literal expressions](/docs/language/expressions/types.html) in the
   Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
+  a [variable file](/docs/language/values/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files
@@ -93,7 +93,7 @@ The available options are:
 
 The `-target` option can be used to focus Terraform's attention on only a
 subset of resources.
-[Resource Address](/docs/internals/resource-addressing.html) syntax is used
+[Resource Address](/docs/cli/state/resource-addressing.html) syntax is used
 to specify the constraint. The resource address is interpreted as follows:
 
 * If the given address has a _resource spec_, only the specified resource
@@ -115,7 +115,7 @@ of resources relates to configuration.
 Instead of using `-target` as a means to operate on isolated portions of very
 large configurations, prefer instead to break large configurations into
 several smaller configurations that can each be independently applied.
-[Data sources](/docs/configuration/data-sources.html) can be used to access
+[Data sources](/docs/language/data-sources/index.html) can be used to access
 information about resources created in other configurations, allowing
 a complex system architecture to be broken down into more manageable parts
 that can be updated independently.
@@ -150,6 +150,6 @@ current working directory.
 If your previous use of this legacy pattern was also relying on Terraform
 writing the `.terraform` subdirectory into the current working directory even
 though the root module directory was overridden, use
-[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
+[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
 to direct Terraform to write the `.terraform` directory to a location other
 than the current working directory.

website/docs/cli/commands/providers.html.md

@@ -10,7 +10,7 @@ description: |-
 # Command: providers
 
 The `terraform providers` command shows information about the
-[provider requirements](/docs/configuration/provider-requirements.html) of the
+[provider requirements](/docs/language/providers/requirements.html) of the
 configuration in the current working directory, as an aid to understanding
 where each requirement was detected from.
 

website/docs/cli/commands/providers/lock.html.md

@@ -11,15 +11,15 @@ description: |-
 
 The `terraform providers lock` consults upstream registries (by default) in
 order to write provider dependency information into
-[the dependency lock file](/docs/configuration/dependency-lock.html).
+[the dependency lock file](/docs/language/dependency-lock.html).
 
 The common way to update the dependency lock file is as a side-effect of normal
 provider installation during
-[`terraform init`](../init.html), but there are several situations where that
+[`terraform init`](/docs/cli/commands/init.html), but there are several situations where that
 automatic approach may not be sufficient:
 
 * If you are running Terraform in an environment that uses
-  [alternative provider installation methods](../cli-config.html#provider-installation),
+  [alternative provider installation methods](/docs/cli/config/config-file.html#provider-installation),
   such as filesystem or network mirrors, normal provider installation will not
   access the origin registry for a provider and therefore Terraform will not
   be able to populate all of the possible package checksums for the selected
@@ -35,7 +35,7 @@ automatic approach may not be sufficient:
   on both Windows and Linux) and the upstream registry for a provider is unable
   to provide signed checksums using the latest hashing scheme, subsequent runs
   of Terraform on other platforms may
-  [add additional checksums to the lock file](/docs/configuration/dependency-lock.html#new-provider-package-checksums).
+  [add additional checksums to the lock file](/docs/language/dependency-lock.html#new-provider-package-checksums).
   You can avoid that by pre-populating hashes for all of the platforms you
   intend to use, using the `terraform providers lock` command.
 
@@ -49,7 +49,7 @@ With no additional command line arguments, `terraform providers lock` will
 analyze the configuration in the current working directory to find all of
 the providers it depends on, and it will fetch the necessary data about those
 providers from their origin registries and then update
-[the dependency lock file](/docs/configuration/dependency-lock.html) to
+[the dependency lock file](/docs/language/dependency-lock.html) to
 include a selected version for each provider and all of the package checksums
 that are covered by the provider developer's cryptographic signature.
 
@@ -150,7 +150,7 @@ multiple times and specify a different subset of your providers each time.
 
 The `-fs-mirror` and `-net-mirror` options have the same meaning as
 `filesystem_mirror` and `network_mirror` blocks in
-[the provider installation methods configuration](../cli-config.html#provider-installation),
+[the provider installation methods configuration](/docs/cli/config/config-file.html#provider-installation),
 but specify only a single method in order to be explicit about where you
 intend to derive the package checksum information from.
 

website/docs/cli/commands/providers/mirror.html.md

@@ -19,7 +19,7 @@ from provider registries as part of initializing the current working directory.
 Sometimes Terraform is running in an environment where that isn't possible,
 such as on an isolated network without access to the Terraform Registry. In
 that case,
-[explicit installation method configuration](../cli-config.html#explicit-installation-method-configuration)
+[explicit installation method configuration](/docs/cli/config/config-file.html#explicit-installation-method-configuration)
 allows you to configure Terraform, when running on a particular system, to
 consult only a local filesystem directory where you've created a local mirror
 of the necessary plugins, and to skip accessing the upstream registry at all.

website/docs/cli/commands/push.html.md

@@ -8,7 +8,7 @@ description: |-
 
 # Command: push
 
-!> **Important:** The `terraform push` command is no longer functional. Its functionality was replaced and surpassed by [the `remote` backend](/docs/backends/types/remote.html), which works with current versions of Terraform Cloud. The `remote` backend allows you to run remote operations directly from the command line, and displays real-time output from the remote run environment.
+!> **Important:** The `terraform push` command is no longer functional. Its functionality was replaced and surpassed by [the `remote` backend](/docs/language/settings/backends/remote.html), which works with current versions of Terraform Cloud. The `remote` backend allows you to run remote operations directly from the command line, and displays real-time output from the remote run environment.
 
 The `terraform push` command was an early implementation of remote Terraform runs. It allowed teams to push a configuration to a remote run environment in a discontinued version of Terraform Enterprise.
 

website/docs/cli/commands/refresh.html.md

@@ -43,24 +43,24 @@ The `terraform refresh` command accepts the following options:
   to 10.
 
 * `-state=path` - Path to read and write the state file to. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 * `-state-out=path` - Path to write updated state file. By default, the
   `-state` path will be used. Ignored when
-  [remote state](/docs/state/remote.html) is used.
+  [remote state](/docs/language/state/remote.html) is used.
 
 * `-target=resource` - A [Resource
-  Address](/docs/internals/resource-addressing.html) to target. Operation will
+  Address](/docs/cli/state/resource-addressing.html) to target. Operation will
   be limited to this resource and its dependencies. This flag can be used
   multiple times.
 
 * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
   can be set multiple times. Variable values are interpreted as
-  [literal expressions](/docs/configuration/expressions/types.html) in the
+  [literal expressions](/docs/language/expressions/types.html) in the
   Terraform language, so list and map values can be specified via this flag.
 
 * `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If
+  a [variable file](/docs/language/values/variables.html#variable-definitions-tfvars-files). If
   a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
   directory, they will be automatically loaded. `terraform.tfvars` is loaded
   first and the `.auto.tfvars` files after in alphabetical order. Any files

website/docs/cli/commands/show.html.md

@@ -18,7 +18,7 @@ flag.
 
 -> **Note:** When using the `-json` command-line flag, any sensitive values in
 Terraform state will be displayed in plain text. For more information, see
-[Sensitive Data in State](/docs/state/sensitive-data.html).
+[Sensitive Data in State](/docs/language/state/sensitive-data.html).
 
 ## JSON Output
 

website/docs/cli/commands/state/index.html.md

@@ -10,7 +10,7 @@ description: |-
 
 The `terraform state` command is used for advanced state management.
 As your Terraform usage becomes more advanced, there are some cases where
-you may need to modify the [Terraform state](/docs/state/index.html).
+you may need to modify the [Terraform state](/docs/language/state/index.html).
 Rather than modify the state directly, the `terraform state` commands can
 be used in many cases instead.
 
@@ -35,7 +35,7 @@ written to disk and the CLI usage is the same as if it were local state.
 All `terraform state` subcommands that modify the state write backup
 files. The path of these backup file can be controlled with `-backup`.
 
-Subcommands that are read-only (such as [list](/docs/commands/state/list.html))
+Subcommands that are read-only (such as [list](/docs/cli/commands/state/list.html))
 do not write any backup files since they aren't modifying the state.
 
 Note that backups for state modification _can not be disabled_. Due to

website/docs/cli/commands/state/list.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state list
 
 The `terraform state list` command is used to list resources within a
-[Terraform state](/docs/state/index.html).
+[Terraform state](/docs/language/state/index.html).
 
 ## Usage
 
@@ -25,12 +25,12 @@ within modules are listed last.
 
 For complex infrastructures, the state can contain thousands of resources.
 To filter these, provide one or more patterns to the command. Patterns are
-in [resource addressing format](/docs/commands/state/addressing.html).
+in [resource addressing format](/docs/cli/state/resource-addressing.html).
 
 The command-line flags are all optional. The list of available flags are:
 
 * `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 * `-id=id` - ID of resources to show. Ignored when unset.
 
 ## Example: All Resources

website/docs/cli/commands/state/mv.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state mv
 
 The `terraform state mv` command is used to move items in a
-[Terraform state](/docs/state/index.html). This command can move
+[Terraform state](/docs/language/state/index.html). This command can move
 single resources, single instances of a resource, entire modules, and more.
 This command can also move items to a completely different state file,
 enabling efficient refactoring.
@@ -36,7 +36,7 @@ for each state file.
 
 This command requires a source and destination address of the item to move.
 Addresses are
-in [resource addressing format](/docs/commands/state/addressing.html).
+in [resource addressing format](/docs/cli/state/resource-addressing.html).
 
 The command-line flags are all optional. The list of available flags are:
 
@@ -100,7 +100,7 @@ $ terraform state mv -state-out=other.tfstate 'module.app' 'module.app'
 ## Example: Move a Resource configured with count
 
 The example below moves the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/meta-arguments/count.html) to
+[`count`](/docs/language/meta-arguments/count.html) to
 the first instance of a resource named `helper` also configured with `count`:
 
 ```shell
@@ -110,7 +110,7 @@ $ terraform state mv 'packet_device.worker[0]' 'packet_device.helper[0]'
 ## Example: Move a Resource configured with for_each
 
 The example below moves the `"example123"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/meta-arguments/for_each.html)
+[`for_each`](/docs/language/meta-arguments/for_each.html)
 to the `"example456"` instance of a resource named `helper` also configuring `for_each`:
 
 Linux, Mac OS, and UNIX:

website/docs/cli/commands/state/pull.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state pull
 
 The `terraform state pull` command is used to manually download and output
-the state from [remote state](/docs/state/remote.html). This command also
+the state from [remote state](/docs/language/state/remote.html). This command also
 works with local state.
 
 ## Usage

website/docs/cli/commands/state/push.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state push
 
 The `terraform state push` command is used to manually upload a local
-state file to [remote state](/docs/state/remote.html). This command also
+state file to [remote state](/docs/language/state/remote.html). This command also
 works with local state.
 
 This command should rarely be used. It is meant only as a utility in case
@@ -20,7 +20,7 @@ manual intervention is necessary with the remote state.
 Usage: `terraform state push [options] PATH`
 
 This command will push the state specified by PATH to the currently
-configured [backend](/docs/configuration/blocks/backends/index.html).
+configured [backend](/docs/language/settings/backends/index.html).
 
 If PATH is "-" then the state data to push is read from stdin. This data
 is loaded completely into memory and verified prior to being written to

website/docs/cli/commands/state/replace-provider.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state replace-provider
 
 The `terraform state replace-provider` command is used to replace the provider
-for resources in a [Terraform state](/docs/state/index.html).
+for resources in a [Terraform state](/docs/language/state/index.html).
 
 ## Usage
 

website/docs/cli/commands/state/rm.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: state rm
 
 The `terraform state rm` command is used to remove items from the
-[Terraform state](/docs/state/index.html). This command can remove
+[Terraform state](/docs/language/state/index.html). This command can remove
 single resources, single instances of a resource, entire modules,
 and more.
 
@@ -39,7 +39,7 @@ of this command, backups are required.
 
 This command requires one or more addresses that point to a resources in the
 state. Addresses are
-in [resource addressing format](/docs/commands/state/addressing.html).
+in [resource addressing format](/docs/cli/state/resource-addressing.html).
 
 The command-line flags are all optional. The list of available flags are:
 
@@ -83,7 +83,7 @@ $ terraform state rm 'module.foo.packet_device.worker'
 ## Example: Remove a Resource configured with count
 
 The example below removes the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/meta-arguments/count.html):
+[`count`](/docs/language/meta-arguments/count.html):
 
 ```shell
 $ terraform state rm 'packet_device.worker[0]'
@@ -92,7 +92,7 @@ $ terraform state rm 'packet_device.worker[0]'
 ## Example: Remove a Resource configured with for_each
 
 The example below removes the `"example"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/meta-arguments/for_each.html):
+[`for_each`](/docs/language/meta-arguments/for_each.html):
 
 Linux, Mac OS, and UNIX:
 

website/docs/cli/commands/state/show.html.md

@@ -10,7 +10,7 @@ description: |-
 
 The `terraform state show` command is used to show the attributes of a
 single resource in the
-[Terraform state](/docs/state/index.html).
+[Terraform state](/docs/language/state/index.html).
 
 ## Usage
 
@@ -21,16 +21,16 @@ state file that matches the given address.
 
 This command requires an address that points to a single resource in the
 state. Addresses are
-in [resource addressing format](/docs/commands/state/addressing.html).
+in [resource addressing format](/docs/cli/state/resource-addressing.html).
 
 The command-line flags are all optional. The list of available flags are:
 
 * `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 The output of `terraform state show` is intended for human consumption, not
 programmatic consumption. To extract state data for use in other software, use
-[`terraform show -json`](../show.html#json-output) and decode the result
+[`terraform show -json`](/docs/cli/commands/show.html#json-output) and decode the result
 using the documented structure.
 
 ## Example: Show a Resource
@@ -61,7 +61,7 @@ $ terraform state show 'module.foo.packet_device.worker'
 ## Example: Show a Resource configured with count
 
 The example below shows the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/meta-arguments/count.html):
+[`count`](/docs/language/meta-arguments/count.html):
 
 ```shell
 $ terraform state show 'packet_device.worker[0]'
@@ -70,7 +70,7 @@ $ terraform state show 'packet_device.worker[0]'
 ## Example: Show a Resource configured with for_each
 
 The example below shows the `"example"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/meta-arguments/for_each.html):
+[`for_each`](/docs/language/meta-arguments/for_each.html):
 
 Linux, Mac OS, and UNIX:
 

website/docs/cli/commands/taint.html.md

@@ -14,9 +14,9 @@ as tainted, forcing it to be destroyed and recreated on the next apply.
 This command _will not_ modify infrastructure, but does modify the
 state file in order to mark a resource as tainted. Once a resource is
 marked as tainted, the next
-[plan](/docs/commands/plan.html) will show that the resource will
+[plan](/docs/cli/commands/plan.html) will show that the resource will
 be destroyed and recreated and the next
-[apply](/docs/commands/apply.html) will implement this change.
+[apply](/docs/cli/commands/apply.html) will implement this change.
 
 Forcing the recreation of a resource is useful when you want a certain
 side effect of recreation that is not visible in the attributes of a resource.
@@ -28,7 +28,7 @@ Note that tainting a resource for recreation may affect resources that
 depend on the newly tainted resource. For example, a DNS resource that
 uses the IP address of a server may need to be modified to reflect
 the potentially new IP address of a tainted server. The
-[plan command](/docs/commands/plan.html) will show this if this is
+[plan command](/docs/cli/commands/plan.html) will show this if this is
 the case.
 
 ## Usage
@@ -37,7 +37,7 @@ Usage: `terraform taint [options] address`
 
 The `address` argument is the address of the resource to mark as tainted.
 The address is in
-[the resource address syntax](/docs/internals/resource-addressing.html) syntax,
+[the resource address syntax](/docs/cli/state/resource-addressing.html) syntax,
 as shown in the output from other commands, such as:
 
  * `aws_instance.foo`
@@ -59,11 +59,11 @@ The command-line flags are all optional. The list of available flags are:
 * `-lock-timeout=0s` - Duration to retry a state lock.
 
 * `-state=path` - Path to read and write the state file to. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 * `-state-out=path` - Path to write updated state file. By default, the
   `-state` path will be used. Ignored when
-  [remote state](/docs/state/remote.html) is used.
+  [remote state](/docs/language/state/remote.html) is used.
 
 * `-ignore-remote-version` - When using the enhanced remote backend with
   Terraform Cloud, continue even if remote and local Terraform versions differ.
@@ -104,7 +104,7 @@ Resource instance module.couchbase.aws_instance.cb_node[9] has been marked as ta
 ```
 
 Although we recommend that most configurations use only one level of nesting
-and employ [module composition](/docs/modules/composition.html), it's possible
+and employ [module composition](/docs/language/modules/develop/composition.html), it's possible
 to have multiple levels of nested modules. In that case the resource instance
 address must include all of the steps to the target instance, as in the
 following example:

website/docs/cli/commands/untaint.html.md

@@ -52,11 +52,11 @@ certain cases, see above note). The list of available flags are:
 * `-no-color` - Disables output with coloring
 
 * `-state=path` - Path to read and write the state file to. Defaults to "terraform.tfstate".
-  Ignored when [remote state](/docs/state/remote.html) is used.
+  Ignored when [remote state](/docs/language/state/remote.html) is used.
 
 * `-state-out=path` - Path to write updated state file. By default, the
   `-state` path will be used. Ignored when
-  [remote state](/docs/state/remote.html) is used.
+  [remote state](/docs/language/state/remote.html) is used.
 
 * `-ignore-remote-version` - When using the enhanced remote backend with
   Terraform Cloud, continue even if remote and local Terraform versions differ.

website/docs/cli/commands/version.html.md

@@ -17,7 +17,7 @@ Usage: `terraform version [options]`
 
 With no additional arguments, `version` will display the version of Terraform,
 the platform it's installed on, installed providers, and the results of upgrade
-and security checks [unless disabled](/docs/commands/index.html#upgrade-and-security-bulletin-checks).
+and security checks [unless disabled](/docs/cli/commands/index.html#upgrade-and-security-bulletin-checks).
 
 This command has one optional flag:
 

website/docs/cli/commands/workspace/index.html.md

@@ -9,7 +9,7 @@ description: |-
 # Command: workspace
 
 The `terraform workspace` command is used to manage
-[workspaces](/docs/state/workspaces.html).
+[workspaces](/docs/language/state/workspaces.html).
 
 This command is a container for further subcommands. These subcommands are
 listed in the navigation bar.

website/docs/cli/config/config-file.html.md

@@ -11,7 +11,7 @@ description: |-
 
 The CLI configuration file configures per-user settings for CLI behaviors,
 which apply across all Terraform working directories. This is separate from
-[your infrastructure configuration](/docs/configuration/index.html).
+[your infrastructure configuration](/docs/language/index.html).
 
 ## Location
 
@@ -33,7 +33,7 @@ as just `terraform.rc`. Use `dir` from PowerShell or Command Prompt to
 confirm the filename.
 
 The location of the Terraform CLI configuration file can also be specified
-using the `TF_CLI_CONFIG_FILE` [environment variable](/docs/commands/environment-variables.html).
+using the `TF_CLI_CONFIG_FILE` [environment variable](/docs/cli/config/environment-variables.html).
 
 ## Configuration File Syntax
 
@@ -60,7 +60,7 @@ The following settings can be set in the CLI configuration file:
   See [Credentials Helpers](#credentials-helpers) below for more information.
 
 - `disable_checkpoint` — when set to `true`, disables
-  [upgrade and security bulletin checks](/docs/commands/index.html#upgrade-and-security-bulletin-checks)
+  [upgrade and security bulletin checks](/docs/cli/commands/index.html#upgrade-and-security-bulletin-checks)
   that require reaching out to HashiCorp-provided network services.
 
 - `disable_checkpoint_signature` — when set to `true`, allows the upgrade and
@@ -93,7 +93,7 @@ credentials "app.terraform.io" {
 }
 ```
 
-If you are running the Terraform CLI interactively on a computer with a web browser, you can use [the `terraform login` command](./login.html)
+If you are running the Terraform CLI interactively on a computer with a web browser, you can use [the `terraform login` command](/docs/cli/commands/login.html)
 to get credentials and automatically save them in the CLI configuration. If
 not, you can manually write `credentials` blocks.
 
@@ -394,7 +394,7 @@ provider_installation {
 With development overrides in effect, the `terraform init` command will still
 attempt to select a suitable published version of your provider to install and
 record in
-[the dependency lock file](/docs/configuration/dependency-lock.html)
+[the dependency lock file](/docs/language/dependency-lock.html)
 for future use, but other commands like
 `terraform apply` will disregard the lock file's entry for `hashicorp/null` and
 will use the given directory instead. Once your new changes are included in a

website/docs/cli/config/environment-variables.html.md

@@ -59,7 +59,7 @@ export TF_VAR_alist='[1,2,3]'
 export TF_VAR_amap='{ foo = "bar", baz = "qux" }'
 ```
 
-For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/docs/configuration/variables.html).
+For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/docs/language/values/variables.html).
 
 ## TF_CLI_ARGS and TF_CLI_ARGS_name
 
@@ -114,7 +114,7 @@ export TF_WORKSPACE=your_workspace
 Using this environment variable is recommended only for non-interactive usage, since in a local shell environment it can be easy to forget the variable is set and apply changes to the wrong state.
 
 For more information regarding workspaces, check out the section on [Using Workspaces]
-(https://www.terraform.io/docs/state/workspaces.html).
+(https://www.terraform.io/docs/language/state/workspaces.html).
 
 ## TF_IN_AUTOMATION
 
@@ -145,7 +145,7 @@ export TF_REGISTRY_CLIENT_TIMEOUT=15
 
 ## TF_CLI_CONFIG_FILE
 
-The location of the [Terraform CLI configuration file](/docs/commands/cli-config.html).
+The location of the [Terraform CLI configuration file](/docs/cli/config/config-file.html).
 
 ```shell
 export TF_CLI_CONFIG_FILE="$HOME/.terraformrc-custom"
@@ -159,4 +159,4 @@ If `TF_IGNORE` is set to "trace", Terraform will output debug messages to displa
 export TF_IGNORE=trace
 ```
 
-For more details on `.terraformignore`, please see [Excluding Files from Upload with .terraformignore](/docs/backends/types/remote.html#excluding-files-from-upload-with-terraformignore).
+For more details on `.terraformignore`, please see [Excluding Files from Upload with .terraformignore](/docs/language/settings/backends/remote.html#excluding-files-from-upload-with-terraformignore).

website/docs/cli/config/index.html.md

@@ -14,9 +14,9 @@ most of the global settings relate to advanced or automated workflows, or
 unusual environmental conditions like running Terraform on an airgapped
 instance.
 
-- The [CLI config file](/docs/commands/cli-config.html) configures provider
+- The [CLI config file](/docs/cli/config/config-file.html) configures provider
   installation and security features.
-- Several [environment variables](/docs/commands/environment-variables.html) can
+- Several [environment variables](/docs/cli/config/environment-variables.html) can
   configure Terraform's inputs and outputs; this includes some alternate ways to
   provide information that is usually passed on the command line or read from
   the state of the shell.

website/docs/cli/import/importability.html.md

@@ -20,5 +20,5 @@ Converting a resource to be importable is also relatively simple, so if
 you're interested in contributing that functionality, the Terraform team
 would be grateful.
 
-To make a resource importable, please see the
-[plugin documentation on writing a resource](/docs/plugins/provider.html).
+To make a resource importable, please see
+[Extending Terraform: Resources — Import](/docs/extend/resources/import.html).

website/docs/cli/import/index.html.md

@@ -26,12 +26,12 @@ itself having created all objects. If you import existing objects into Terraform
 be careful to import each remote object to only one Terraform resource address.
 If you import the same object multiple times, Terraform may exhibit unwanted
 behavior. For more information on this assumption, see
-[the State section](/docs/state/).
+[the State section](/docs/language/state/index.html).
 
 ## Currently State Only
 
 The current implementation of Terraform import can only import resources
-into the [state](/docs/state/). It does not generate configuration. A future
+into the [state](/docs/language/state/index.html). It does not generate configuration. A future
 version of Terraform will also generate configuration.
 
 Because of this, prior to running `terraform import` it is necessary to write
@@ -44,7 +44,7 @@ importing existing resources.
 ## Remote Backends
 
 When using Terraform import on the command line with a [remote
-backend](/docs/backends/types/remote.html), such as Terraform Cloud, the import
+backend](/docs/language/settings/backends/remote.html), such as Terraform Cloud, the import
 command runs locally, unlike commands such as apply, which run inside your
 Terraform Cloud environment. Because of this, the import command will not have
 access to information from the remote backend, such as workspace variables.

website/docs/cli/import/usage.html.md

@@ -23,7 +23,7 @@ itself having created all objects. If you import existing objects into Terraform
 be careful to import each remote object to only one Terraform resource address.
 If you import the same object multiple times, Terraform may exhibit unwanted
 behavior. For more information on this assumption, see
-[the State section](/docs/state/).
+[the State section](/docs/language/state/index.html).
 
 To import a resource, first write a resource block for it in your
 configuration, establishing the name by which it will be known to Terraform:
@@ -57,7 +57,7 @@ Terraform state.
 
 It is also possible to import to resources in child modules, using their paths,
 and to single instances of a resource with `count` or `for_each` set. See
-[_Resource Addressing_](/docs/internals/resource-addressing.html) for more
+[_Resource Addressing_](/docs/cli/state/resource-addressing.html) for more
 details on how to specify a target resource.
 
 The syntax of the given ID is dependent on the resource type being imported.
@@ -83,4 +83,4 @@ a `resource` block in configuration for each secondary resource. If this is
 not done, Terraform will plan to destroy the imported objects on the next run.
 
 If you want to rename or otherwise move the imported resources, the
-[state management commands](/docs/commands/state/index.html) can be used.
+[state management commands](/docs/cli/commands/state/index.html) can be used.

website/docs/cli/index.html.md

@@ -17,4 +17,4 @@ Cloud or Terraform Enterprise.
 
 Notably, this documentation does not cover the syntax and usage of the Terraform
 language. For that, see the
-[Terraform Language Documentation](/docs/configuration/index.html).
+[Terraform Language Documentation](/docs/language/index.html).

website/docs/cli/init/index.html.md

@@ -7,7 +7,7 @@ page_title: "Initializing Working Directories - Terraform CLI"
 
 Terraform expects to be invoked from a working directory that contains
 configuration files written in
-[the Terraform language](/docs/configuration/index.html). Terraform uses
+[the Terraform language](/docs/language/index.html). Terraform uses
 configuration content from this directory, and also uses the directory to store
 settings, cached plugins and modules, and sometimes state data.
 
@@ -47,7 +47,7 @@ plugins, and downloading modules. Under some conditions (usually when changing
 from one backend to another), it might ask the user for guidance or
 confirmation.
 
-For details, see [the `terraform init` command](/docs/commands/init.html).
+For details, see [the `terraform init` command](/docs/cli/commands/init.html).
 
 ## Reinitialization
 

website/docs/cli/inspect/index.html.md

@@ -15,19 +15,19 @@ Terraform CLI includes some commands for inspecting or transforming this data.
 You can use these to integrate other tools with Terraform's infrastructure data,
 or just to gain a deeper or more holistic understanding of your infrastructure.
 
-- [The `terraform graph` command](/docs/commands/graph.html) creates a visual
+- [The `terraform graph` command](/docs/cli/commands/graph.html) creates a visual
   representation of a configuration or a set of planned changes.
-- [The `terraform output` command](/docs/commands/output.html) can get the
-  values for the top-level [output values](/docs/configuration/outputs.html) of
+- [The `terraform output` command](/docs/cli/commands/output.html) can get the
+  values for the top-level [output values](/docs/language/values/outputs.html) of
   a configuration, which are often helpful when making use of the infrastructure
   Terraform has provisioned.
-- [The `terraform show` command](/docs/commands/show.html) can generate
+- [The `terraform show` command](/docs/cli/commands/show.html) can generate
   human-readable versions of a state file or plan file, or generate
   machine-readable versions that can be integrated with other tools.
-- [The `terraform state list` command](/docs/commands/state/list.html) can list
+- [The `terraform state list` command](/docs/cli/commands/state/list.html) can list
   the resources being managed by the current working directory and workspace,
   providing a complete or filtered list.
-- [The `terraform state show` command](/docs/commands/state/show.html) can print
+- [The `terraform state show` command](/docs/cli/commands/state/show.html) can print
   all of the attributes of a given resource being managed by the current working
   directory and workspace, including generated read-only attributes like the
   unique ID assigned by the cloud provider.

website/docs/cli/plugins/index.html.md

@@ -7,7 +7,7 @@ page_title: "Managing Plugins - Terraform CLI"
 
 Terraform relies on plugins called "providers" in order to manage various types
 of resources. (For more information about providers, see
-[Providers](/docs/configuration/blocks/providers/index.html) in the Terraform
+[Providers](/docs/language/providers/index.html) in the Terraform
 language docs.)
 
 -> **Note:** Providers are currently the only plugin type most Terraform users
@@ -15,7 +15,7 @@ will interact with. Terraform also supports third-party provisioner plugins, but
 we discourage their use.
 
 Terraform downloads and/or installs any providers
-[required](/docs/configuration/provider-requirements.html) by a configuration
+[required](/docs/language/providers/requirements.html) by a configuration
 when [initializing](/docs/cli/init/index.html) a working directory. By default,
 this works without any additional interaction but requires network access to
 download providers from their source registry.
@@ -30,29 +30,29 @@ environments.
 
 Terraform's configuration file includes options for caching downloaded plugins,
 or explicitly specifying a local or HTTPS mirror to install plugins from. For
-more information, see [CLI Config File](/docs/commands/cli-config.html).
+more information, see [CLI Config File](/docs/cli/config/config-file.html).
 
 ## Getting Plugin Information
 
-Use the [`terraform providers`](/docs/commands/providers.html) command to get information
+Use the [`terraform providers`](/docs/cli/commands/providers.html) command to get information
 about the providers required by the current working directory's configuration.
 
-Use the [`terraform version`](/docs/commands/version.html) command (or
+Use the [`terraform version`](/docs/cli/commands/version.html) command (or
 `terraform -version`) to show the specific provider versions installed for the
 current working directory.
 
-Use the [`terraform providers schema`](/docs/commands/providers/schema.html) command to
+Use the [`terraform providers schema`](/docs/cli/commands/providers/schema.html) command to
 get machine-readable information about the resources and configuration options
 offered by each provider.
 
 ## Managing Plugin Installation
 
-Use the [`terraform providers mirror`](/docs/commands/providers/mirror.html) command to
+Use the [`terraform providers mirror`](/docs/cli/commands/providers/mirror.html) command to
 download local copies of every provider required by the current working
 directory's configuration. This directory will use the nested directory layout
 that Terraform expects when installing plugins from a local source, so you can
 transfer it directly to an airgapped system that runs Terraform.
 
-Use the [`terraform providers lock`](/docs/commands/providers/lock.html) command
+Use the [`terraform providers lock`](/docs/cli/commands/providers/lock.html) command
 to update the lock file that Terraform uses to ensure predictable runs when
 using ambiguous provider version constraints.

website/docs/cli/plugins/signing.html.md

@@ -1,7 +1,6 @@
 ---
-layout: "registry"
+layout: "docs"
 page_title: "Plugin Signing"
-sidebar_current: "docs-plugins-signing"
 description: |-
   Terraform plugin signing trust levels
 ---
@@ -15,7 +14,7 @@ description: |-
 Terraform providers installed from the Registry are cryptographically signed, and the signature is verified at time of installation. There are three types of provider signatures, each with different trust implications:
 
 * **Signed by HashiCorp** - are built, signed, and supported by HashiCorp.
-* **Signed by Trusted Partners** - are built, signed, and supported by a third party. HashiCorp has 
+* **Signed by Trusted Partners** - are built, signed, and supported by a third party. HashiCorp has
 verified the ownership of the private key and we provide a chain of trust to the CLI to verify this
 programatically.
 * **Self-signed** - are built, signed, and supported by a third party. HashiCorp does not provide a

website/docs/cli/run/index.html.md

@@ -7,7 +7,7 @@ page_title: "Provisioning Infrastructure - Terraform CLI"
 
 Terraform's primary function is to create, modify, and destroy infrastructure
 resources to match the desired state described in a
-[Terraform configuration](/docs/configuration/index.html).
+[Terraform configuration](/docs/language/index.html).
 
 When people refer to "running Terraform," they generally mean performing these
 provisioning actions in order to affect real infrastructure objects. The
@@ -38,7 +38,7 @@ resulting actions are as expected. However, `terraform plan` can also save its
 plan as a runnable artifact, which `terraform apply` can use to carry out those
 exact changes.
 
-For details, see [the `terraform plan` command](/docs/commands/plan.html).
+For details, see [the `terraform plan` command](/docs/cli/commands/plan.html).
 
 ## Applying
 
@@ -54,7 +54,7 @@ running a new plan. You can use this to reliably perform an exact set of
 pre-approved changes, even if the configuration or the state of the real
 infrastructure has changed in the minutes since the original plan was created.
 
-For details, see [the `terraform apply` command](/docs/commands/apply.html).
+For details, see [the `terraform apply` command](/docs/cli/commands/apply.html).
 
 ## Destroying
 
@@ -68,4 +68,4 @@ and then running an apply, except that it doesn't require editing the
 configuration. This is more convenient if you intend to provision similar
 resources at a later date.
 
-For details, see [the `terraform destroy` command](/docs/commands/destroy.html).
+For details, see [the `terraform destroy` command](/docs/cli/commands/destroy.html).

website/docs/cli/state/index.html.md

@@ -5,7 +5,7 @@ page_title: "Manipulating State - Terraform CLI"
 
 # Manipulating Terraform State
 
-Terraform uses [state data](/docs/state/index.html) to remember which
+Terraform uses [state data](/docs/language/state/index.html) to remember which
 real-world object corresponds to each resource in the configuration;
 this allows it to modify an existing object when its resource declaration
 changes.
@@ -21,7 +21,7 @@ Terraform CLI supports several workflows for interacting with state:
 - [Forcing Re-creation (Tainting)](/docs/cli/state/taint.html)
 - [Moving Resources](/docs/cli/state/move.html)
 - Importing Pre-existing Resources (documented in the
-  [Importing Infrastructure](/docs/import/index.html) section)
+  [Importing Infrastructure](/docs/cli/import/index.html) section)
 - [Disaster Recovery](/docs/cli/state/recover.html)
 
 ~> **Important:** Modifying state data outside a normal plan or apply can cause

website/docs/cli/state/inspect.html.md

@@ -8,14 +8,14 @@ page_title: "Inspecting State - Terraform CLI"
 Terraform includes some commands for reading and updating state without taking
 any other actions.
 
-- [The `terraform state list` command](/docs/commands/state/list.html)
+- [The `terraform state list` command](/docs/cli/commands/state/list.html)
   shows the resource addresses for every resource Terraform knows about in a
   configuration, optionally filtered by partial resource address.
 
-- [The `terraform state show` command](/docs/commands/state/show.html)
+- [The `terraform state show` command](/docs/cli/commands/state/show.html)
   displays detailed state data about one resource.
 
-- [The `terraform refresh` command](/docs/commands/refresh.html) updates
+- [The `terraform refresh` command](/docs/cli/commands/refresh.html) updates
   state data to match the real-world condition of the managed resources. This is
   done automatically during plans and applies, but not when interacting with
   state directly.

website/docs/cli/state/move.html.md

@@ -6,7 +6,7 @@ page_title: "Moving Resources - Terraform CLI"
 # Moving Resources
 
 Terraform's state associates each real-world object with a configured resource
-at a specific [resource address](/docs/internals/resource-addressing.html). This
+at a specific [resource address](/docs/cli/state/resource-addressing.html). This
 is seamless when changing a resource's attributes, but Terraform will lose track
 of a resource if you change its name, move it to a different module, or change
 its provider.
@@ -19,17 +19,17 @@ In cases where it's important to preserve an existing infrastructure object, you
 can explicitly tell Terraform to associate it with a different configured
 resource.
 
-- [The `terraform state mv` command](/docs/commands/state/mv.html) changes
+- [The `terraform state mv` command](/docs/cli/commands/state/mv.html) changes
   which resource address in your configuration is associated with a particular
   real-world object. Use this to preserve an object when renaming a resource, or
   when moving a resource into or out of a child module.
 
-- [The `terraform state rm` command](/docs/commands/state/rm.html) tells
+- [The `terraform state rm` command](/docs/cli/commands/state/rm.html) tells
   Terraform to stop managing a resource as part of the current working directory
   and workspace, _without_ destroying the corresponding real-world object. (You
   can later use `terraform import` to start managing that resource in a
   different workspace or a different Terraform configuration.)
 
-- [The `terraform state replace-provider` command](/docs/commands/state/replace-provider.html)
+- [The `terraform state replace-provider` command](/docs/cli/commands/state/replace-provider.html)
   transfers existing resources to a new provider without requiring them to be
   re-created.

website/docs/cli/state/recover.html.md

@@ -9,7 +9,7 @@ If something has gone horribly wrong (possibly due to accidents when performing
 other state manipulation actions), you might need to take drastic actions with
 your state data.
 
-- [The `terraform force-unlock` command](/docs/commands/force-unlock.html) can
+- [The `terraform force-unlock` command](/docs/cli/commands/force-unlock.html) can
   override the protections Terraform uses to prevent two processes from
   modifying state at the same time. You might need this if a Terraform process
   (like a normal apply) is unexpectedly terminated (like by the complete
@@ -17,8 +17,8 @@ your state data.
   state backend. Do not run this until you are completely certain what happened
   to the process that caused the lock to get stuck.
 
-- [The `terraform state pull` command](/docs/commands/state/pull.html) and
-  [the `terraform state push` command](/docs/commands/state/push.html) can
+- [The `terraform state pull` command](/docs/cli/commands/state/pull.html) and
+  [the `terraform state push` command](/docs/cli/commands/state/push.html) can
   directly read and write entire state files from and to the configured backend.
   You might need this for obtaining or restoring a state backup.
 

website/docs/cli/state/taint.html.md

@@ -16,10 +16,10 @@ happen during creation; for example, a virtual machine that configures itself
 with `cloud-init` on startup might no longer meet your needs if the cloud-init
 configuration changes.
 
-- [The `terraform taint` command](/docs/commands/taint.html) tells Terraform to
+- [The `terraform taint` command](/docs/cli/commands/taint.html) tells Terraform to
   destroy and re-create a particular resource during the next apply, regardless
   of whether its resource arguments would normally require that.
 
-- [The `terraform untaint` command](/docs/commands/untaint.html) undoes a
+- [The `terraform untaint` command](/docs/cli/commands/untaint.html) undoes a
   previous taint, or can preserve a resource that was automatically tainted due
-  to failed [provisioners](/docs/provisioners/index.html).
+  to failed [provisioners](/docs/language/resources/provisioners/syntax.html).

website/docs/cli/workspaces/index.html.md

@@ -6,7 +6,7 @@ page_title: "Managing Workspaces - Terraform CLI"
 # Managing Workspaces
 
 In Terraform CLI, _workspaces_ are separate instances of
-[state data](/docs/state/index.html) that can be used from the same working
+[state data](/docs/language/state/index.html) that can be used from the same working
 directory. You can use workspaces to manage multiple non-overlapping groups of
 resources with the same configuration.
 
@@ -17,11 +17,11 @@ resources with the same configuration.
 - Most Terraform commands (including [provisioning](/docs/cli/run/index.html)
   and [state manipulation](/docs/cli/state/index.html) commands) only interact
   with the currently selected workspace.
-- Use [the `terraform workspace select` command](/docs/commands/workspace/select.html)
+- Use [the `terraform workspace select` command](/docs/cli/commands/workspace/select.html)
   to change the currently selected workspace.
-- Use the [`terraform workspace list`](/docs/commands/workspace/list.html),
-  [`terraform workspace new`](/docs/commands/workspace/new.html), and
-  [`terraform workspace delete`](/docs/commands/workspace/delete.html) commands
+- Use the [`terraform workspace list`](/docs/cli/commands/workspace/list.html),
+  [`terraform workspace new`](/docs/cli/commands/workspace/new.html), and
+  [`terraform workspace delete`](/docs/cli/commands/workspace/delete.html) commands
   to manage the available workspaces in the current working directory.
 
 -> **Note:** Terraform Cloud and Terraform CLI both have features called
@@ -34,11 +34,11 @@ Since most of the resources you can manage with Terraform don't include a unique
 name as part of their configuration, it's common to use the same Terraform
 configuration to provision multiple groups of similar resources.
 
-Terraform relies on [state](/docs/state/index.html) to associate resources with
+Terraform relies on [state](/docs/language/state/index.html) to associate resources with
 real-world objects, so if you run the same configuration multiple times with
 completely separate state data, Terraform can manage many non-overlapping groups
 of resources. In some cases you'll want to change
-[variable values](/docs/configuration/variables.html) for these different
+[variable values](/docs/language/values/variables.html) for these different
 resource collections (like when specifying differences between staging and
 production deployments), and in other cases you might just want many instances
 of a particular infrastructure pattern.
@@ -46,7 +46,7 @@ of a particular infrastructure pattern.
 The simplest way to maintain multiple instances of a configuration with
 completely separate state data is to use multiple
 [working directories](/docs/cli/init/index.html) (with different
-[backend](/docs/configuration/backend.html) configurations per directory, if you
+[backend](/docs/language/settings/backends/configuration.html) configurations per directory, if you
 aren't using the default `local` backend).
 
 However, this isn't always the most _convenient_ way to handle separate states.
@@ -70,7 +70,7 @@ data, run history, and settings.
 These two kinds of workspaces are different, but related. When using Terraform
 CLI as a frontend for Terraform Cloud, you associate the current working
 directory with one or more remote workspaces by configuring
-[the `remote` backend](/docs/backends/types/remote.html). If you associate the
+[the `remote` backend](/docs/language/settings/backends/remote.html). If you associate the
 directory with multiple workspaces (using a name prefix), you can use the
 `terraform workspace` commands to select which remote workspace to use.
 

website/docs/commands/state/addressing.html.md

@@ -1,20 +0,0 @@
----
-layout: "docs"
-page_title: "Command: state resource addressing"
-sidebar_current: "docs-commands-state-address"
-description: |-
-  The `terraform state` command is used for advanced state management.
----
-
-# Resource Addressing
-
-The `terraform state` subcommands use
-[standard address syntax](/docs/internals/resource-addressing.html) to refer
-to individual resources, resource instances, and modules. This is the same
-syntax used for the `-target` option to the `apply` and `plan` commands.
-
-Most state commands allow referring to individual resource instances, whole
-resources (which may have multiple instances if `count` or `for_each` is used),
-or even whole modules.
-
-For more information on the syntax, see [Resource Addressing](/docs/internals/resource-addressing.html).

website/docs/configuration-0-11/data-sources.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Configuring Data Sources](../configuration/data-sources.html).
+[Configuration Language: Configuring Data Sources](/docs/language/data-sources/index.html).
 
 *Data sources* allow data to be fetched or computed for use elsewhere
 in Terraform configuration. Use of data sources allows a Terraform

website/docs/configuration-0-11/environment-variables.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Commands: Environment Variables](../commands/environment-variables.html).
+[Commands: Environment Variables](/docs/cli/config/environment-variables.html).
 
 ## TF_LOG
 
@@ -48,7 +48,7 @@ export TF_INPUT=0
 
 ## TF_MODULE_DEPTH
 
-When given a value, causes terraform commands to behave as if the `-module-depth=VALUE` flag was specified. By setting this to 0, for example, you enable commands such as [plan](/docs/commands/plan.html) and [graph](/docs/commands/graph.html) to display more compressed information.
+When given a value, causes terraform commands to behave as if the `-module-depth=VALUE` flag was specified. By setting this to 0, for example, you enable commands such as [plan](/docs/cli/commands/plan.html) and [graph](/docs/cli/commands/graph.html) to display more compressed information.
 
 ```shell
 export TF_MODULE_DEPTH=0

website/docs/configuration-0-11/index.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language](../configuration/index.html).
+[Configuration Language](/docs/language/index.html).
 
 Terraform uses text files to describe infrastructure and to set variables.
 These text files are called Terraform _configurations_ and end in

website/docs/configuration-0-11/interpolation.html.md

@@ -10,8 +10,8 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Expressions](/docs/configuration/expressions/index.html) and
-[Configuration Language: Functions](../configuration/functions.html).
+[Configuration Language: Expressions](/docs/language/expressions/index.html) and
+[Configuration Language: Functions](/docs/language/functions/index.html).
 
 Embedded within strings in Terraform, whether you're using the
 Terraform syntax or JSON syntax, you can interpolate other values. These
@@ -77,7 +77,7 @@ syntax to get a list of all the attributes: `${data.aws_subnet.example.*.cidr_bl
 
 The syntax is `module.<NAME>.<OUTPUT>`. For example `${module.foo.bar}` will
 interpolate the `bar` output from the `foo`
-[module](/docs/modules/index.html).
+[module](/docs/language/modules/develop/index.html).
 
 #### Count information
 
@@ -98,7 +98,7 @@ path of the root module.  In general, you probably want the
 
 The syntax is `terraform.<FIELD>`. This variable type contains metadata about
 the currently executing Terraform run. FIELD can currently only be `env` to
-reference the currently active [state environment](/docs/state/environments.html).
+reference the currently active workspace.
 
 ## Conditionals
 
@@ -560,7 +560,7 @@ Operator precedences is the standard mathematical order of operations:
 "${2 * (4 + 3) * 3}" # computes to 42
 ```
 
-You can use the [terraform console](/docs/commands/console.html) command to
+You can use the [terraform console](/docs/cli/commands/console.html) command to
 try the math operations.
 
 -> **Note:** Since Terraform allows hyphens in resource and variable names,

website/docs/configuration-0-11/load.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language](../configuration/index.html).
+[Configuration Language](/docs/language/index.html).
 
 When invoking any command that loads the Terraform configuration,
 Terraform loads all configuration files within the directory

website/docs/configuration-0-11/locals.html.md

@@ -11,7 +11,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Configuring Local Values](../configuration/locals.html).
+[Configuration Language: Configuring Local Values](/docs/language/values/locals.html).
 
 Local values assign a name to an expression, that can then be used multiple
 times within a module.

website/docs/configuration-0-11/modules.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Modules](../configuration/modules.html).
+[Configuration Language: Modules](/docs/language/modules/index.html).
 
 A _module_ is a container for multiple resources that are used together.
 
@@ -27,7 +27,7 @@ and re-used.
 This page describes how to call one module from another. Other pages in this
 section of the documentation describe the different elements that make up
 modules, and there is further information about how modules can be used,
-created, and published in [the dedicated _Modules_ section](/docs/modules/index.html).
+created, and published in [the dedicated _Modules_ section](/docs/language/modules/develop/index.html).
 
 ## Calling a Child Module
 
@@ -62,7 +62,7 @@ Terraform CLI. Its value is either the path to a local directory of the
 module's configuration files, or a remote module source that Terraform should
 download and use. This value must be a literal string with no template
 sequences; interpolations are not allowed. For more information on
-possible values for this argument, see [Module Sources](/docs/modules/sources.html).
+possible values for this argument, see [Module Sources](/docs/language/modules/sources.html).
 
 The same source address can be specified in multiple `module` blocks to create
 multiple copies of the resources defined within, possibly with different
@@ -161,7 +161,7 @@ future features.
 
 Since modules are a complex feature in their own right, further detail
 about how modules can be used, created, and published is included in
-[the dedicated section on modules](/docs/modules/index.html).
+[the dedicated section on modules](/docs/language/modules/develop/index.html).
 
 ## Providers within Modules
 
@@ -386,7 +386,7 @@ giving each instance a unique name -- here `module "assets_bucket"` and
 Resources from child modules are prefixed with `module.<module-instance-name>`
 when displayed in plan output and elsewhere in the UI. For example, the
 `./publish_bucket` module contains `aws_s3_bucket.example`, and so the two
-instances of this module produce S3 bucket resources with [_resource addresses_](/docs/internals/resource-addressing.html)
+instances of this module produce S3 bucket resources with [_resource addresses_](/docs/cli/state/resource-addressing.html)
 `module.assets_bucket.aws_s3_bucket.example` and `module.media_bucket.aws_s3_bucket.example`
 respectively. These full addresses are used within the UI and on the command
 line, but are not valid within interpolation expressions due to the
@@ -405,7 +405,7 @@ several regions or datacenters.
 
 ## Tainting resources within a module
 
-The [taint command](/docs/commands/taint.html) can be used to _taint_ specific
+The [taint command](/docs/cli/commands/taint.html) can be used to _taint_ specific
 resources within a module:
 
 ```shell

website/docs/configuration-0-11/outputs.html.md

@@ -10,11 +10,11 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Output Values](../configuration/outputs.html).
+[Configuration Language: Output Values](/docs/language/values/outputs.html).
 
 Outputs define values that will be highlighted to the user
 when Terraform applies, and can be queried easily using the
-[output command](/docs/commands/output.html).
+[output command](/docs/cli/commands/output.html).
 
 Terraform knows a lot about the infrastructure it manages.
 Most resources have attributes associated with them, and

website/docs/configuration-0-11/override.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Override Files](../configuration/override.html).
+[Configuration Language: Override Files](/docs/language/files/override.html).
 
 Terraform loads all configuration files within a directory and
 appends them together. Terraform also has a concept of _overrides_,

website/docs/configuration-0-11/providers.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Providers](../configuration/providers.html).
+[Configuration Language: Providers](/docs/language/providers/index.html).
 
 Providers are responsible in Terraform for managing the lifecycle
 of a [resource](./resources.html): create,
@@ -79,7 +79,7 @@ distributed by HashiCorp. See [Third-party Plugins](#third-party-plugins) below
 for installation instructions.
 
 For more information, see
-[the `terraform init` command](/docs/commands/init.html).
+[the `terraform init` command](/docs/cli/commands/init.html).
 
 ## Provider Versions
 
@@ -118,7 +118,7 @@ provider "aws" {
 ```
 
 This special argument applies to _all_ providers.
-[`terraform providers`](/docs/commands/providers.html) can be used to
+[`terraform providers`](/docs/cli/commands/providers.html) can be used to
 view the specified version constraints for all providers used in the
 current configuration.
 
@@ -295,7 +295,7 @@ use of a local directory as a shared plugin cache, which then allows each
 distinct plugin binary to be downloaded only once.
 
 To enable the plugin cache, use the `plugin_cache_dir` setting in
-[the CLI configuration file](https://www.terraform.io/docs/commands/cli-config.html).
+[the CLI configuration file](https://www.terraform.io/docs/cli/config/config-file.html).
 For example:
 
 ```hcl

website/docs/configuration-0-11/resources.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Resources](../configuration/resources.html).
+[Configuration Language: Resources](/docs/language/resources/index.html).
 
 The most important thing you'll configure with Terraform are
 resources. Resources are a component of your infrastructure.
@@ -176,7 +176,7 @@ could automatically do this a better way.
 Within a resource, you can optionally have a **connection block**.
 Connection blocks describe to Terraform how to connect to the
 resource for
-[provisioning](/docs/provisioners/index.html). This block doesn't
+[provisioning](/docs/language/resources/provisioners/syntax.html). This block doesn't
 need to be present if you're using only local provisioners, or
 if you're not provisioning at all.
 
@@ -184,13 +184,13 @@ Resources provide some data on their own, such as an IP address,
 but other data must be specified by the user.
 
 The full list of settings that can be specified are listed on
-the [provisioner connection page](/docs/provisioners/connection.html).
+the [provisioner connection page](/docs/language/resources/provisioners/connection.html).
 
 ### Provisioners
 
 Within a resource, you can specify zero or more **provisioner
 blocks**. Provisioner blocks configure
-[provisioners](/docs/provisioners/index.html).
+[provisioners](/docs/language/resources/provisioners/syntax.html).
 
 Within the provisioner block is provisioner-specific configuration,
 much like resource-specific configuration.

website/docs/configuration-0-11/syntax.html.md

@@ -14,7 +14,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Syntax](../configuration/syntax.html).
+[Configuration Language: Syntax](/docs/language/syntax/configuration.html).
 
 The syntax of Terraform configurations is called [HashiCorp Configuration
 Language (HCL)](https://github.com/hashicorp/hcl). It is meant to strike a

website/docs/configuration-0-11/terraform-enterprise.html.md

@@ -13,9 +13,9 @@ feature that was removed in Terraform 0.12.
 
 ~> **Important:** The `terraform push` command is deprecated, and only works with the legacy version of Terraform Enterprise. In the current version of Terraform Cloud, you can upload configurations using the API. See [the docs about API-driven runs](/docs/cloud/run/api.html) for more details.
 
-The [`terraform push` command](/docs/commands/push.html) uploads a configuration to a Terraform Enterprise (legacy) environment. The name of the environment (and the organization it's in) can be specified on the command line, or as part of the Terraform configuration in an `atlas` block.
+The [`terraform push` command](/docs/cli/commands/push.html) uploads a configuration to a Terraform Enterprise (legacy) environment. The name of the environment (and the organization it's in) can be specified on the command line, or as part of the Terraform configuration in an `atlas` block.
 
-The `atlas` block does not configure remote state; it only configures the push command. For remote state, [use a `terraform { backend "<NAME>" {...} }` block](/docs/backends/config.html).
+The `atlas` block does not configure remote state; it only configures the push command. For remote state, use a `terraform { backend "<NAME>" {...} }` block.
 
 This page assumes you're familiar with the
 [configuration syntax](./syntax.html)
@@ -40,7 +40,7 @@ Enterprise**. While this transition is in progress, you may see references to
 ## Description
 
 The `atlas` block configures the settings when Terraform is
-[pushed](/docs/commands/push.html) to Terraform Enterprise. Only one `atlas` block
+[pushed](/docs/cli/commands/push.html) to Terraform Enterprise. Only one `atlas` block
 is allowed.
 
 Within the block (the `{ }`) is configuration for Atlas uploading.
@@ -50,7 +50,7 @@ No keys are required, but the key typically set is `name`.
 to the nature of this configuration, interpolations are not possible.
 If you want to parameterize these settings, use the Atlas block to
 set defaults, then use the command-line flags of the
-[push command](/docs/commands/push.html) to override.
+[push command](/docs/cli/commands/push.html) to override.
 
 ## Syntax
 

website/docs/configuration-0-11/terraform.html.md

@@ -10,7 +10,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Terraform Settings](../configuration/terraform.html).
+[Configuration Language: Terraform Settings](/docs/language/settings/index.html).
 
 The `terraform` configuration section is used to configure Terraform itself,
 such as requiring a minimum Terraform version to execute a configuration.
@@ -41,7 +41,7 @@ that must be met to perform operations on this configuration. If the
 running Terraform version doesn't meet these constraints, an error
 is shown. See the section below dedicated to this option.
 
-See [backends](/docs/backends/index.html) for more detail on the `backend`
+See [backends](/docs/language/settings/backends/configuration.html) for more detail on the `backend`
 configuration.
 
 **No value within the `terraform` block can use interpolations.** The

website/docs/configuration-0-11/variables.html.md

@@ -11,7 +11,7 @@ description: |-
 
 -> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
 and later, see
-[Configuration Language: Input Variables](../configuration/variables.html).
+[Configuration Language: Input Variables](/docs/language/values/variables.html).
 
 Input variables serve as parameters for a Terraform module.
 

website/docs/configuration/expressions.html.md

@@ -21,7 +21,7 @@ Terraform's types are `string`, `number`, `bool`, `list`, `tuple`, `map`,
 `object`, and `null`.
 
 This information has moved to
-[Types and Values](/docs/configuration/expressions/types.html).
+[Types and Values](/docs/language/expressions/types.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -40,7 +40,7 @@ You can refer to certain values by name, like `var.some_variable` or
 `aws_instance.example.ami`.
 
 This information has moved to
-[References to Values](/docs/configuration/expressions/references.html).
+[References to Values](/docs/language/expressions/references.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -57,7 +57,7 @@ Operators are expressions that transform other expressions, like adding two
 numbers (`+`) or comparing two values to get a bool (`==`, `>=`, etc.).
 
 This information has moved to
-[Operators](/docs/configuration/expressions/references.html).
+[Operators](/docs/language/expressions/references.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -69,7 +69,7 @@ The `condition ? true_val : false_val` expression chooses between two
 expressions based on a bool condition.
 
 This information has moved to
-[Conditional Expressions](/docs/configuration/expressions/conditionals.html).
+[Conditional Expressions](/docs/language/expressions/conditionals.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -83,7 +83,7 @@ This information has moved to
 Terraform's functions can be called like `function_name(arg1, arg2)`.
 
 This information has moved to
-[Function Calls](/docs/configuration/expressions/function-calls.html).
+[Function Calls](/docs/language/expressions/function-calls.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -97,7 +97,7 @@ Expressions like `[for s in var.list : upper(s)]` can transform a complex type
 value into another complex type value.
 
 This information has moved to
-[For Expressions](/docs/configuration/expressions/for.html).
+[For Expressions](/docs/language/expressions/for.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -112,7 +112,7 @@ Expressions like `var.list[*].id` can extract simpler collections from complex
 collections.
 
 This information has moved to
-[Splat Expressions](/docs/configuration/expressions/splat.html).
+[Splat Expressions](/docs/language/expressions/splat.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -127,7 +127,7 @@ The special `dynamic` block type serves the same purpose as a `for` expression,
 except it creates multiple repeatable nested blocks instead of a complex value.
 
 This information has moved to
-[Dynamic Blocks](/docs/configuration/expressions/dynamic-blocks.html).
+[Dynamic Blocks](/docs/language/expressions/dynamic-blocks.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -152,6 +152,6 @@ Strings can also include escape sequences like `\n`, interpolation sequences
 (`${ ... }`), and template sequences (`%{ ... }`).
 
 This information has moved to
-[Strings and Templates](/docs/configuration/expressions/strings.html).
+[Strings and Templates](/docs/language/expressions/strings.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>

website/docs/configuration/modules.html.md

@@ -18,7 +18,7 @@ pages.
 ## Syntax and Elements of Module Blocks
 
 This information has moved to
-[Module Blocks](/docs/configuration/blocks/modules/syntax.html).
+[Module Blocks](/docs/language/modules/syntax.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -29,8 +29,8 @@ This information has moved to
 ## Multiple Instances with `count` and `for_each`
 
 This information has moved to
-[`count`](/docs/configuration/meta-arguments/count.html) and
-[`for_each`](/docs/configuration/meta-arguments/for_each.html).
+[`count`](/docs/language/meta-arguments/count.html) and
+[`for_each`](/docs/language/meta-arguments/for_each.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -46,9 +46,9 @@ This information has moved to
 ## Handling Provider Configurations in Re-usable Modules
 
 This information has moved to
-[The `providers` Meta-Argument](/docs/configuration/meta-arguments/module-providers.html)
+[The `providers` Meta-Argument](/docs/language/meta-arguments/module-providers.html)
 (for users of re-usable modules) and
-[Providers Within Modules](/docs/modules/providers.html)
+[Providers Within Modules](/docs/language/modules/develop/providers.html)
 (for module developers).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>

website/docs/configuration/resources.html.md

@@ -20,7 +20,7 @@ pages.
 ## Syntax and Elements of Resource Blocks
 
 This information has moved to
-[Resource Blocks](/docs/configuration/blocks/resources/syntax.html).
+[Resource Blocks](/docs/language/resources/syntax.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -34,7 +34,7 @@ This information has moved to
 ## Details of Resource Behavior
 
 This information has moved to
-[Resource Behavior](/docs/configuration/blocks/resources/behavior.html).
+[Resource Behavior](/docs/language/resources/behavior.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -44,12 +44,12 @@ This information has moved to
 
 Each resource meta-argument has moved to its own page:
 
-- [`depends_on`](/docs/configuration/meta-arguments/depends_on.html)
-- [`count`](/docs/configuration/meta-arguments/count.html)
-- [`for_each`](/docs/configuration/meta-arguments/for_each.html)
-- [`provider`](/docs/configuration/meta-arguments/resource-provider.html)
-- [`lifecycle`](/docs/configuration/meta-arguments/lifecycle.html)
-- [Provisioners](/docs/configuration/blocks/resources/provisioners/index.html)
+- [`depends_on`](/docs/language/meta-arguments/depends_on.html)
+- [`count`](/docs/language/meta-arguments/count.html)
+- [`for_each`](/docs/language/meta-arguments/for_each.html)
+- [`provider`](/docs/language/meta-arguments/resource-provider.html)
+- [`lifecycle`](/docs/language/meta-arguments/lifecycle.html)
+- [Provisioners](/docs/language/resources/provisioners/index.html)
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -60,7 +60,7 @@ Each resource meta-argument has moved to its own page:
 ### `depends_on`
 
 This information has moved to
-[`depends_on`](/docs/configuration/meta-arguments/depends_on.html).
+[`depends_on`](/docs/language/meta-arguments/depends_on.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -77,7 +77,7 @@ This information has moved to
 ### `count`
 
 This information has moved to
-[`count`](/docs/configuration/meta-arguments/count.html).
+[`count`](/docs/language/meta-arguments/count.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -94,7 +94,7 @@ This information has moved to
 ### `for_each`
 
 This information has moved to
-[`for_each`](/docs/configuration/meta-arguments/for_each.html).
+[`for_each`](/docs/language/meta-arguments/for_each.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -105,7 +105,7 @@ This information has moved to
 ### `provider`
 
 This information has moved to
-[`provider`](/docs/configuration/meta-arguments/resource-provider.html).
+[`provider`](/docs/language/meta-arguments/resource-provider.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -119,7 +119,7 @@ This information has moved to
 ### `lifecycle`
 
 This information has moved to
-[`lifecycle`](/docs/configuration/meta-arguments/lifecycle.html).
+[`lifecycle`](/docs/language/meta-arguments/lifecycle.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>
 
@@ -130,6 +130,6 @@ This information has moved to
 ### Provisioners
 
 This information has moved to
-[Provisioners](/docs/configuration/blocks/resources/provisioners/index.html).
+[Provisioners](/docs/language/resources/provisioners/index.html).
 
 <div style="height: 100vh; margin: 0; padding: 0;"></div>

website/docs/internals/credentials-helpers.html.md

@@ -12,7 +12,7 @@ For Terraform-specific features that interact with remote network services,
 such as [module registries](/docs/registry/) and
 [remote operations](/docs/cloud/run/cli.html), Terraform by default looks for
 API credentials to use in these calls in
-[the CLI configuration](/docs/commands/cli-config.html).
+[the CLI configuration](/docs/cli/config/config-file.html).
 
 Credentials helpers offer an alternative approach that allows you to customize
 how Terraform obtains credentials using an external program, which can then
@@ -20,7 +20,7 @@ directly access an existing secrets management system in your organization.
 
 This page is about how to write and install a credentials helper. To learn
 how to configure a credentials helper that was already installed, see
-[the CLI config Credentials Helpers section](/docs/commands/cli-config.html#credentials-helpers).
+[the CLI config Credentials Helpers section](/docs/cli/config/config-file.html#credentials-helpers).
 
 ## How Terraform finds Credentials Helpers
 
@@ -57,7 +57,7 @@ The current set of verbs are:
 
 To represent credentials, the credentials helper protocol uses a JSON object
 whose contents correspond with the contents of
-[`credentials` blocks in the CLI configuration](/docs/commands/cli-config.html#credentials).
+[`credentials` blocks in the CLI configuration](/docs/cli/config/config-file.html#credentials).
 To represent an API token, the object contains a property called "token" whose
 value is the token string:
 

website/docs/internals/graph.html.md

@@ -108,8 +108,8 @@ The amount of parallelism is limited using a semaphore to prevent too many
 concurrent operations from overwhelming the resources of the machine running
 Terraform. By default, up to 10 nodes in the graph will be processed
 concurrently. This number can be set using the `-parallelism` flag on the
-[plan](/docs/commands/plan.html), [apply](/docs/commands/apply.html), and
-[destroy](/docs/commands/destroy.html) commands.
+[plan](/docs/cli/commands/plan.html), [apply](/docs/cli/commands/apply.html), and
+[destroy](/docs/cli/commands/destroy.html) commands.
 
 Setting `-parallelism` is considered an advanced operation and should not be
 necessary for normal usage of Terraform. It may be helpful in certain special

website/docs/internals/json-format.html.md

@@ -14,7 +14,7 @@ When Terraform plans to make changes, it prints a human-readable summary to the
 
 Since the format of plan files isn't suited for use with external tools (and likely never will be), Terraform can output a machine-readable JSON representation of a plan file's changes. It can also convert state files to the same format, to simplify data loading and provide better long-term compatibility.
 
-Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/docs/commands/show.html) for more details.
+Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/docs/cli/commands/show.html) for more details.
 
 -> **Note:** The output includes a `format_version` key, which currently has major version zero to indicate that the format is experimental and subject to change. A future version will assign a non-zero major version and make stronger promises about compatibility. We do not anticipate any significant breaking changes to the format before its first major version, however.
 
@@ -244,7 +244,7 @@ The following example illustrates the structure of a `<values-representation>`:
 }
 ```
 
-The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by Terraform's [`jsonencode`](/docs/configuration/functions/jsonencode.html) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
+The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by Terraform's [`jsonencode`](/docs/language/functions/jsonencode.html) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
 
 Only the "current" object for each resource instance is described. "Deposed" objects are not reflected in this structure at all; in plan representations, you can refer to the change representations for further details.