migrate docs to mdx

website/README.md

@@ -8,39 +8,36 @@ The files in this directory are intended to be used in conjunction with
 different documentation sources together and contains the scripts for testing and building the site as
 a whole.
 
+## Modifying Sidebar Navigation
+
+Updates to the sidebar navigation of Terraform docs need to be made in the [`terraform-website`](https://github.com/hashicorp/terraform-website/) repository (preferrably in a PR also updating the submodule commit). You can read more about how to make modifications to the navigation in the [README for `terraform-website`](https://github.com/hashicorp/terraform-website#editing-navigation-sidebars).
+
 ## Previewing Changes
 
-You should preview all of your changes locally before creating a pull request. The build includes content from this repository and the [`terraform-website`](https://github.com/hashicorp/terraform-website/) repository, allowing you to preview the entire Terraform documentation site. If `terraform-website` isn't in your `GOPATH`, the preview command will clone it to your machine.
+You should preview all of your changes locally before creating a pull request. The build includes content from this repository and the [`terraform-website`](https://github.com/hashicorp/terraform-website/) repository, allowing you to preview the entire Terraform documentation site.
 
 **Set Up Local Environment**
 
 1. [Install Docker](https://docs.docker.com/get-docker/).
-2. Create a `~/go` directory manually or by [installing Go](https://golang.org/doc/install).
-3. Open terminal and set `GOPATH` as an environment variable:
-
-    Bash: `export $GOPATH=~/go`(bash)
-
-    Zsh: `echo -n 'export GOPATH=~/go' >> ~/.zshrc`
-4. Restart your terminal or command line session.
+1. Restart your terminal or command line session.
 
 **Launch Site Locally**
 
 1. Navigate into your local `terraform` top-level directory and run `make website`.
-2. Open `http://localhost:4567` in your web browser. While the preview is running, you can edit pages and Middleman will automatically rebuild them.
-3. When you're done with the preview, press `ctrl-C` in your terminal to stop the server.
+1. Open `http://localhost:4567` in your web browser. While the preview is running, you can edit pages and Next.js will automatically rebuild them.
+1. When you're done with the preview, press `ctrl-C` in your terminal to stop the server.
 
 ## Deploying Changes
 
 Merge the PR to main. The changes will appear in the next major Terraform release.
 
 If you need your changes to be deployed sooner, cherry-pick them to:
-- the current release branch (e.g. `v1.0`) and push. They will be deployed in the next minor version release (once every two weeks).
-- the `stable-website` branch and push. They will be included in the next site deploy (see below). Note that the release process resets `stable-website` to match the release tag, removing any additional commits. So, we recommend always cherry-picking to the version branch first and then to `stable-website` when needed.
+
+- the current release branch (e.g. `v1.1`) and push. They will be deployed in the next minor version release (once every two weeks).
+- the `stable-website` branch and push. They will be included in the next site deploy (see below). Note that the release process resets `stable-website` to match the release tag, removing any additional commits. So, we recommend always cherry-picking to the version branch first and then to `stable-website` when needed.
+
+Once your PR to `stable-website` is merged, open a PR bumping the submodule commit in [`terraform-website`](https://github.com/hashicorp/terraform-website).
 
 ### Deployment
-Currently, HashiCorp uses a CircleCI job to deploy the [terraform.io](terraform.io) site. This job can be run manually by many people within HashiCorp, and also runs automatically whenever a user in the HashiCorp GitHub org merges changes to master in the `terraform-website` repository.
 
-New commits in this repository don't automatically deploy the [terraform.io][] site, but an unrelated site deploy will usually happen within a day. If you can't wait that long, you can do a manual CircleCI build or ask someone in the #proj-terraform-docs channel to do so:
-- Log in to circleci.com, and  make sure you're viewing the HashiCorp organization.
-- Go to the terraform-website project's list of workflows.
-- Find the most recent "website-deploy" workflow, and click the "Rerun workflow from start" button (which looks like a refresh button with a numeral "1" inside).
+New commits in `hashicorp/terraform` and `hashicorp/terraform-cdk` don't automatically deploy the site. To use the latest upstream content, you'll need to open a PR bumping the submodule commit. If your changes aren't being deployed, it's very likely that you need to open a PR to update the submodule commit.

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

 ---
-layout: "docs"
-page_title: "Authentication - Terraform CLI"
-description: "Documentation about the login and logout commands that help automate getting an API token for your Terraform Cloud account."
+page_title: Authentication - Terraform CLI
+description: >-
+  Documentation about the login and logout commands that help automate getting
+  an API token for your Terraform Cloud account.
 ---
 
 # CLI Authentication
 
 > **Hands-on:** Try the [Authenticate the CLI with Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-login?in=terraform/cloud&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn.
 
-[Terraform Cloud](/docs/cloud/index.html) and
-[Terraform Enterprise](/docs/enterprise/index.html) are platforms that perform
+[Terraform Cloud](/cloud) and
+[Terraform Enterprise](/enterprise) are platforms that perform
 Terraform runs to provision infrastructure, offering a collaboration-focused
 environment that makes it easier for teams to use Terraform together. (For
 expediency, the content below refers to both products as "Terraform Cloud.")
 
 Terraform CLI integrates with Terraform Cloud in several ways — it can be a
-front-end for [CLI-driven runs](/docs/cloud/run/cli.html) in Terraform Cloud,
+front-end for [CLI-driven runs](/cloud-docs/run/cli) in Terraform Cloud,
 and can also use Terraform Cloud as a state backend and a private module
 registry. All of these integrations require you to authenticate Terraform CLI
 with your Terraform Cloud account.
@@ -26,5 +27,5 @@ Terraform Cloud user account.
 
 For details, see:
 
-- [The `terraform login` command](/docs/cli/commands/login.html)
-- [The `terraform logout` command](/docs/cli/commands/logout.html)
+- [The `terraform login` command](/cli/commands/login)
+- [The `terraform logout` command](/cli/commands/logout)

website/docs/cli/cloud/command-line-arguments.html.md → website/docs/cli/cloud/command-line-arguments.mdx

 ---
-layout: "docs"
-page_title: "Command Line Arguments"
-description: "Command Line Arguments"
+page_title: Command Line Arguments
+description: Command Line Arguments
 ---
 
 # Command Line Arguments
@@ -14,13 +13,12 @@ accept the following option to modify that behavior:
   Terraform versions agree, making an operation proceed even when there is
   a mismatch.
 
-    State-modification operations usually require using a local version of the
-    Terraform CLI that is compatible with the Terraform version selected
-    in the remote workspace settings. This prevents the
-    local operation from creating a new state snapshot that the workspace's
-    remote execution environment cannot decode.
-
-    We recommend against using this option unless absolutely necessary. Overriding this check can result 
-     in a Terraform Cloud workspace that is no longer able to complete remote operations with the currently 
-     selected version of Terraform.
+  State-modification operations usually require using a local version of the
+  Terraform CLI that is compatible with the Terraform version selected
+  in the remote workspace settings. This prevents the
+  local operation from creating a new state snapshot that the workspace's
+  remote execution environment cannot decode.
 
+  We recommend against using this option unless absolutely necessary. Overriding this check can result
+  in a Terraform Cloud workspace that is no longer able to complete remote operations with the currently
+  selected version of Terraform.

website/docs/cli/cloud/index.html.md → website/docs/cli/cloud/index.mdx

 ---
-layout: "docs"
-page_title: "Using Terraform Cloud - Terraform CLI"
+page_title: Using Terraform Cloud - Terraform CLI
 ---
 
 # Using Terraform Cloud with Terraform CLI
 
 The Terraform CLI's integration with Terraform Cloud lets you to use Terraform Cloud and Terraform Enterprise on the command line. In the documentation Terraform Cloud instructions also apply to Terraform Enterprise, except where explicitly stated.
 
-Using Terraform Cloud through the command line is called the [CLI-driven run workflow](/docs/cloud/run/cli.html). When you use the CLI workflow, operations like `terraform plan` or `terraform apply` are remotely executed in Terraform Cloud's run environment by default, with log output streaming to the local terminal. This lets you use Terraform Cloud features within the familiar Terraform CLI workflow, including variables encrypted at rest in a Terraform Cloud workspace, cost estimates, and policy checking.
+Using Terraform Cloud through the command line is called the [CLI-driven run workflow](/cloud-docs/run/cli). When you use the CLI workflow, operations like `terraform plan` or `terraform apply` are remotely executed in Terraform Cloud's run environment by default, with log output streaming to the local terminal. This lets you use Terraform Cloud features within the familiar Terraform CLI workflow, including variables encrypted at rest in a Terraform Cloud workspace, cost estimates, and policy checking.
 
 > **Hands On:** Try the [Migrate State to Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-migrate) tutorial on HashiCorp Learn.
 
 Workspaces can also be configured for local execution, in which case only state is stored in
 Terraform Cloud. In this mode, Terraform Cloud behaves just like a standard state backend.
 
--> **Note:** The CLI integration is available in Terraform 1.1.0 and later, and Terraform Enterprise 202201-1 and later. Previous versions can use the [`remote` backend](/docs/language/settings/backends/remote.html). Refer to [Migrating from the remote
-backend](/docs/cli/cloud/migrating.html) for details about switching to the CLI integration.
-
+-> **Note:** The CLI integration is available in Terraform 1.1.0 and later, and Terraform Enterprise 202201-1 and later. Previous versions can use the [`remote` backend](/language/settings/backends/remote). Refer to [Migrating from the remote
+backend](/cli/cloud/migrating) for details about switching to the CLI integration.
 
 ## Documentation Summary
 
-- [Terraform Cloud Settings](/docs/cli/cloud/settings.html) documents the `cloud` block that you must add to your configuration to enable Terraform Cloud support.
-- [Initializing and Migrating](/docs/cli/cloud/migrating.html) describes
-how to start using Terraform Cloud with a working directory that already has state data.
-- [Command Line Arguments](/docs/cli/cloud/command-line-arguments.html) lists the Terraform command flags that are specific to using Terraform with Terraform Cloud.
+- [Terraform Cloud Settings](/cli/cloud/settings) documents the `cloud` block that you must add to your configuration to enable Terraform Cloud support.
+- [Initializing and Migrating](/cli/cloud/migrating) describes
+  how to start using Terraform Cloud with a working directory that already has state data.
+- [Command Line Arguments](/cli/cloud/command-line-arguments) lists the Terraform command flags that are specific to using Terraform with Terraform Cloud.
 
-Refer to the [CLI-driven Run Workflow](/docs/cloud/run/cli.html) for more details about how to use Terraform Cloud from the command line.
+Refer to the [CLI-driven Run Workflow](/cloud-docs/run/cli) for more details about how to use Terraform Cloud from the command line.

website/docs/cli/cloud/migrating.html.md → website/docs/cli/cloud/migrating.mdx

 ---
-layout: "docs"
-page_title: "Initializing and Migrating to Terraform Cloud - Terraform CLI"
+page_title: Initializing and Migrating to Terraform Cloud - Terraform CLI
 ---
 
 # Initializing and Migrating
 
-After [configuring Terraform Cloud settings](/docs/cli/cloud/settings.html) for a working directory, you must run `terraform init` to finish setting up. If the working directory has no existing Terraform state, you can start using Terraform with Terraform Cloud right away. Refer to [CLI-driven run workflow](/docs/cloud/run/cli.html) for more details.
+After [configuring Terraform Cloud settings](/cli/cloud/settings) for a working directory, you must run `terraform init` to finish setting up. If the working directory has no existing Terraform state, you can start using Terraform with Terraform Cloud right away. Refer to [CLI-driven run workflow](/cloud-docs/run/cli) for more details.
 
 When you run `terraform init` in the following scenarios, Terraform will ask you to choose whether or not to migrate state from any existing workspaces.
 
 1. [**Migrating from local state or state backends:**](#migrating-from-local-state-or-state-backends) If the working directory already has state data in one or more workspaces, Terraform will ask if you would like to migrate that state to new Terraform Cloud workspaces.
 
-2. [**Migrating from the `remote` backend:**](#migrating-from-the-remote-backend) If the working directory was already connected to Terraform Cloud with the `remote` backend, Terraform can continue using the same Terraform Cloud workspaces. You will need to switch the `remote` backend block to the `cloud` block.
+1. [**Migrating from the `remote` backend:**](#migrating-from-the-remote-backend) If the working directory was already connected to Terraform Cloud with the `remote` backend, Terraform can continue using the same Terraform Cloud workspaces. You will need to switch the `remote` backend block to the `cloud` block.
 
 ## Migrating from Local State or State Backends
 
 > **Hands On:** Try the [Migrate State to Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-migrate) tutorial on HashiCorp Learn.
 
 If the working directory already has state data available (using either local state or a [state
-backend](/docs/language/settings/backends/index.html)), Terraform will ask your approval to migrate
+backend](/language/settings/backends)), Terraform will ask your approval to migrate
 that state to Terraform Cloud. You will need permission to manage workspaces in the destination Terraform Cloud organization. This process is interactive and self-documenting, and resembles
 moving between state backends.
 
@@ -32,13 +31,13 @@ Because of this, Terraform will prompt you to rename the working directory's wor
 according to a pattern relative to their existing names. This can indicate the fact that these specific workspaces share configuration. A typical strategy is
 `<COMPONENT>-<ENVIRONMENT>-<REGION>` (e.g.,  `networking-prod-us-east`,
 `networking-staging-us-east`). Refer to [Workspace
-Naming](/docs/cloud/workspaces/naming.html) in the Terraform Cloud documentation for more detail.
+Naming](/cloud-docs/workspaces/naming) in the Terraform Cloud documentation for more detail.
 
 ## Migrating from the `remote` Backend
 
 If the working directory was already connected to Terraform Cloud with the `remote` backend, Terraform can continue using the same Terraform Cloud workspaces. The local names shown for those workspaces will change to match their remote names.
 
-The [`remote` backend](/docs/language/settings/backends/remote.html) was the primary implementation of Terraform Cloud's [CLI-driven run workflow](/docs/cloud/run/cli.html) for Terraform versions 0.11.13 through 1.0.x. We recommend using the native `cloud` integration for Terraform versions 1.1 or later, as it provides an improved user experience and various enhancements.
+The [`remote` backend](/language/settings/backends/remote) was the primary implementation of Terraform Cloud's [CLI-driven run workflow](/cloud-docs/run/cli) for Terraform versions 0.11.13 through 1.0.x. We recommend using the native `cloud` integration for Terraform versions 1.1 or later, as it provides an improved user experience and various enhancements.
 
 ### Block Replacement
 
@@ -49,7 +48,7 @@ block.
 #### Single Workspace
 
 If you were using a single workspace with the `name` argument, change the block
-  label to `cloud`.
+label to `cloud`.
 
 ```diff
 terraform {

website/docs/cli/cloud/settings.html.md → website/docs/cli/cloud/settings.mdx

 ---
-layout: "docs"
-page_title: "Terraform Cloud Settings - Terraform CLI"
+page_title: Terraform Cloud Settings - Terraform CLI
 ---
 
 # Terraform Cloud Settings
 
 Terraform CLI can integrate with Terraform Cloud, acting as a client for Terraform Cloud's
-[CLI-driven run workflow](https://www.terraform.io/docs/cloud/run/cli.html).
+[CLI-driven run workflow](/cloud-docs/run/cli).
 
 > **Hands On:** Try the [Migrate State to Terraform Cloud](https://learn.hashicorp.com/tutorials/terraform/cloud-migrate) tutorial on HashiCorp Learn.
 
 You must configure the following settings to use Terraform Cloud for a particular working directory:
 
 - Provide credentials to access Terraform Cloud, preferably by using the
-  [`terraform login`](/docs/cli/commands/login.html) command.
+  [`terraform login`](/cli/commands/login) command.
 - Add a `cloud` block to the directory's Terraform configuration, to specify
   which organization and workspace(s) to use.
 - Optionally, use a `.terraformignore` file to specify files that shouldn't be
@@ -43,7 +42,7 @@ terraform {
 The `cloud` block also has some special restrictions:
 
 - A configuration can only provide one `cloud` block.
-- A `cloud` block cannot be used with [state backends](/docs/language/settings/backends/index.html).
+- A `cloud` block cannot be used with [state backends](/language/settings/backends).
   A configuration can use one or the other, but not both.
 - A `cloud` block cannot refer to named values (like input variables, locals, or
   data source attributes).
@@ -60,32 +59,32 @@ The `cloud` block supports the following configuration arguments:
   workspace(s) the current configuration should use.
 
 - `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
-use for the current configuration. The `workspaces` block must contain **exactly one** of the
-following arguments, each denoting a strategy for how workspaces should be mapped:
+  use for the current configuration. The `workspaces` block must contain **exactly one** of the
+  following arguments, each denoting a strategy for how workspaces should be mapped:
 
-    - `tags` - (Optional) A set of Terraform Cloud workspace tags. You will be able to use
-      this working directory with any workspaces that have all of the specified tags,
-      and can use [the `terraform workspace` commands](/docs/cli/workspaces/index.html)
-      to switch between them or create new workspaces. New workspaces will automatically have
-      the specified tags. This option conflicts with `name`.
+  - `tags` - (Optional) A set of Terraform Cloud workspace tags. You will be able to use
+    this working directory with any workspaces that have all of the specified tags,
+    and can use [the `terraform workspace` commands](/cli/workspaces)
+    to switch between them or create new workspaces. New workspaces will automatically have
+    the specified tags. This option conflicts with `name`.
 
-    - `name` - (Optional) The name of a single Terraform Cloud workspace. You will
-      only be able to use the workspace specified in the configuration with this working
-      directory, and cannot manage workspaces from the CLI (e.g. `terraform workspace select` or
-      `terraform workspace new`). This option conflicts with `tags`.
+  - `name` - (Optional) The name of a single Terraform Cloud workspace. You will
+    only be able to use the workspace specified in the configuration with this working
+    directory, and cannot manage workspaces from the CLI (e.g. `terraform workspace select` or
+    `terraform workspace new`). This option conflicts with `tags`.
 
 - `hostname` - (Optional) The hostname of a Terraform Enterprise installation, if using Terraform
   Enterprise. Defaults to Terraform Cloud (app.terraform.io).
 
 - `token` - (Optional) The token used to authenticate with Terraform Cloud.
   We recommend omitting the token from the configuration, and instead using
-  [`terraform login`](/docs/cli/commands/login.html) or manually configuring
+  [`terraform login`](/cli/commands/login) or manually configuring
   `credentials` in the
-  [CLI config file](/docs/cli/config/config-file.html#credentials).
+  [CLI config file](/cli/config/config-file#credentials).
 
 ## Excluding Files from Upload with .terraformignore
 
-When executing a remote `plan` or `apply` in a [CLI-driven run](/docs/cloud/run/cli.html),
+When executing a remote `plan` or `apply` in a [CLI-driven run](/cloud-docs/run/cli),
 a copy of your configuration directory is uploaded to Terraform Cloud. You can define
 paths to exclude from upload by adding a `.terraformignore` file at the root of your
 configuration directory. If this file is not present, the upload will exclude

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

 ---
-layout: "docs"
-page_title: "Writing and Modifying Code - Terraform CLI"
-description: "Learn commands that help validate, format, and upgrade code written in the Terraform Configuration Language."
+page_title: Writing and Modifying Code - Terraform CLI
+description: >-
+  Learn commands that help validate, format, and upgrade code written in the
+  Terraform Configuration Language.
 ---
 
 # Writing and Modifying Terraform Code
 
-The [Terraform language](/docs/language/index.html) is Terraform's primary
+The [Terraform language](/language) is Terraform's primary
 user interface, and all of Terraform's workflows rely on configurations written
 in the Terraform language.
 
@@ -14,18 +15,17 @@ 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/cli/commands/console.html) starts an
+- [The `terraform console` command](/cli/commands/console) starts an
   interactive shell for evaluating Terraform
-  [expressions](/docs/language/expressions/index.html), which can be a faster way
+  [expressions](/language/expressions), which can be a faster way
   to verify that a particular resource argument results in the value you expect.
 
-
-- [The `terraform fmt` command](/docs/cli/commands/fmt.html) rewrites Terraform
+- [The `terraform fmt` command](/cli/commands/fmt) 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/cli/commands/validate.html) validates the
+- [The `terraform validate` command](/cli/commands/validate) 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
@@ -33,12 +33,12 @@ 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/cli/commands/0.13upgrade.html) and
-  [the `0.12upgrade` command](/docs/cli/commands/0.12upgrade.html) can automatically
+- [The `0.13upgrade` command](/cli/commands/0.13upgrade) and
+  [the `0.12upgrade` command](/cli/commands/0.12upgrade) 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
   associated with, and you are expected to upgrade older code to be compatible
   with 0.12 before attempting to make it compatible with 0.13. For more detailed
   information about updating code for new Terraform versions, see the [upgrade
-  guides](/upgrade-guides/index.html) in the Terraform language docs.
+  guides](/language/upgrade-guides) in the Terraform language docs.

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

 ---
-layout: "docs"
-page_title: "Command: 0.12upgrade"
-sidebar_current: "docs-commands-012upgrade"
-description: |-
-  The 0.12upgrade subcommand automatically rewrites existing configurations for Terraform 0.12 compatibility.
+page_title: 'Command: 0.12upgrade'
+description: >-
+  The 0.12upgrade subcommand automatically rewrites existing configurations for
+  Terraform 0.12 compatibility.
 ---
 
 # Command: 0.12upgrade
@@ -12,7 +11,7 @@ The `terraform 0.12upgrade` command applies several automatic upgrade rules to
 help prepare a module that was written for Terraform v0.11 to be used
 with Terraform v0.12.
 
--> **This command is available only in Terraform v0.12 releases.** For more information, see [the Terraform v0.12 upgrade guide](https://www.terraform.io/upgrade-guides/0-12.html).
+-> **This command is available only in Terraform v0.12 releases.** For more information, see [the Terraform v0.12 upgrade guide](/language/upgrade-guides/0-12).
 
 ## Usage
 
@@ -71,13 +70,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/language/modules/syntax.html#version)
+[fix existing configurations to a previous version](/language/modules/syntax#version)
 to allow for a gradual upgrade. If the module is published via
-[a Terraform registry](/docs/registry/), assign a new _major_ version number
+[a Terraform registry](/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/language/modules/sources.html#selecting-a-revision)
+[use specific revisions](/language/modules/sources#selecting-a-revision)
 to control which version is used by which caller.
 
 The command-line options are all optional. The available options are:
@@ -107,8 +106,8 @@ On Mac OS X, the `find` included with the system does not support the `-printf`
 ```
 brew install findutils
 ```
-Once installed, run the above command line using `gfind` instead of `find`.
 
+Once installed, run the above command line using `gfind` instead of `find`.
 
 Note that the above includes the `-yes` option to override the interactive
 prompt, so be sure you have a clean work tree before running it.

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

 ---
-layout: "docs"
-page_title: "Command: 0.13upgrade"
-sidebar_current: "docs-commands-013upgrade"
-description: |-
-  The 0.13upgrade subcommand updates existing configurations to use the new provider source features from Terraform 0.13.
+page_title: 'Command: 0.13upgrade'
+description: >-
+  The 0.13upgrade subcommand updates existing configurations to use the new
+  provider source features from Terraform 0.13.
 ---
 
 # Command: 0.13upgrade
@@ -12,7 +11,7 @@ The `terraform 0.13upgrade` command updates existing configuration to add an
 explicit `source` attribute for each provider used in a given module. The
 provider source settings are stored in a `required_providers` block.
 
--> **This command is available only in Terraform v0.13 releases.** For more information, see [the Terraform v0.13 upgrade guide](https://www.terraform.io/upgrade-guides/0-13.html).
+-> **This command is available only in Terraform v0.13 releases.** For more information, see [the Terraform v0.13 upgrade guide](/language/upgrade-guides/0-13).
 
 ## Usage
 
@@ -23,7 +22,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/language/providers/requirements.html
+[required-providers]: /language/providers/requirements
 
 ~> Note: the command ignores `.tf.json` files and override files in the module.
 

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

 ---
-layout: "docs"
-page_title: "Command: apply"
-sidebar_current: "docs-commands-apply"
-description: "The terraform apply command executes the actions proposed in a Terraform plan to create, update, or destroy infrastructure."
+page_title: 'Command: apply'
+description: >-
+  The terraform apply command executes the actions proposed in a Terraform plan
+  to create, update, or destroy infrastructure.
 ---
 
 # Command: apply
@@ -33,15 +33,15 @@ you pass it the filename of a previously-saved plan file.
 ### Automatic Plan Mode
 
 In the default case, with no saved plan file, `terraform apply` creates its own
-plan of action, in the same way that [`terraform plan`](./plan.html) would.
+plan of action, in the same way that [`terraform plan`](/cli/commands/plan) would.
 
 Terraform will propose the plan to you and prompt you to approve it before
 taking the described actions, unless you waive that prompt by using the
 `-auto-approve` option.
 
 When performing its own plan, `terraform apply` supports all of the same
-[planning modes](./plan.html#planning-modes) and
-[planning options](./plan.html#planning-options) that `terraform plan` would
+[planning modes](/cli/commands/plan#planning-modes) and
+[planning options](/cli/commands/plan#planning-options) that `terraform plan` would
 accept, so you can customize how Terraform will create the plan.
 
 ### Saved Plan Mode
@@ -49,7 +49,7 @@ accept, so you can customize how Terraform will create the plan.
 If you pass the filename of a previously-saved plan file, `terraform apply`
 performs exactly the steps specified by that plan file. It does not prompt for
 approval; if you want to inspect a plan file before applying it, you can use
-[`terraform show`](./show.html).
+[`terraform show`](/cli/commands/show).
 
 When using a saved plan, none of the planning modes or planning options linked
 above are supported; these options only affect Terraform's decisions about which
@@ -61,8 +61,8 @@ decisions.
 When run without a saved plan file, `terraform apply` supports all of `terraform
 plan`'s planning modes and planning options. For details, see:
 
-- [Planning Modes](./plan.html#planning-modes)
-- [Planning Options](./plan.html#planning-options)
+* [Planning Modes](/cli/commands/plan#planning-modes)
+* [Planning Options](/cli/commands/plan#planning-options)
 
 ### Apply Options
 
@@ -70,7 +70,7 @@ The following options allow you to change various details about how the
 apply command executes and reports on the apply operation. If you are running
 `terraform apply` _without_ a previously-saved plan file, these options are
 _in addition to_ the planning modes and planning options described for
-[`terraform plan`](./plan.html).
+[`terraform plan`](/cli/commands/plan).
 
 * `-auto-approve` - Skips interactive approval of plan before applying. This
   option is ignored when you pass a previously-saved plan file, because
@@ -95,11 +95,11 @@ _in addition to_ the planning modes and planning options described for
   variable values to continue. To enable this flag, you must also either enable
   the `-auto-approve` flag or specify a previously-saved plan.
 
-  [machine-readable-ui]: /docs/internals/machine-readable-ui.html
+  [machine-readable-ui]: /internals/machine-readable-ui
 
 * `-lock=false` - Don't hold a state lock during the operation. This is
-   dangerous if others might concurrently run commands against the same
-   workspace.
+  dangerous if others might concurrently run commands against the same
+  workspace.
 
 * `-lock-timeout=DURATION` - Unless locking is disabled with `-lock=false`,
   instructs Terraform to retry acquiring a lock for a period of time before
@@ -111,13 +111,13 @@ _in addition to_ the planning modes and planning options described for
   rendered by a system that cannot interpret terminal formatting.
 
 * `-parallelism=n` - Limit the number of concurrent operation as Terraform
-  [walks the graph](/docs/internals/graph.html#walking-the-graph). Defaults to
-  10.
+  [walks the graph](/internals/graph#walking-the-graph). Defaults to
+  10\.
 
 For configurations using
-[the `local` backend](/docs/language/settings/backends/local.html) only,
+[the `local` backend](/language/settings/backends/local) only,
 `terraform apply` also accepts the legacy options
-[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local.html#command-line-arguments).
+[`-state`, `-state-out`, and `-backup`](/language/settings/backends/local#command-line-arguments).
 
 ## Passing a Different Configuration Directory
 
@@ -127,7 +127,7 @@ that directory as the root module instead of the current working directory.
 
 That usage was deprecated in Terraform v0.14 and removed in Terraform v0.15.
 If your workflow relies on overriding the root module directory, use
-[the `-chdir` global option](./#switching-working-directory-with-chdir)
+[the `-chdir` global option](/cli/commands/#switching-working-directory-with-chdir)
 instead, which works across all commands and makes Terraform consistently look
 in the given directory for all files it would normally read or write in the
 current working directory.
@@ -135,6 +135,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](/docs/cli/config/environment-variables.html#tf_data_dir)
+[the `TF_DATA_DIR` environment variable](/cli/config/environment-variables#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 → website/docs/cli/commands/console.mdx

 ---
-layout: "docs"
-page_title: "Command: console"
-sidebar_current: "docs-commands-console"
-description: "The terraform console command provides an interactive console for
-  evaluating expressions."
+page_title: 'Command: console'
+description: >-
+  The terraform console command provides an interactive console for evaluating
+  expressions.
 ---
 
 # Command: console
 
 The `terraform console` command provides an interactive console for
-evaluating [expressions](/docs/language/expressions/index.html).
+evaluating [expressions](/language/expressions).
 
 ## Usage
 
 Usage: `terraform console [options]`
 
 This command provides an interactive command-line console for evaluating and
-experimenting with [expressions](/docs/language/expressions/index.html).
+experimenting with [expressions](/language/expressions).
 This is useful for testing interpolations before using them in configurations,
 and for interacting with any values currently saved in
-[state](/docs/language/state/index.html).
+[state](/language/state).
 
 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/language/functions/index.html).
+[built-in functions](/language/functions).
 
 You can close the console with the `exit` command or by pressing Control-C
 or Control-D.
 
 For configurations using
-[the `local` backend](/docs/language/settings/backends/local.html) only,
+[the `local` backend](/language/settings/backends/local) only,
 `terraform console` accepts the legacy command line option
-[`-state`](/docs/language/settings/backends/local.html#command-line-arguments).
+[`-state`](/language/settings/backends/local#command-line-arguments).
 
 ## Scripting
 
@@ -52,7 +51,7 @@ tolist([
 
 ## Remote State
 
-If [remote state](/docs/language/state/remote.html) is used by the current backend,
+If [remote state](/language/state/remote) 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 → website/docs/cli/commands/destroy.mdx

 ---
-layout: "docs"
-page_title: "Command: destroy"
-sidebar_current: "docs-commands-destroy"
-description: "The terraform destroy command destroys all objects managed by a Terraform configuration."
+page_title: 'Command: destroy'
+description: >-
+  The terraform destroy command destroys all objects managed by a Terraform
+  configuration.
 ---
 
 # Command: destroy
@@ -27,7 +27,7 @@ terraform apply -destroy
 ```
 
 For that reason, this command accepts most of the options that
-[`terraform apply`](./apply.html) accepts, although it does
+[`terraform apply`](/cli/commands/apply) accepts, although it does
 not accept a plan file argument and forces the selection of the "destroy"
 planning mode.
 
@@ -38,7 +38,7 @@ destroying would be, by running the following command:
 terraform plan -destroy
 ```
 
-This will run [`terraform plan`](./plan.html) in _destroy_ mode, showing
+This will run [`terraform plan`](/cli/commands/plan) in _destroy_ mode, showing
 you the proposed destroy changes without executing them.
 
 -> **Note:** The `-destroy` option to `terraform apply` exists only in

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

----
-layout: "docs"
-page_title: "Command: env"
-sidebar_current: "docs-commands-envcmd"
-description: "The terraform env command is a deprecated form of the terraform workspace command."
----
-
-# Command: env
-
-The `terraform env` command is deprecated.
-[The `terraform workspace` command](/docs/cli/commands/workspace/index.html)
-should be used instead.

website/docs/cli/commands/env.mdx

+---
+page_title: 'Command: env'
+description: >-
+  The terraform env command is a deprecated form of the terraform workspace
+  command.
+---
+
+# Command: env
+
+The `terraform env` command is deprecated.
+[The `terraform workspace` command](/cli/commands/workspace)
+should be used instead.

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

 ---
-layout: "docs"
-page_title: "Command: fmt"
-sidebar_current: "docs-commands-fmt"
-description: "The terraform fmt command rewrites configuration files to a canonical format and style."
+page_title: 'Command: fmt'
+description: >-
+  The terraform fmt command rewrites configuration files to a canonical format
+  and style.
 ---
 
 # Command: fmt
 
 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/language/syntax/style.html),
+the [Terraform language style conventions](/language/syntax/style),
 along with other minor adjustments for readability.
 
 Other Terraform commands that generate Terraform configuration will produce
@@ -58,5 +58,5 @@ The command-line flags are all optional. The list of available flags are:
 * `-write=false` - Don't overwrite the input files. (This is implied by `-check` or when the input is STDIN.)
 * `-diff` - Display diffs of formatting changes
 * `-check` - Check if the input is formatted. Exit status will be 0 if
-    all input is properly formatted and non-zero otherwise.
+  all input is properly formatted and non-zero otherwise.
 * `-recursive` - Also process files in subdirectories. By default, only the given directory (or current directory) is processed.

website/docs/cli/commands/force-unlock.html.md → website/docs/cli/commands/force-unlock.mdx

 ---
-layout: "docs"
-page_title: "Command: force-unlock"
-sidebar_current: "docs-commands-force-unlock"
-description: "The terraform force-unlock command unlocks the state for a configuration. It does not modify your infrastructure."
+page_title: 'Command: force-unlock'
+description: >-
+  The terraform force-unlock command unlocks the state for a configuration. It
+  does not modify your infrastructure.
 ---
 
 # Command: force-unlock
@@ -27,4 +27,4 @@ process.
 
 Options:
 
-*  `-force` -  Don't ask for input for unlock confirmation.
+* `-force` -  Don't ask for input for unlock confirmation.

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

 ---
-layout: "docs"
-page_title: "Command: get"
-sidebar_current: "docs-commands-get"
-description: "The terraform get command downloads and updates modules."
+page_title: 'Command: get'
+description: The terraform get command downloads and updates modules.
 ---
 
 # Command: get
 
 The `terraform get` command is used to download and update
-[modules](/docs/language/modules/develop/index.html) mentioned in the root module.
+[modules](/language/modules/develop) mentioned in the root module.
 
 ## Usage
 
@@ -21,6 +19,6 @@ repository.
 The `get` command supports the following option:
 
 * `-update` - If specified, modules that are already downloaded will be
-   checked for updates and the updates will be downloaded if present.
+  checked for updates and the updates will be downloaded if present.
 
 * `-no-color` - Disable text coloring in the output.

website/docs/cli/commands/graph.html.md → website/docs/cli/commands/graph.mdx

 ---
-layout: "docs"
-page_title: "Command: graph"
-sidebar_current: "docs-commands-graph"
-description: "The terraform graph command generates a visual representation of a configuration or execution plan that you can use to generate charts."
+page_title: 'Command: graph'
+description: >-
+  The terraform graph command generates a visual representation of a
+  configuration or execution plan that you can use to generate charts.
 ---
 
 # Command: graph
@@ -12,7 +12,6 @@ representation of either a configuration or execution plan.
 The output is in the DOT format, which can be used by
 [GraphViz](http://www.graphviz.org) to generate charts.
 
-
 ## Usage
 
 Usage: `terraform graph [options]`
@@ -33,16 +32,16 @@ argument.
 Options:
 
 * `-plan=tfplan`    - Render graph using the specified plan file instead of the
-                      configuration in the current directory.
+  configuration in the current directory.
 
 * `-draw-cycles`    - Highlight any cycles in the graph with colored edges.
-                      This helps when diagnosing cycle errors.
+  This helps when diagnosing cycle errors.
 
 * `-type=plan`      - Type of graph to output. Can be: `plan`, `plan-destroy`, `apply`,
-                      `validate`, `input`, `refresh`.
+  `validate`, `input`, `refresh`.
 
 * `-module-depth=n` - (deprecated) In prior versions of Terraform, specified the
-                      depth of modules to show in the output.
+  depth of modules to show in the output.
 
 ## Generating Images
 
@@ -55,4 +54,4 @@ $ terraform graph | dot -Tsvg > graph.svg
 ```
 
 Here is an example graph output:
-![Graph Example](docs/graph-example.png)
+![Graph Example](/img/docs/graph-example.png)

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

 ---
-layout: "docs"
-page_title: "Command: import"
-sidebar_current: "docs-commands-import"
-description: "The terraform import command brings existing resources into Terraform state."
+page_title: 'Command: import'
+description: The terraform import command brings existing resources into Terraform state.
 ---
 
 # Command: import
@@ -10,7 +8,7 @@ description: "The terraform import command brings existing resources into Terraf
 > **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/cli/import/index.html)
+[import existing resources](/cli/import)
 into Terraform.
 
 ## Usage
@@ -20,7 +18,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/cli/state/resource-addressing.html).
+ADDRESS must be a valid [resource address](/cli/state/resource-addressing).
 Because any resource address is valid, the import command can import resources
 into modules as well as directly into the root of your state.
 
@@ -36,7 +34,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/language/state/index.html).
+[the State section](/language/state).
 
 The command-line flags are all optional. The list of available flags are:
 
@@ -48,29 +46,29 @@ The command-line flags are all optional. The list of available flags are:
 * `-input=true` - Whether to ask for input for provider configuration.
 
 * `-lock=false` - Don't hold a state lock during the operation. This is
-   dangerous if others might concurrently run commands against the same
-   workspace.
+  dangerous if others might concurrently run commands against the same
+  workspace.
 
 * `-lock-timeout=0s` - Duration to retry a state lock.
 
 * `-no-color` - If specified, output won't contain any color.
 
 * `-parallelism=n` - Limit the number of concurrent operation as Terraform
-  [walks the graph](/docs/internals/graph.html#walking-the-graph). Defaults
+  [walks the graph](/internals/graph#walking-the-graph). Defaults
   to 10.
 
 * `-provider=provider` - **Deprecated** Override the provider configuration to
-use when importing the object. By default, Terraform uses the provider specified
-in the configuration for the target resource, and that is the best behavior in most cases.
+  use when importing the object. By default, Terraform uses the provider specified
+  in the configuration for the target resource, and that is the best behavior in most cases.
 
 * `-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/language/expressions/types.html) in the
+  [literal expressions](/language/expressions/types) 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/language/values/variables.html#variable-definitions-tfvars-files). If
+  a [variable file](/language/values/variables#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
@@ -79,15 +77,15 @@ in the configuration for the target resource, and that is the best behavior in m
   useful with the `-config` flag.
 
 For configurations using
-[the `remote` backend](/docs/language/settings/backends/remote.html)
+[the `remote` backend](/language/settings/backends/remote)
 only, `terraform import`
 also accepts the option
-[`-ignore-remote-version`](/docs/language/settings/backends/remote.html#command-line-arguments).
+[`-ignore-remote-version`](/language/settings/backends/remote#command-line-arguments).
 
 For configurations using
-[the `local` backend](/docs/language/settings/backends/local.html) only,
+[the `local` backend](/language/settings/backends/local) only,
 `terraform import` also accepts the legacy options
-[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local.html#command-line-arguments).
+[`-state`, `-state-out`, and `-backup`](/language/settings/backends/local#command-line-arguments).
 
 ## Provider Configuration
 
@@ -135,7 +133,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/language/meta-arguments/count.html):
+[`count`](/language/meta-arguments/count):
 
 ```shell
 $ terraform import 'aws_instance.baz[0]' i-abcd1234
@@ -144,7 +142,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/language/meta-arguments/for_each.html):
+[`for_each`](/language/meta-arguments/for_each):
 
 Linux, Mac OS, and UNIX:
 

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

 ---
-layout: "docs"
-page_title: "Basic CLI Features"
-sidebar_current: "docs-commands"
-description: "An introduction to the terraform command and its available subcommands."
+page_title: Basic CLI Features
+description: An introduction to the terraform command and its available subcommands.
 ---
 
 # Basic CLI Features
@@ -17,8 +15,8 @@ of this page.
 We refer to the `terraform` command line tool as "Terraform CLI" elsewhere
 in the documentation. This terminology is often used to distinguish it from
 other components you might use in the Terraform product family, such as
-[Terraform Cloud](/docs/cloud/) or
-the various [Terraform providers](/docs/language/providers/index.html), which
+[Terraform Cloud](/cloud-docs) or
+the various [Terraform providers](/language/providers), which
 are developed and released separately from Terraform CLI.
 
 To view a list of the commands available in your current Terraform version,
@@ -100,7 +98,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](/docs/cli/config/config-file.html) are not for a specific
+* Settings in the [CLI Configuration](/cli/config/config-file) are not for a specific
   subcommand and Terraform processes them before acting on the `-chdir`
   option.
 
@@ -153,7 +151,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/cli/config/config-file.html) can be used to
+[the CLI configuration file](/cli/config/config-file) can be used to
 disable checkpoint features. The following checkpoint-related settings are
 supported in this file: