upstream/terraform
1
0
Fork 0
mirror of https://github.com/hashicorp/terraform.git synced 2026-02-03 20:50:59 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

Merge pull request #35033 from hashicorp/RK/fix-links

Browse source 
docs: Fix links and headers
This commit is contained in:
rita 2024-04-22 08:46:30 -04:00 committed by GitHub
commit d1f9d3b13f
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
62 changed files with 264 additions and 265 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.github/CONTRIBUTING.md vendored
View file

@ -156,7 +156,7 @@ Terraform providers are not maintained in this repository; you can find relevant
repository and relevant issue tracker for each provider within the
[Terraform Registry index](https://registry.terraform.io/browse/providers).
This repository also does not include the source code for some other parts of the Terraform product including Terraform Cloud, Terraform Enterprise, and the Terraform Registry. The source for those components is not publicly available. If you have feedback about these products, including bug reports, please email [tf-cloud@hashicorp.support](mailto:tf-cloud@hashicorp.support) or [open a support request](https://support.hashicorp.com/hc/en-us/requests/new).
This repository also does not include the source code for some other parts of the Terraform product including HCP Terraform, Terraform Enterprise, and the Terraform Registry. The source for those components is not publicly available. If you have feedback about these products, including bug reports, please email [tf-cloud@hashicorp.support](mailto:tf-cloud@hashicorp.support) or [open a support request](https://support.hashicorp.com/hc/en-us/requests/new).
---
@ -200,7 +200,7 @@ go test ./internal/addrs
Terraform's unit test suite is self-contained, using mocks and local files to help ensure that it can run offline and is unlikely to be broken by changes to outside systems.
However, several Terraform components interact with external services, such as the automatic provider installation mechanism, the Terraform Registry, Terraform Cloud, etc.
However, several Terraform components interact with external services, such as the automatic provider installation mechanism, the Terraform Registry, HCP Terraform, etc.
There are some optional tests in the Terraform CLI codebase that *do* interact with external services, which we collectively refer to as "acceptance tests". You can enable these by setting the environment variable `TF_ACC=1` when running the tests. We recommend focusing only on the specific package you are working on when enabling acceptance tests, both because it can help the test run to complete faster and because you are less likely to encounter failures due to drift in systems unrelated to your current goal:

2
.github/ISSUE_TEMPLATE/bug_report.yml vendored
View file

@ -15,7 +15,7 @@ body:
For general usage questions, please see: https://www.terraform.io/community.html.
## If your issue relates to:
* **Terraform Cloud/Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **HCP Terraform or Terraform Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **AWS Terraform Provider**: Open an issue at [hashicorp/terraform-provider-aws](https://github.com/hashicorp/terraform-provider-aws/issues/new/choose).
* **Azure Terraform Provider**: Open an issue at [hashicorp/terraform-provider-azurerm](https://github.com/hashicorp/terraform-provider-azurerm/issues/new/choose).
* **Other Terraform Providers**: Please open an issue in the provider's own repository, which can be found by searching the [Terraform Registry](https://registry.terraform.io/browse/providers).

4
.github/ISSUE_TEMPLATE/config.yml vendored
View file

@ -3,9 +3,9 @@
blank_issues_enabled: false
contact_links:
- name: Terraform Cloud/Enterprise Troubleshooting and Feature Requests
- name: HCP Terraform and Terraform Enterprise Troubleshooting and Feature Requests
url: https://support.hashicorp.com/hc/en-us/requests/new
about: For issues and feature requests related to the Terraform Cloud/Enterprise platform, please submit a HashiCorp support request or email tf-cloud@hashicorp.support
about: For issues and feature requests related to HCP Terraform and Terraform Enterprise, please submit a HashiCorp support request or email tf-cloud@hashicorp.support
- name: AWS Terraform Provider Feedback and Questions
url: https://github.com/hashicorp/terraform-provider-aws
about: The AWS Terraform Provider has its own repository, any provider related issues or questions should be directed there.

2
.github/ISSUE_TEMPLATE/feature_request.yml vendored
View file

@ -15,7 +15,7 @@ body:
For general usage questions, please see: https://www.terraform.io/community.html.
## If your feature request relates to:
* **Terraform Cloud/Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **HCP Terraform or Terraform Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **AWS Terraform Provider**: Open an issue at [hashicorp/terraform-provider-aws](https://github.com/hashicorp/terraform-provider-aws/issues/new/choose).
* **Azure Terraform Provider**: Open an issue at [hashicorp/terraform-provider-azurerm](https://github.com/hashicorp/terraform-provider-azurerm/issues/new/choose).
* **Other Terraform Providers**: Please open an issue in the provider's own repository, which can be found by searching the [Terraform Registry](https://registry.terraform.io/browse/providers).

2
docs/architecture.md
View file

@ -64,7 +64,7 @@ constructed, and then the backend is responsible for executing that action.
Backends that execute operations, however, do so as an architectural implementation detail and not a
general feature of backends. That is, the term 'backend' as a Terraform feature is used to refer to
a plugin that determines where Terraform stores its state snapshots - only the default `local`
backend and Terraform Cloud's backends (`remote`, `cloud`) perform operations.
backend and HCP Terraform's backends (`remote`, `cloud`) perform operations.
Thus, most backends do _not_ implement this interface, and so the `command` package wraps these
backends in an instance of

4
docs/dependency-upgrades.md
View file

@ -130,8 +130,8 @@ special constraints due to how Terraform uses them:
prevent adoption of changes made to pre-existing functionality that
Terraform already exposes.
* `github.com/hashicorp/go-tfe` -- the client library for the Terraform Cloud
API -- includes various types corresponding to Terraform Cloud API
* `github.com/hashicorp/go-tfe` -- the client library for the HCP Terraform
API -- includes various types corresponding to HCP Terraform API
requests and responses. The internal package `internal/cloud` contains mock
implementations of some of those types, which may need to be updated when
the client library is upgraded.

4
internal/cloud/e2e/README.md
View file

@ -10,7 +10,7 @@ Required flags
external network calls. This is needed to run these tests. Without it, the
tests do not run.
* `TFE_TOKEN=<admin token>` and `TFE_HOSTNAME=<hostname>`. The helpers
for these tests require admin access to a TFC/TFE instance.
for these tests require admin access to an HCP Terraform or Terraform Enterprise instance.
* `-timeout=30m`. Some of these tests take longer than the default 10m timeout for `go test`.
### Flags
@ -19,6 +19,6 @@ for these tests require admin access to a TFC/TFE instance.
* Use the `-tfoutput` flag to print the terraform output to standard out.
* Use `-ldflags` to change the version Prerelease to match a version
available remotely. Some behaviors rely on the exact local version Terraform
being available in TFC/TFE, and manipulating the Prerelease during build is
being available in HCP Terraform or Terraform Enterprise, and manipulating the Prerelease during build is
often the only way to ensure this.
[(More on `-ldflags`.)](https://www.digitalocean.com/community/tutorials/using-ldflags-to-set-version-information-for-go-applications)

4
tools/terraform-bundle/README.md
View file

@ -18,7 +18,7 @@ to this need:
current Terraform configuration, serving a similar (though not identical)
purpose than `terraform-bundle` had served.
For those using Terraform CLI alone, without Terraform Cloud, we recommend
For those using Terraform CLI alone, without HCP Terraform, we recommend
planning to transition to the above features instead of using
`terraform-bundle`.
@ -53,7 +53,7 @@ Terraform v0.13's introduction of automatic third-party provider installation.
## Terraform Enterprise Users
If you use Terraform Enterprise, the self-hosted distribution of
Terraform Cloud, you can use `terraform-bundle` as described above to build
HCP Terraform, you can use `terraform-bundle` as described above to build
custom Terraform packages with bundled provider plugins.
For more information, see

4
website/data/cli-nav-data.json
View file

@ -229,10 +229,10 @@
]
},
{
"title": "Using Terraform Cloud",
"title": "Using HCP Terraform",
"routes": [
{ "title": "Overview", "path": "cloud" },
{ "title": "Terraform Cloud Settings", "path": "cloud/settings" },
{ "title": "HCP Terraform Settings", "path": "cloud/settings" },
{
"title": "Initializing and Migrating",
"path": "cloud/migrating"

2
website/data/language-nav-data.json
View file

@ -933,7 +933,7 @@
"title": "Terraform Settings",
"routes": [
{ "title": "Overview", "path": "settings" },
{ "title": "Terraform Cloud", "path": "settings/terraform-cloud" },
{ "title": "HCP Terraform", "path": "settings/cloud" },
{
"title": "Backends",
"routes": [

18
website/docs/cli/auth/index.mdx
View file

@ -2,28 +2,28 @@
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.
an API token for your HCP Terraform account.
---
# CLI Authentication
> **Hands-on:** Try the [Authenticate the CLI with Terraform Cloud](/terraform/tutorials/cloud/cloud-login?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
> **Hands-on:** Try the [Authenticate the CLI with HCP Terraform](/terraform/tutorials/cloud/cloud-login?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
[Terraform Cloud](https://cloud.hashicorp.com/products/terraform) and
[HCP Terraform](https://cloud.hashicorp.com/products/terraform) and
[Terraform Enterprise](/terraform/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.")
expediency, the content below refers to both products as "HCP Terraform.")
Terraform CLI integrates with Terraform Cloud in several ways — it can be a
front-end for [CLI-driven runs](/terraform/cloud-docs/run/cli) in Terraform Cloud,
and can also use Terraform Cloud as a state backend and a private module
Terraform CLI integrates with HCP Terraform in several ways — it can be a
front-end for [CLI-driven runs](/terraform/cloud-docs/run/cli) in HCP Terraform,
and can also use HCP Terraform as a state backend and a private module
registry. All of these integrations require you to authenticate Terraform CLI
with your Terraform Cloud account.
with your HCP Terraform account.
The best way to handle CLI authentication is with the `login` and `logout`
commands, which help automate the process of getting an API token for your
Terraform Cloud user account.
HCP Terraform user account.
For details, see:

2
website/docs/cli/cloud/command-line-arguments.mdx
View file

@ -20,5 +20,5 @@ accept the following option to modify that behavior:
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
in an HCP Terraform workspace that is no longer able to complete remote operations with the currently
selected version of Terraform.

22
website/docs/cli/cloud/index.mdx
View file

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

26
website/docs/cli/cloud/migrating.mdx
View file

@ -1,50 +1,50 @@
---
page_title: Initializing and Migrating to Terraform Cloud - Terraform CLI
page_title: Initializing and Migrating to HCP Terraform - Terraform CLI
description: >-
Learn how to use the Terraform CLI to migrate local or remote state to Terraform Cloud.
Learn how to use the Terraform CLI to migrate local or remote state to HCP Terraform.
---
# Initializing and Migrating
After [configuring Terraform Cloud settings](/terraform/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](/terraform/cloud-docs/run/cli) for more details.
After [configuring HCP Terraform settings](/terraform/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 HCP Terraform right away. Refer to [CLI-driven run workflow](/terraform/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.
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 HCP Terraform workspaces.
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.
1. [**Migrating from the `remote` backend:**](#migrating-from-the-remote-backend) If the working directory was already connected to HCP Terraform with the `remote` backend, Terraform can continue using the same HCP Terraform 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](/terraform/tutorials/cloud/cloud-migrate) tutorial.
> **Hands On:** Try the [Migrate State to HCP Terraform](/terraform/tutorials/cloud/cloud-migrate) tutorial.
If the working directory already has state data available (using either local state or a [state
backend](/terraform/language/settings/backends/configuration)), Terraform asks 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
that state to HCP Terraform. You will need permission to manage workspaces in the destination HCP Terraform organization. This process is interactive and self-documenting, and resembles
moving between state backends.
Terraform may also prompt you to rename your workspaces during the migration, to either give a name to
the unnamed `default` workspace (Terraform Cloud requires all workspaces to have a name) or give
the unnamed `default` workspace (HCP Terraform requires all workspaces to have a name) or give
your workspace names more contextual information. Unlike Terraform CLI-only workspaces, which represent
multiple environments associated with the same configuration (e.g. production, staging, development),
Terraform Cloud workspaces can represent totally independent configurations, and must have unique names within the Terraform Cloud organization.
HCP Terraform workspaces can represent totally independent configurations, and must have unique names within the HCP Terraform organization.
Because of this, Terraform will prompt you to rename the working directory's workspaces
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](/terraform/cloud-docs/workspaces/naming) in the Terraform Cloud documentation for more detail.
Naming](/terraform/cloud-docs/workspaces/naming) in the HCP Terraform 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.
If the working directory was already connected to HCP Terraform with the `remote` backend, Terraform can continue using the same HCP Terraform workspaces. The local names shown for those workspaces will change to match their remote names.
The [`remote` backend](/terraform/language/settings/backends/remote) was the primary implementation of Terraform Cloud's [CLI-driven run workflow](/terraform/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.
The [`remote` backend](/terraform/language/settings/backends/remote) was the primary implementation of HCP Terraform's [CLI-driven run workflow](/terraform/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
When switching from the `remote` backend to a `cloud` block, Terraform will continue using the same
set of Terraform Cloud workspaces. Replace your `backend "remote"` block with an equivalent `cloud`
set of HCP Terraform workspaces. Replace your `backend "remote"` block with an equivalent `cloud`
block.
#### Single Workspace

36
website/docs/cli/cloud/settings.mdx
View file

@ -1,19 +1,19 @@
---
page_title: Terraform Cloud Settings - Terraform CLI
page_title: HCP Terraform Settings - Terraform CLI
description: >-
Configure the Terraform Cloud CLI integration.
Configure the HCP Terraform CLI integration.
---
# Terraform Cloud Settings
# HCP Terraform Settings
Terraform CLI can integrate with Terraform Cloud, acting as a client for Terraform Cloud's
Terraform CLI can integrate with HCP Terraform, acting as a client for HCP Terraform's
[CLI-driven run workflow](/terraform/cloud-docs/run/cli).
> **Hands On:** Try the [Migrate State to Terraform Cloud](/terraform/tutorials/cloud/cloud-migrate) tutorial.
> **Hands On:** Try the [Migrate State to HCP Terraform](/terraform/tutorials/cloud/cloud-migrate) tutorial.
You must configure the following settings to use Terraform Cloud for a particular working directory:
You must configure the following settings to use HCP Terraform for a particular working directory:
- Provide credentials to access Terraform Cloud, preferably by using the
- Provide credentials to access HCP Terraform, preferably by using the
[`terraform login`](/terraform/cli/commands/login) command.
- Add a `cloud` block to the directory's Terraform configuration, to specify
which organization and workspace(s) to use.
@ -25,7 +25,7 @@ After adding or changing a `cloud` block, you must run `terraform init`.
## The `cloud` Block
The `cloud` block is a nested block within the top-level `terraform` settings
block. It specifies which Terraform Cloud workspaces to use for the current
block. It specifies which HCP Terraform workspaces to use for the current
working directory.
```hcl
@ -50,7 +50,7 @@ The `cloud` block also has some special restrictions:
- A `cloud` block cannot refer to named values (like input variables, locals, or
data source attributes).
The `cloud` block only affects Terraform CLI's behavior. When Terraform Cloud uses a configuration
The `cloud` block only affects Terraform CLI's behavior. When HCP Terraform uses a configuration
that contains a cloud block - for example, when a workspace is configured to use a VCS provider
directly - it ignores the block and behaves according to its own workspace settings.
@ -61,29 +61,29 @@ The `cloud` block supports the following configuration arguments:
- `organization` - (Required) The name of the organization containing the
workspace(s) the current configuration should use.
- `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
- `workspaces` - (Required) A nested block that specifies which remote HCP Terraform 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:
- `tags` - (Optional) A set of Terraform Cloud workspace tags. You will be able to use
- `tags` - (Optional) A set of HCP Terraform 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](/terraform/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
- `name` - (Optional) The name of a single HCP Terraform 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`.
- `project` - (Optional) The name of a Terraform Cloud project. Workspaces that need creating
- `project` - (Optional) The name of an HCP Terraform project. Workspaces that need creating
will be created within this project. `terraform workspace list` will be filtered by workspaces
in the supplied project.
- `hostname` - (Optional) The hostname of a Terraform Enterprise installation, if using Terraform
Enterprise. Defaults to Terraform Cloud (app.terraform.io).
Enterprise. Defaults to HCP Terraform (app.terraform.io).
- `token` - (Optional) The token used to authenticate with Terraform Cloud.
- `token` - (Optional) The token used to authenticate with HCP Terraform.
We recommend omitting the token from the configuration, and instead using
[`terraform login`](/terraform/cli/commands/login) or manually configuring
`credentials` in the
@ -103,14 +103,14 @@ Use the following environment variables to configure the `cloud` block:
- `TF_CLOUD_HOSTNAME` - The hostname of a Terraform Enterprise installation. Terraform reads this when `hostname` is omitted from the `cloud` block. If both are specified, the configuration takes precedence.
- `TF_CLOUD_PROJECT` - The name of a Terraform Cloud project. Terraform reads this when `workspaces.project` is omitted from the `cloud` block. If both are specified, the cloud block configuration takes precedence.
- `TF_CLOUD_PROJECT` - The name of an HCP Terraform project. Terraform reads this when `workspaces.project` is omitted from the `cloud` block. If both are specified, the cloud block configuration takes precedence.
- `TF_WORKSPACE` - The name of a single Terraform Cloud workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. Terraform Cloud will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/terraform/cli/config/environment-variables#tf_workspace) for details.
- `TF_WORKSPACE` - The name of a single HCP Terraform workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. HCP Terraform will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/terraform/cli/config/environment-variables#tf_workspace) for details.
## Excluding Files from Upload with .terraformignore
When executing a remote `plan` or `apply` in a [CLI-driven run](/terraform/cloud-docs/run/cli),
a copy of your configuration directory is uploaded to Terraform Cloud. You can define
a copy of your configuration directory is uploaded to HCP Terraform. 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
the following by default:

2
website/docs/cli/commands/import.mdx
View file

@ -74,7 +74,7 @@ The command-line flags are all optional. The following flags are available:
the working directory. This flag can be used multiple times. This is only
useful with the `-config` flag.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform import`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

2
website/docs/cli/commands/index.mdx
View file

@ -13,7 +13,7 @@ accepts a variety of subcommands such as `terraform init` or `terraform plan`.
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](/terraform/cloud-docs) or
[HCP Terraform](/terraform/cloud-docs) or
the various [Terraform providers](/terraform/language/providers), which
are developed and released separately from Terraform CLI.

8
website/docs/cli/commands/login.mdx
View file

@ -2,14 +2,14 @@
page_title: 'Command: login'
description: >-
The terraform login command can be used to automatically obtain and save an
API token for Terraform Cloud, Terraform Enterprise, or any other host that
API token for HCP Terraform, Terraform Enterprise, or any other host that
offers Terraform services.
---
# Command: login
The `terraform login` command can be used to automatically obtain and save an
API token for Terraform Cloud, Terraform Enterprise, or any other host that offers Terraform services.
API token for HCP Terraform, Terraform Enterprise, or any other host that offers Terraform services.
-> **Note:** This command is suitable only for use in interactive scenarios
where it is possible to launch a web browser on the same host where Terraform
@ -22,7 +22,7 @@ you can
Usage: `terraform login [hostname]`
If you don't provide an explicit hostname, Terraform will assume you want to
log in to Terraform Cloud at `app.terraform.io`.
log in to HCP Terraform at `app.terraform.io`.
## Credentials Storage
@ -41,5 +41,5 @@ your organization's existing secrets management system.
## Login Server Support
The `terraform login` command works with any server supporting the
[login protocol](/terraform/internals/login-protocol), including Terraform Cloud
[login protocol](/terraform/internals/login-protocol), including HCP Terraform
and Terraform Enterprise.

4
website/docs/cli/commands/logout.mdx
View file

@ -8,7 +8,7 @@ description: >-
# Command: logout
The `terraform logout` command is used to remove credentials stored by
`terraform login`. These credentials are API tokens for Terraform Cloud,
`terraform login`. These credentials are API tokens for HCP Terraform,
Terraform Enterprise, or any other host that offers Terraform services.
## Usage
@ -16,7 +16,7 @@ Terraform Enterprise, or any other host that offers Terraform services.
Usage: `terraform logout [hostname]`
If you don't provide an explicit hostname, Terraform will assume you want to
log out of Terraform Cloud at `app.terraform.io`.
log out of HCP Terraform at `app.terraform.io`.
-> **Note:** the API token is only removed from local storage, not destroyed on
the remote server, so it will remain valid until manually revoked.

4
website/docs/cli/commands/push.mdx
View file

@ -1,13 +1,13 @@
---
page_title: 'Command: push'
description: >-
DISCONTINUED. Terraform Cloud and the modern "remote" backend have replaced
DISCONTINUED. HCP Terraform and the modern "remote" backend have replaced
the old `terraform push` command.
---
# Command: push
!> **Important:** The `terraform push` command is no longer functional. We recommend the [Terraform Cloud CLI integration](/terraform/cli/cloud) instead, which allows you to run remote operations in Terraform Cloud directly from the command line.
!> **Important:** The `terraform push` command is no longer functional. We recommend the [HCP Terraform CLI integration](/terraform/cli/cloud) instead, which allows you to run remote operations in HCP Terraform directly from the command line.
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.

2
website/docs/cli/commands/state/mv.mdx
View file

@ -66,7 +66,7 @@ This command also accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform state mv`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

2
website/docs/cli/commands/state/push.mdx
View file

@ -42,7 +42,7 @@ Both of these safety checks can be disabled with the `-force` flag.
**This is not recommended.** If you disable the safety checks and are
pushing state, the destination state will be overwritten.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform state push`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

2
website/docs/cli/commands/state/replace-provider.mdx
View file

@ -32,7 +32,7 @@ This command also accepts the following options:
- `-lock-timeout=0s` - Duration to retry a state lock.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform state replace-provider`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

2
website/docs/cli/commands/state/rm.mdx
View file

@ -51,7 +51,7 @@ This command also accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform state rm`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

2
website/docs/cli/commands/taint.mdx
View file

@ -55,7 +55,7 @@ This command accepts the following options:
returning an error. The duration syntax is a number followed by a time
unit letter, such as "3s" for three seconds.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote) only, `terraform taint`
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote) only, `terraform taint`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

8
website/docs/cli/commands/test.mdx
View file

@ -24,7 +24,7 @@ Terraform then executes a series of Terraform plan or apply commands according t
The following options apply to the Terraform `test` command:
* `-cloud-run=<module source>` - This test run executes remotely on Terraform Cloud within the specified Terraform [private registry](/terraform/language/modules/sources#terraform-registry) module.
* `-cloud-run=<module source>` - This test run executes remotely on HCP Terraform within the specified Terraform [private registry](/terraform/language/modules/sources#terraform-registry) module.
* `-filter=testfile` - Limits the `terraform test` operation to the specified test files.
@ -46,11 +46,11 @@ You should monitor the output of the test command closely to ensure Terraform re
Terraform also provides diagnostics explaining why it could not automatically clean up. You should review these diagnostics to ensure that future clean-up operations are successful.
## Terraform Cloud execution
## HCP Terraform execution
You can execute tests remotely on Terraform Cloud using the `-cloud-run` option.
You can execute tests remotely on HCP Terraform using the `-cloud-run` option.
The `-cloud-run` option accepts a [private registry module source](/terraform/language/modules/sources#terraform-registry). This option associates the test run with your specified private module within the Terraform Cloud user interface.
The `-cloud-run` option accepts a [private registry module source](/terraform/language/modules/sources#terraform-registry). This option associates the test run with your specified private module within the HCP Terraform user interface.
You must provide a module from a _private_ registry, not the public Terraform registry.

2
website/docs/cli/commands/untaint.mdx
View file

@ -61,7 +61,7 @@ This command also accepts the following options:
if you are running Terraform in a context where its output will be
rendered by a system that cannot interpret terminal formatting.
For configurations using the [Terraform Cloud CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
For configurations using the [HCP Terraform CLI integration](/terraform/cli/cloud) or the [`remote` backend](/terraform/language/settings/backends/remote)
only, `terraform untaint`
also accepts the option
[`-ignore-remote-version`](/terraform/cli/cloud/command-line-arguments#ignore-remote-version).

12
website/docs/cli/config/config-file.mdx
View file

@ -50,12 +50,12 @@ disable_checkpoint = true
The following settings can be set in the CLI configuration file:
* `credentials` - configures credentials for use with Terraform Cloud or
* `credentials` - configures credentials for use with HCP Terraform or
Terraform Enterprise. See [Credentials](#credentials) below for more
information.
* `credentials_helper` - configures an external helper program for the storage
and retrieval of credentials for Terraform Cloud or Terraform Enterprise.
and retrieval of credentials for HCP Terraform or Terraform Enterprise.
See [Credentials Helpers](#credentials-helpers) below for more information.
* `disable_checkpoint` — when set to `true`, disables
@ -76,7 +76,7 @@ The following settings can be set in the CLI configuration file:
## Credentials
[Terraform Cloud](https://cloud.hashicorp.com/products/terraform) provides a number of remote network
[HCP Terraform](https://cloud.hashicorp.com/products/terraform) provides a number of remote network
services for use with Terraform, and
[Terraform Enterprise](/terraform/enterprise) allows hosting those
services inside your own infrastructure. For example, these systems offer both
@ -98,11 +98,11 @@ not, you can manually write `credentials` blocks.
You can have multiple `credentials` blocks if you regularly use services from
multiple hosts. Many users will configure only one, for either
Terraform Cloud (at `app.terraform.io`) or for their organization's own
HCP Terraform (at `app.terraform.io`) or for their organization's own
Terraform Enterprise host. Each `credentials` block contains a `token` argument
giving the API token to use for that host.
~> **Important:** If you are using Terraform Cloud or Terraform Enterprise,
~> **Important:** If you are using HCP Terraform or Terraform Enterprise,
the token provided must be either a
[user token](/terraform/cloud-docs/users-teams-organizations/users#api-tokens)
or a
@ -112,7 +112,7 @@ organization tokens cannot be used for command-line Terraform actions.
-> **Note:** The credentials hostname must match the hostname in your module
sources and/or backend configuration. If your Terraform Enterprise instance
is available at multiple hostnames, use only one of them consistently.
Terraform Cloud responds to API calls at both its current hostname
HCP Terraform responds to API calls at both its current hostname
`app.terraform.io`, and its historical hostname `atlas.hashicorp.com`.
### Environment Variable Credentials

6
website/docs/cli/config/environment-variables.mdx
View file

@ -169,8 +169,8 @@ export TF_IGNORE=trace
For more details on `.terraformignore`, please see [Excluding Files from Upload with .terraformignore](/terraform/language/settings/backends/remote#excluding-files-from-upload-with-terraformignore).
## Terraform Cloud CLI Integration
## HCP Terraform CLI Integration
The CLI integration with Terraform Cloud lets you use Terraform Cloud and Terraform Enterprise on the command line. The integration requires including a `cloud` block in your Terraform configuration. You can define its arguments directly in your configuration file or supply them through environment variables, which can be useful for non-interactive workflows like Continuous Integration (CI).
The CLI integration with HCP Terraform lets you use HCP Terraform and Terraform Enterprise on the command line. The integration requires including a `cloud` block in your Terraform configuration. You can define its arguments directly in your configuration file or supply them through environment variables, which can be useful for non-interactive workflows like Continuous Integration (CI).
Refer to [Terraform Cloud Settings](/terraform/cli/cloud/settings#environment-variables) for a full list of `cloud` block environment variables.
Refer to [HCP Terraform Settings](/terraform/cli/cloud/settings#environment-variables) for a full list of `cloud` block environment variables.

4
website/docs/cli/import/index.mdx
View file

@ -21,6 +21,6 @@ The `terraform import` CLI command can only import resources into the [state](/t
Before you run `terraform import` you must manually write a `resource` configuration block for the resource. The resource block describes where Terraform should map the imported object.
## Terraform Cloud
## HCP Terraform
When you use Terraform on the command line with Terraform Cloud, many commands like `apply` run inside your Terraform Cloud environment. However, the `import` command runs locally, so it does not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.
When you use Terraform on the command line with HCP Terraform, many commands like `apply` run inside your HCP Terraform environment. However, the `import` command runs locally, so it does not have access to information from HCP Terraform. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in HCP Terraform.

2
website/docs/cli/index.mdx
View file

@ -2,7 +2,7 @@
page_title: Terraform CLI Documentation
description: >-
Learn Terraform's CLI-based workflows. You can use the CLI alone or
with Terraform Cloud or Terraform Enterprise.
with HCP Terraform or Terraform Enterprise.
---
# Terraform CLI Documentation

2
website/docs/cli/test/index.mdx
View file

@ -45,7 +45,7 @@ Terraform test files [have their own configuration syntax](/terraform/language/t
## Validations
Validations allow you to verify aspects of your configuration and infrastructure as it is applied and created. Terraform Cloud also supports automated [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation).
Validations allow you to verify aspects of your configuration and infrastructure as it is applied and created. HCP Terraform also supports automated [continuous validation](/terraform/cloud-docs/workspaces/health#continuous-validation).
The Terraform `test` command also executes any validations within your configuration as part of the tests it executes. For more information on the available validation, refer to [Checks](/terraform/language/checks) and [Custom Conditions](/terraform/language/expressions/custom-conditions).

14
website/docs/cli/workspaces/index.mdx
View file

@ -7,7 +7,7 @@ description: >-
# Managing Workspaces
Workspaces in the Terraform CLI refer to separate instances of [state data](/terraform/language/state) inside the same Terraform working directory. They are distinctly different from [workspaces in Terraform Cloud](/terraform/cloud-docs/workspaces), which each have their own Terraform configuration and function as separate working directories.
Workspaces in the Terraform CLI refer to separate instances of [state data](/terraform/language/state) inside the same Terraform working directory. They are distinctly different from [workspaces in HCP Terraform](/terraform/cloud-docs/workspaces), which each have their own Terraform configuration and function as separate working directories.
Terraform relies on state to associate resources with real-world objects. When you run the same configuration multiple times with separate state data, Terraform can manage multiple sets of non-overlapping resources.
@ -61,16 +61,16 @@ When multiple configurations represent distinct system components rather than mu
- If you store a Terraform state for one configuration in a remote backend that other configurations can access, then the other configurations can use [`terraform_remote_state`](/terraform/language/state/remote-state-data) to directly consume its root module outputs. This setup creates a tighter coupling between configurations, and the root configuration does not need to publish its results in a separate system.
## Interactions with Terraform Cloud Workspaces
## Interactions with HCP Terraform Workspaces
Terraform Cloud organizes infrastructure using workspaces, but its workspaces
act more like completely separate working directories. Each Terraform Cloud
HCP Terraform organizes infrastructure using workspaces, but its workspaces
act more like completely separate working directories. Each HCP Terraform
workspace has its own Terraform configuration, set of variable values, state
data, run history, and settings.
When you [integrate Terraform CLI with Terraform Cloud](/terraform/cli/cloud), you can associate the current CLI working directory with one or more remote Terraform Cloud workspaces. Then, use the `terraform workspace` commands to select the remote workspace you want to use for each run.
When you [integrate Terraform CLI with HCP Terraform](/terraform/cli/cloud), you can associate the current CLI working directory with one or more remote HCP Terraform workspaces. Then, use the `terraform workspace` commands to select the remote workspace you want to use for each run.
Refer to [CLI-driven Runs](/terraform/cloud-docs/run/cli) in the Terraform Cloud documentation for more details.
Refer to [CLI-driven Runs](/terraform/cloud-docs/run/cli) in the HCP Terraform documentation for more details.
## Workspace Internals
@ -83,4 +83,4 @@ For local state, Terraform stores the workspace states in a directory called `te
For [remote state](/terraform/language/state/remote), the workspaces are stored directly in the configured [backend](/terraform/language/settings/backends/configuration). For example, if you use [Consul](/terraform/language/settings/backends/consul), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name must be valid to use in a URL path segment without escaping.
Terraform stores the current workspace name locally in the ignored `.terraform` directory. This allows multiple team members to work on different workspaces concurrently. Workspace names are also attached to associated remote workspaces in Terraform Cloud. For more details about workspace names in Terraform Cloud, refer to the [CLI Integration (recommended)](/terraform/cli/cloud/settings#arguments) and [remote backend](/terraform/language/settings/backends/remote#workspaces) and documentation.
Terraform stores the current workspace name locally in the ignored `.terraform` directory. This allows multiple team members to work on different workspaces concurrently. Workspace names are also attached to associated remote workspaces in HCP Terraform. For more details about workspace names in HCP Terraform, refer to the [CLI Integration (recommended)](/terraform/cli/cloud/settings#arguments) and [remote backend](/terraform/language/settings/backends/remote#workspaces) and documentation.

2
website/docs/internals/login-protocol.mdx
View file

@ -105,7 +105,7 @@ authorization errors once the token expires, after which the user can run
-> **Note:** As a special case, Terraform can use a
[Resource Owner Password Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.3)
only when interacting with `app.terraform.io` ([Terraform Cloud](https://cloud.hashicorp.com/products/terraform)),
only when interacting with `app.terraform.io` ([HCP Terraform](https://cloud.hashicorp.com/products/terraform)),
under the recommendation in the OAuth specification to use this grant type only
when the client and server are closely related. The `password` grant type is
not supported for any other hostname and will be ignored.

28
website/docs/intro/core-workflow.mdx
View file

@ -13,7 +13,7 @@ The core Terraform workflow has three steps:
This guide walks through how each of these three steps plays out in the context
of working as an individual practitioner, how they evolve when a team is
collaborating on infrastructure, and how Terraform Cloud enables this
collaborating on infrastructure, and how HCP Terraform enables this
workflow to run smoothly for entire organizations.
## Working as an Individual Practitioner
@ -215,22 +215,22 @@ Just like the workflow for individuals, the core workflow for teams is a loop
that plays out for each change. For some teams this loop happens a few times a
week, for others, many times a day.
## The Core Workflow Enhanced by Terraform Cloud
## The Core Workflow Enhanced by HCP Terraform
While the above described workflows enable the safe, predictable, and
reproducible creating or changing of infrastructure, there are multiple
collaboration points that can be streamlined, especially as teams and
organizations scale. We designed Terraform Cloud to support and enhance
organizations scale. We designed HCP Terraform to support and enhance
the core Terraform workflow for anyone collaborating on infrastructure, from
small teams to large organizations. Let's look at how Terraform Cloud makes
small teams to large organizations. Let's look at how HCP Terraform makes
for a better experience at each step.
### Write
Terraform Cloud provides a centralized and secure location for storing
HCP Terraform provides a centralized and secure location for storing
input variables and state while also bringing back a tight feedback loop for
speculative plans for config authors. Terraform configuration can interact with
Terraform Cloud through the [CLI integration](/terraform/cli/cloud).
HCP Terraform through the [CLI integration](/terraform/cli/cloud).
```
terraform {
@ -245,7 +245,7 @@ terraform {
}
```
After you configure the integration, a Terraform Cloud API key is all your team members need to edit config and run speculative plans
After you configure the integration, an HCP Terraform API key is all your team members need to edit config and run speculative plans
against the latest version of the state file using all the remotely stored
input variables.
@ -273,7 +273,7 @@ authoring config until it is ready to propose as a change via a pull request.
### Plan
Once a pull request is ready for review, Terraform Cloud makes the process
Once a pull request is ready for review, HCP Terraform makes the process
of reviewing a speculative plan easier for team members. First, the plan is
automatically run when the pull request is created. Status updates to the pull
request indicate while the plan is in progress.
@ -285,17 +285,17 @@ changes in the speculative plan, right from the pull request view.
For certain types of changes, this information is all that's needed for a team
member to be able to approve the pull request. When a teammate needs to do a
full review of the plan, clicking the link to Terraform Cloud brings up a
full review of the plan, clicking the link to HCP Terraform brings up a
view that allows them to quickly analyze the full plan details.
![Screenshot of Pull Request run in Terraform Cloud](/img/docs/pr-plan.png)
![Screenshot of Pull Request run in HCP Terraform](/img/docs/pr-plan.png)
This page allows the reviewer to quickly determine if the plan is matching the
config author's intent and evaluate the risk of the change.
### Apply
After merge, Terraform Cloud presents the concrete plan to the team for
After merge, HCP Terraform presents the concrete plan to the team for
review and approval.
![Screenshot of concrete plan](/img/docs/concrete-plan.png)
@ -303,9 +303,9 @@ review and approval.
The team can discuss any outstanding questions about the plan before the change
is made.
![Screenshot of back-and-forth in Terraform Cloud comments](/img/docs/plan-comments.png)
![Screenshot of back-and-forth in HCP Terraform comments](/img/docs/plan-comments.png)
Once the Apply is confirmed, Terraform Cloud displays the progress live
Once the Apply is confirmed, HCP Terraform displays the progress live
to anyone who'd like to watch.
![Screenshot of in-progress Apply](/img/docs/in-progress-apply.png)
@ -327,5 +327,5 @@ There are many different ways to use Terraform: as an individual user, a single
team, or an entire organization at scale. Choosing the best approach for the
density of collaboration needed will provide the most return on your investment
in the core Terraform workflow. For organizations using Terraform at scale,
Terraform Cloud introduces new layers that build on this core workflow to
HCP Terraform introduces new layers that build on this core workflow to
solve problems unique to teams and organizations.

2
website/docs/intro/index.mdx
View file

@ -52,7 +52,7 @@ Terraform supports reusable configuration components called [modules](/terraform
### Collaborate
Since your configuration is written in a file, you can commit it to a Version Control System (VCS) and use [Terraform Cloud](/terraform/intro/terraform-editions#terraform-cloud) to efficiently manage Terraform workflows across teams. Terraform Cloud runs Terraform in a consistent, reliable environment and provides secure access to shared state and secret data, role-based access controls, a private registry for sharing both modules and providers, and more.
Since your configuration is written in a file, you can commit it to a Version Control System (VCS) and use [HCP Terraform](/terraform/intro/terraform-editions#hcp-terraform) to efficiently manage Terraform workflows across teams. HCP Terraform runs Terraform in a consistent, reliable environment and provides secure access to shared state and secret data, role-based access controls, a private registry for sharing both modules and providers, and more.
-> **Tip:** Learn more about [Terraform use cases](/terraform/intro/use-cases) and [how Terraform compares to alternatives](/terraform/intro/vs).

28
website/docs/intro/terraform-editions.mdx
View file

@ -3,7 +3,7 @@ layout: "intro"
page_title: "Terraform Editions"
sidebar_current: "what"
description: |-
Terraform Community Edition, Terraform Cloud, and Terraform Enterprise solve increasingly complex infrastructure and collaboration challenges.
Terraform Community Edition, HCP Terraform, and Terraform Enterprise solve increasingly complex infrastructure and collaboration challenges.
---
# Terraform Editions
@ -30,38 +30,38 @@ Terraform Community Edition lets you:
- [Configuration Language Documentation](/terraform/language)
- [CLI Documentation](/terraform/cli)
## Terraform Cloud
## HCP Terraform
Terraform Cloud is a SaaS application that runs Terraform in a stable, remote environment and securely stores state and secrets. It includes a rich user interface that helps you better understand your Terraform operations and resources, allows you to define role-based access controls, and offers a private registry for sharing modules and providers. Terraform Cloud also integrates with the Terraform CLI and connects to common version control systems (VCS) like GitHub, GitLab, and Bitbucket. When you connect a Terraform Cloud workspace to a VCS repository, new commits and changes can automatically trigger Terraform plans. Terraform Cloud also offers an API, allowing you to integrate it into existing workflows.
HCP Terraform is a SaaS application that runs Terraform in a stable, remote environment and securely stores state and secrets. It includes a rich user interface that helps you better understand your Terraform operations and resources, allows you to define role-based access controls, and offers a private registry for sharing modules and providers. HCP Terraform also integrates with the Terraform CLI and connects to common version control systems (VCS) like GitHub, GitLab, and Bitbucket. When you connect an HCP Terraform workspace to a VCS repository, new commits and changes can automatically trigger Terraform plans. HCP Terraform also offers an API, allowing you to integrate it into existing workflows.
Many Terraform Cloud features are free for small teams; we offer paid plans for larger organizations with additional collaboration and governance features.
Many HCP Terraform features are free for small teams; we offer paid plans for larger organizations with additional collaboration and governance features.
### Why Terraform Cloud?
### Why HCP Terraform?
Terraform Cloud lets you:
HCP Terraform lets you:
- Run Terraform from the local CLI or in a remote environment, trigger operations through your version control system, or use an API to integrate Terraform Cloud into your existing workflows.
- Ensure that only approved teams can access, edit, and provision infrastructure with Terraform Cloud workspaces, single sign-on, and role-based access controls.
- Run Terraform from the local CLI or in a remote environment, trigger operations through your version control system, or use an API to integrate HCP Terraform into your existing workflows.
- Ensure that only approved teams can access, edit, and provision infrastructure with HCP Terraform workspaces, single sign-on, and role-based access controls.
- Securely store and version Terraform state remotely, with encryption at rest. Versioned state files allow you to access state file history.
- Publish configuration modules in the Terraform Cloud private registry that define approved infrastructure patterns. For example, a module may allow users to choose the cloud provider on which to deploy their Java application. This allows consumers to implement your organization’s best practices without becoming infrastructure or cloud experts.
- Publish configuration modules in the HCP Terraform private registry that define approved infrastructure patterns. For example, a module may allow users to choose the cloud provider on which to deploy their Java application. This allows consumers to implement your organization’s best practices without becoming infrastructure or cloud experts.
- Enforce best practices and security rules with the Sentinel embedded policy as code framework. For example, policies may restrict regions for production deployments.
### Resources
- [Create a Terraform Cloud Account](https://app.terraform.io/public/signup/account)
- [Terraform Cloud Documentation](/terraform/cloud-docs)
- [Create an HCP Terraform Account](https://app.terraform.io/public/signup/account)
- [HCP Terraform Documentation](/terraform/cloud-docs)
- [Sentinel Documentation](/terraform/cloud-docs/policy-enforcement)
- [Get Started - Terraform Cloud](/terraform/tutorials/cloud-get-started) tutorials show you how to manage infrastructure using Terraform Cloud's VCS integration
- [Get Started - HCP Terraform](/terraform/tutorials/cloud-get-started) tutorials show you how to manage infrastructure using HCP Terraform's VCS integration
## Terraform Enterprise
Terraform Enterprise allows you to set up a self-hosted distribution of Terraform Cloud. It offers customizable resource limits and is ideal for organizations with strict security and compliance requirements.
Terraform Enterprise allows you to set up a self-hosted distribution of HCP Terraform. It offers customizable resource limits and is ideal for organizations with strict security and compliance requirements.
### Why Terraform Enterprise?
Terraform Enterprise lets you:
- Set up a private instance of Terraform Cloud with dedicated support from HashiCorp.
- Set up a private instance of HCP Terraform with dedicated support from HashiCorp.
- Accommodate advanced security and compliance requirements. Terraform Enterprise supports several types of installations, including air gapped and active/active architecture, and allows private networking and job scaling for better performance.
### Resources

12
website/docs/intro/use-cases.mdx
View file

@ -33,18 +33,18 @@ You can use Terraform to efficiently deploy, release, scale, and monitor infrast
## Self-Service Clusters
At a large organization, your centralized operations team may get many repetitive infrastructure requests. You can use Terraform to build a "self-serve" infrastructure model that lets product teams manage their own infrastructure independently. You can create and use Terraform modules that codify the standards for deploying and managing services in your organization, allowing teams to efficiently deploy services in compliance with your organization’s practices. Terraform Cloud can also integrate with ticketing systems like ServiceNow to automatically generate new infrastructure requests.
At a large organization, your centralized operations team may get many repetitive infrastructure requests. You can use Terraform to build a "self-serve" infrastructure model that lets product teams manage their own infrastructure independently. You can create and use Terraform modules that codify the standards for deploying and managing services in your organization, allowing teams to efficiently deploy services in compliance with your organization’s practices. HCP Terraform can also integrate with ticketing systems like ServiceNow to automatically generate new infrastructure requests.
### Resources
- Try the [Use Modules from the Registry](/terraform/tutorials/modules/module-use) tutorial to get started using public modules in your Terraform configuration.
Try the [Build and Use a Local Module](/terraform/tutorials/modules/module-create) tutorial to create a module to manage AWS S3 buckets.
- Follow these [ServiceNow Service Catalog Integration Setup Instructions](/terraform/cloud-docs/integrations/service-now) to connect ServiceNow to Terraform Cloud.
- Follow these [ServiceNow Service Catalog Integration Setup Instructions](/terraform/cloud-docs/integrations/service-now) to connect ServiceNow to HCP Terraform.
## Policy Compliance and Management
Terraform can help you enforce policies on the types of resources teams can provision and use. Ticket-based review processes are a bottleneck that can slow down development. Instead, you can use Sentinel, a policy-as-code framework, to automatically enforce compliance and governance policies before Terraform makes infrastructure changes. Sentinel policies are available in Terraform Enterprise and [Terraform Cloud](https://www.hashicorp.com/products/terraform/pricing).
Terraform can help you enforce policies on the types of resources teams can provision and use. Ticket-based review processes are a bottleneck that can slow down development. Instead, you can use Sentinel, a policy-as-code framework, to automatically enforce compliance and governance policies before Terraform makes infrastructure changes. Sentinel policies are available in Terraform Enterprise and [HCP Terraform](https://www.hashicorp.com/products/terraform/pricing).
### Resources
@ -70,17 +70,17 @@ For example, when a service registers with [HashiCorp Consul](https://www.consul
### Resources
- Try the [Network Infrastructure Automation with Consul-Terraform-Sync Intro](/consul/tutorials/network-infrastructure-automation/consul-terraform-sync-intro) tutorial to install Consul-Terraform-Sync on a node. You will then configure it to communicate with a Consul datacenter, react to service changes, and execute an example task.
- Try the [Consul-Terraform-Sync and Terraform Enterprise/Cloud Integration](/consul/tutorials/network-infrastructure-automation/consul-terraform-sync-terraform-enterprise) tutorial to configure Consul-Terraform-Sync to interact with Terraform Enterprise and Terraform Cloud.
- Try the [Consul-Terraform-Sync and Terraform Enterprise/Cloud Integration](/consul/tutorials/network-infrastructure-automation/consul-terraform-sync-terraform-enterprise) tutorial to configure Consul-Terraform-Sync to interact with Terraform Enterprise and HCP Terraform.
## Kubernetes
Kubernetes is an open-source workload scheduler for containerized applications. Terraform lets you both deploy a Kubernetes cluster and manage its resources (e.g., pods, deployments, services, etc.). You can also use the [Kubernetes Operator for Terraform](https://github.com/hashicorp/terraform-k8s) to manage cloud and on-prem infrastructure through a Kubernetes Custom Resource Definition (CRD) and Terraform Cloud.
Kubernetes is an open-source workload scheduler for containerized applications. Terraform lets you both deploy a Kubernetes cluster and manage its resources (e.g., pods, deployments, services, etc.). You can also use the [Kubernetes Operator for Terraform](https://github.com/hashicorp/terraform-k8s) to manage cloud and on-prem infrastructure through a Kubernetes Custom Resource Definition (CRD) and HCP Terraform.
### Resources
- Try the [Manage Kubernetes Resources via Terraform](/terraform/tutorials/kubernetes/kubernetes-provider) tutorial. You will use Terraform to schedule and expose a NGINX deployment on a Kubernetes cluster.
- Try the [Deploy Infrastructure with the Terraform Cloud Operator for Kubernetes](/terraform/tutorials/kubernetes/kubernetes-operator) tutorial. You will configure and deploy the Operator to a Kubernetes cluster and use it to create a Terraform Cloud workspace and provision a message queue for an example application.
- Try the [Deploy Infrastructure with the HCP Terraform Operator for Kubernetes](/terraform/tutorials/kubernetes/kubernetes-operator) tutorial. You will configure and deploy the Operator to a Kubernetes cluster and use it to create an HCP Terraform workspace and provision a message queue for an example application.
## Parallel Environments

4
website/docs/language/checks/index.mdx
View file

@ -71,9 +71,9 @@ Condition arguments within `assert` blocks can refer to scoped data sources with
Check blocks do not currently support [meta-arguments](/terraform/language/resources/syntax#meta-arguments). We are still collecting feedback on this feature, so if your use case would benefit from check blocks supporting meta-arguments, please [let us know](https://github.com/hashicorp/terraform/issues/new/choose).
## Continuous validation in Terraform Cloud
## Continuous validation in HCP Terraform
Terraform Cloud can automatically validate whether checks in a workspace’s configuration continue to pass after Terraform provisions new infrastructure. See [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) for details.
HCP Terraform can automatically validate whether checks in a workspace’s configuration continue to pass after Terraform provisions new infrastructure. See [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) for details.
## Choosing Checks or other Custom Conditions

4
website/docs/language/expressions/custom-conditions.mdx
View file

@ -234,9 +234,9 @@ check "health_check" {
If the condition evaluates to `false`, Terraform produces an [error message](#error-messages) that includes the result of the `error_message` expression. If you declare multiple assertions, Terraform returns error messages for all failed conditions.
### Continuous Validation in Terraform Cloud
### Continuous Validation in HCP Terraform
Terraform Cloud can automatically check whether the checks in a workspace’s configuration continue to pass after Terraform provisions the infrastructure. For example, you can write a `check` to continuously monitor the validity of an API gateway certificate. Continuous validation alerts you when the condition fails, so you can update the certificate and avoid errors the next time you want to update your infrastructure. Refer to [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) in the Terraform Cloud documentation for details.
HCP Terraform can automatically check whether the checks in a workspace’s configuration continue to pass after Terraform provisions the infrastructure. For example, you can write a `check` to continuously monitor the validity of an API gateway certificate. Continuous validation alerts you when the condition fails, so you can update the certificate and avoid errors the next time you want to update your infrastructure. Refer to [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) in the HCP Terraform documentation for details.
## Condition Expressions

2
website/docs/language/files/index.mdx
View file

@ -52,7 +52,7 @@ called by those modules, etc.).
- In Terraform CLI, the root module is the working directory where Terraform is
invoked. (You can use command line options to specify a root module outside
the working directory, but in practice this is rare.)
- In Terraform Cloud and Terraform Enterprise, the root module for a workspace
- In HCP Terraform and Terraform Enterprise, the root module for a workspace
defaults to the top level of the configuration directory (supplied via version
control repository or direct upload), but the workspace settings can specify a
subdirectory to use instead.

4
website/docs/language/functions/terraform-encode_expr.mdx
View file

@ -32,7 +32,7 @@ provider's resource type
which expects variable values to be provided in Terraform expression syntax.
For example, the following concisely declares multiple input variables for
a particular Terraform Cloud workspace:
a particular HCP Terraform workspace:
```hcl
locals {
@ -55,7 +55,7 @@ resource "tfe_variable" "test" {
```
When using this pattern, always set `hcl = true` in the resource declaration
to ensure that Terraform Cloud will expect `value` to be given as Terraform
to ensure that HCP Terraform will expect `value` to be given as Terraform
expression syntax.
We do not recommend using this function in any other situation.

2
website/docs/language/index.mdx
View file

@ -8,7 +8,7 @@ description: >-
This is the documentation for Terraform's configuration language. It is relevant
to users of [Terraform CLI](/terraform/cli),
[Terraform Cloud](https://cloud.hashicorp.com/products/terraform), and
[HCP Terraform](https://cloud.hashicorp.com/products/terraform), and
[Terraform Enterprise](/terraform/enterprise). Terraform's language is
its primary user interface. Configuration files you write in Terraform
language tell Terraform what plugins to install, what infrastructure to create,

6
website/docs/language/modules/develop/index.mdx
View file

@ -70,11 +70,11 @@ your module is not creating any new abstraction and so the module is
adding unnecessary complexity. Just use the resource type directly in the
calling module instead.
### No-Code Provisioning in Terraform Cloud
### No-Code Provisioning in HCP Terraform
You can also create no-code ready modules to enable the no-code provisioning workflow in Terraform Cloud. No-code provisioning lets users deploy a module's resources in Terraform Cloud without writing any Terraform configuration.
You can also create no-code ready modules to enable the no-code provisioning workflow in HCP Terraform. No-code provisioning lets users deploy a module's resources in HCP Terraform without writing any Terraform configuration.
No-code ready modules have additional requirements and considerations. Refer to [Designing No-Code Ready Modules](/terraform/cloud-docs/no-code-provisioning/module-design) in the Terraform Cloud documentation for details.
No-code ready modules have additional requirements and considerations. Refer to [Designing No-Code Ready Modules](/terraform/cloud-docs/no-code-provisioning/module-design) in the HCP Terraform documentation for details.
## Refactoring module resources

2
website/docs/language/modules/index.mdx
View file

@ -44,7 +44,7 @@ download them automatically if you specify the appropriate source and version in
a module call block.
Also, members of your organization might produce modules specifically crafted
for your own infrastructure needs. [Terraform Cloud](https://cloud.hashicorp.com/products/terraform) and
for your own infrastructure needs. [HCP Terraform](https://cloud.hashicorp.com/products/terraform) and
[Terraform Enterprise](/terraform/enterprise) both include a private
module registry for sharing modules internally within your organization.

14
website/docs/language/modules/sources.mdx
View file

@ -98,7 +98,7 @@ community.
You can also use a
[private registry](/terraform/registry/private), either
via the built-in feature from Terraform Cloud, or by running a custom
via the built-in feature from HCP Terraform, or by running a custom
service that implements
[the module registry protocol](/terraform/registry/api-docs).
@ -128,13 +128,13 @@ module "consul" {
}
```
If you are using the SaaS version of Terraform Cloud, its private
If you are using the SaaS version of HCP Terraform, its private
registry hostname is `app.terraform.io`. If you use a self-hosted Terraform
Enterprise instance, its private registry hostname is the same as the host
where you'd access the web UI and the host you'd use when configuring
the [Terraform Cloud CLI integration](/terraform/cli/cloud).
the [HCP Terraform CLI integration](/terraform/cli/cloud).
Both Terraform Cloud and self-hosted Terraform Enterprise support a [generic hostname](/terraform/cloud-docs/registry/using#generic-hostname-terraform-cloud-and-terraform-enterprise) `localterraform.com`.
Both HCP Terraform and self-hosted Terraform Enterprise support a [generic hostname](/terraform/cloud-docs/registry/using#generic-hostname-terraform-cloud-and-terraform-enterprise) `localterraform.com`.
Registry modules support versioning. You can provide a specific version as shown
in the above examples, or use flexible
@ -146,7 +146,7 @@ You can learn more about the registry at the
To access modules from a private registry, you may need to configure an access
token [in the CLI config](/terraform/cli/config/config-file#credentials). Use the
same hostname as used in the module source string. For a private registry
within Terraform Cloud, use the same authentication token as you would
within HCP Terraform, use the same authentication token as you would
use with the Enterprise API or command-line clients.
## GitHub
@ -229,7 +229,7 @@ username/password credentials, configure
[Git Credentials Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage)
to select a suitable source of credentials for your environment.
If your Terraform configuration will be used within [Terraform Cloud](https://www.hashicorp.com/products/terraform),
If your Terraform configuration will be used within [HCP Terraform](https://www.hashicorp.com/products/terraform),
only SSH key authentication is supported, and
[keys can be configured on a per-workspace basis](/terraform/cloud-docs/workspaces/settings/ssh-keys).
@ -321,7 +321,7 @@ automatically. This is the most common way to access non-public Mercurial
repositories from automated systems because it allows access to private
repositories without interactive prompts.
If your Terraform configuration will be used within [Terraform Cloud](https://www.hashicorp.com/products/terraform),
If your Terraform configuration will be used within [HCP Terraform](https://www.hashicorp.com/products/terraform),
only SSH key authentication is supported, and
[keys can be configured on a per-workspace basis](/terraform/cloud-docs/workspaces/settings/ssh-keys).

2
website/docs/language/modules/syntax.mdx
View file

@ -102,7 +102,7 @@ version that meets the constraint.
Version constraints are supported only for modules installed from a module
registry, such as the public [Terraform Registry](https://registry.terraform.io/)
or [Terraform Cloud's private module registry](/terraform/cloud-docs/registry).
or [HCP Terraform's private module registry](/terraform/cloud-docs/registry).
Other module sources can provide their own versioning mechanisms within the
source string itself, or might not support versions at all. In particular,
modules sourced from local file paths do not support `version`; since

4
website/docs/language/providers/index.mdx
View file

@ -72,7 +72,7 @@ about it in your configuration. See the following pages for details:
## Provider Installation
- Terraform Cloud and Terraform Enterprise install providers as part of every run.
- HCP Terraform and Terraform Enterprise install providers as part of every run.
- Terraform CLI finds and installs providers when
[initializing a working directory](/terraform/cli/init). It can
@ -88,7 +88,7 @@ To ensure Terraform always installs the same provider versions for a given
configuration, you can use Terraform CLI to create a
[dependency lock file](/terraform/language/files/dependency-lock)
and commit it to version control along with your configuration. If a lock file
is present, Terraform Cloud, CLI, and Enterprise will all obey it when
is present, HCP Terraform, CLI, and Enterprise will all obey it when
installing providers.
> **Hands-on:** Try the [Lock and Upgrade Provider Versions](/terraform/tutorials/configuration-language/provider-versioning?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.

4
website/docs/language/providers/requirements.mdx
View file

@ -129,7 +129,7 @@ Examples of valid provider source address formats include:
[the public Terraform Registry](https://registry.terraform.io/).
* **Namespace:** An organizational namespace within the specified registry.
For the public Terraform Registry and for Terraform Cloud's private registry,
For the public Terraform Registry and for HCP Terraform's private registry,
this represents the organization that publishes the provider. This field
may have other meanings for other registry hosts.
@ -226,7 +226,7 @@ To ensure Terraform always installs the same provider versions for a given
configuration, you can use Terraform CLI to create a
[dependency lock file](/terraform/language/files/dependency-lock)
and commit it to version control along with your configuration. If a lock file
is present, Terraform Cloud, CLI, and Enterprise will all obey it when
is present, HCP Terraform, CLI, and Enterprise will all obey it when
installing providers.
> **Hands-on:** Try the [Lock and Upgrade Provider Versions](/terraform/tutorials/configuration-language/provider-versioning) tutorial.

8
website/docs/language/settings/backends/configuration.mdx
View file

@ -8,11 +8,11 @@ description: >-
A backend defines where Terraform stores its [state](/terraform/language/state) data files.
Terraform uses persisted state data to keep track of the resources it manages. Most non-trivial Terraform configurations either [integrate with Terraform Cloud](/terraform/language/settings/terraform-cloud) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
Terraform uses persisted state data to keep track of the resources it manages. Most non-trivial Terraform configurations either [integrate with HCP Terraform](/terraform/language/settings/cloud) or use a backend to store state remotely. This lets multiple people access the state data and work together on that collection of infrastructure resources.
This page describes how to configure a backend by adding the [`backend` block](#using-a-backend-block) to your configuration.
-> **Note:** In Terraform versions before 1.1.0, we classified backends as standard or enhanced. The enhanced label differentiated the [`remote` backend](/terraform/language/settings/backends/remote), which could both store state and perform Terraform operations. This classification has been removed. Refer to [Using Terraform Cloud](/terraform/cli/cloud) for details about storing state, executing remote operations, and using Terraform Cloud directly from Terraform.
-> **Note:** In Terraform versions before 1.1.0, we classified backends as standard or enhanced. The enhanced label differentiated the [`remote` backend](/terraform/language/settings/backends/remote), which could both store state and perform Terraform operations. This classification has been removed. Refer to [Using HCP Terraform](/terraform/cli/cloud) for details about storing state, executing remote operations, and using HCP Terraform directly from Terraform.
## Available Backends
@ -24,8 +24,8 @@ Some of these backends act like plain remote disks for state files, while others
## Using a Backend Block
You do not need to configure a backend when using Terraform Cloud because
Terraform Cloud automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](/terraform/language/settings/terraform-cloud), it cannot include a `backend` block.
You do not need to configure a backend when using HCP Terraform because
HCP Terraform automatically manages state in the workspaces associated with your configuration. If your configuration includes a [`cloud` block](/terraform/language/settings/cloud), it cannot include a `backend` block.
To configure a backend, add a nested `backend` block within the top-level
`terraform` block. The following example configures the `remote` backend.

38
website/docs/language/settings/backends/remote.mdx
View file

@ -7,14 +7,14 @@ description: >-
# remote
-> **Note:** We introduced the remote backend in Terraform v0.11.13 and Terraform Enterprise v201809-1. As of Terraform v1.1.0 and Terraform Enterprise v202201-1, **we recommend using the Terraform Cloud's built-in [`cloud` integration](/terraform/cli/cloud/settings)** instead of this backend. The `cloud` option includes an improved user experience and more features.
-> **Note:** We introduced the remote backend in Terraform v0.11.13 and Terraform Enterprise v201809-1. As of Terraform v1.1.0 and Terraform Enterprise v202201-1, **we recommend using the HCP Terraform's built-in [`cloud` integration](/terraform/cli/cloud/settings)** instead of this backend. The `cloud` option includes an improved user experience and more features.
The remote backend is unique among all other Terraform backends because it can both store state snapshots and execute operations for Terraform Cloud's [CLI-driven run workflow](/terraform/cloud-docs/run/cli). It used to be called an "enhanced" backend.
The remote backend is unique among all other Terraform backends because it can both store state snapshots and execute operations for HCP Terraform's [CLI-driven run workflow](/terraform/cloud-docs/run/cli). It used to be called an "enhanced" backend.
When using full remote operations, operations like `terraform plan` or `terraform apply` can be executed in Terraform
Cloud's run environment, with log output streaming to the local terminal. Remote plans and applies use variable values from the associated Terraform Cloud workspace.
Cloud's run environment, with log output streaming to the local terminal. Remote plans and applies use variable values from the associated HCP Terraform workspace.
You can also use Terraform Cloud with local operations, in which case only state is stored in the Terraform Cloud backend.
You can also use HCP Terraform with local operations, in which case only state is stored in the HCP Terraform backend.
## Command Support
@ -41,18 +41,18 @@ The remote backend supports the following Terraform commands:
## Workspaces
The remote backend can work with either a single remote Terraform Cloud workspace, or with multiple similarly-named remote workspaces (like `networking-dev` and `networking-prod`). The `workspaces` block of the backend configuration
The remote backend can work with either a single remote HCP Terraform workspace, or with multiple similarly-named remote workspaces (like `networking-dev` and `networking-prod`). The `workspaces` block of the backend configuration
determines which mode it uses:
- To use a single remote Terraform Cloud workspace, set `workspaces.name` to the
- To use a single remote HCP Terraform workspace, set `workspaces.name` to the
remote workspace's full name (like `networking-prod`).
- To use multiple remote workspaces, set `workspaces.prefix` to a prefix used in
all of the desired remote workspace names. For example, set
`prefix = "networking-"` to use Terraform cloud workspaces with
`prefix = "networking-"` to use HCP Terraform workspaces with
names like `networking-dev` and `networking-prod`. This is helpful when
mapping multiple Terraform CLI [workspaces](/terraform/language/state/workspaces)
used in a single Terraform configuration to multiple Terraform Cloud
used in a single Terraform configuration to multiple HCP Terraform
workspaces.
@ -62,37 +62,37 @@ setting both results in a configuration error.
If previous state is present when you run `terraform init` and the corresponding
remote workspaces are empty or absent, Terraform will create workspaces and
update the remote state accordingly. However, if your workspace requires variables or a specific version of Terraform for remote operations, we
recommend that you create your remote workspaces on Terraform Cloud before
recommend that you create your remote workspaces on HCP Terraform before
running any remote operations against them.
### Workspace Names
Terraform uses shortened names without the common prefix to interact with workspaces on the command line. For example, if `prefix = "networking-"`, use `terraform workspace select prod` to switch to the Terraform CLI workspace `prod` within the current configuration. However, remote Terraform operations such as `plan` and `apply` for that Terraform CLI workspace will take place in the Terraform Cloud workspace `networking-prod`.
Terraform uses shortened names without the common prefix to interact with workspaces on the command line. For example, if `prefix = "networking-"`, use `terraform workspace select prod` to switch to the Terraform CLI workspace `prod` within the current configuration. However, remote Terraform operations such as `plan` and `apply` for that Terraform CLI workspace will take place in the HCP Terraform workspace `networking-prod`.
Because of this, the [`terraform.workspace`](/terraform/language/state/workspaces#current-workspace-interpolation) interpolation expression produces different results depending on whether a remote workspace is configured to perform operations locally or remotely. For example, in a remote workspace called `networking-prod` created with `prefix = "networking-"` the expression produces the following:
- For local operations, `terraform.workspace` = `prod`
- For remote operations, `terraform.workspace`= `networking-prod`
Prior to Terraform version 1.1.0, Terraform Cloud workspaces used only the single `default` Terraform CLI workspace internally. So if a Terraform configuration used `terraform.workspace` to return `dev` or `prod`, remote runs in Terraform Cloud would always evaluate it as `default`, regardless of
which workspace you set with the `terraform workspace select` command. Therefore, we do not recommend using `terraform.workspace` in Terraform configurations that use Terraform 1.0.x or earlier and run remote operations against Terraform Cloud workspaces.
Prior to Terraform version 1.1.0, HCP Terraform workspaces used only the single `default` Terraform CLI workspace internally. So if a Terraform configuration used `terraform.workspace` to return `dev` or `prod`, remote runs in HCP Terraform would always evaluate it as `default`, regardless of
which workspace you set with the `terraform workspace select` command. Therefore, we do not recommend using `terraform.workspace` in Terraform configurations that use Terraform 1.0.x or earlier and run remote operations against HCP Terraform workspaces.
### Determining Run Environment
If you need to determine whether a run is local or remote in your Terraform configuration, we recommend using [Terraform Cloud run environment variables](/terraform/cloud-docs/run/run-environment#environment-variables). The example below uses `TFC_RUN_ID`.
If you need to determine whether a run is local or remote in your Terraform configuration, we recommend using [HCP Terraform run environment variables](/terraform/cloud-docs/run/run-environment#environment-variables). The example below uses `HCP_TERRAFORM_RUN_ID`.
```
output "current_workspace_name" {
value = terraform.workspace
}
variable "TFC_RUN_ID" {
variable "HCP_TERRAFORM_RUN_ID" {
type = string
default = ""
}
output "remote_execution_determine" {
value = "Remote run environment? %{if var.TFC_RUN_ID != ""}Yes%{else}No this is local%{endif}!"
value = "Remote run environment? %{if var.HCP_TERRAFORM_RUN_ID != ""}Yes%{else}No this is local%{endif}!"
}
```
@ -195,12 +195,12 @@ The following configuration options are supported:
only the default workspace can be used. This option conflicts with `prefix`.
- `prefix` - (Optional) A prefix used in the names of one or more remote
workspaces, all of which can be used with this configuration. The full
workspace names are used in Terraform Cloud, and the short names
workspace names are used in HCP Terraform, and the short names
(minus the prefix) are used on the command line for Terraform CLI workspaces.
If omitted, only the default workspace can be used. This option conflicts with `name`.
-> **Note:** You must use the `name` key when configuring a `terraform_remote_state`
data source that retrieves state from another Terraform Cloud workspace. The `prefix` key is only
data source that retrieves state from another HCP Terraform workspace. The `prefix` key is only
intended for use when configuring an instance of the remote backend.
## Command Line Arguments
@ -219,7 +219,7 @@ the remote workspace accept the following option to modify that behavior:
local operation creating a new state snapshot which the workspace's
remote execution environment would then be unable to decode.
Overriding this check can result in a Terraform Cloud workspace that is
Overriding this check can result in an HCP Terraform workspace that is
no longer able to complete remote operations, so we recommend against
using this option.
@ -228,7 +228,7 @@ the remote workspace accept the following option to modify that behavior:
-> **Version note:** `.terraformignore` support was added in Terraform 0.12.11.
When executing a remote `plan` or `apply` in a [CLI-driven run](/terraform/cloud-docs/run/cli),
an archive of your configuration directory is uploaded to Terraform Cloud. You can define
an archive of your configuration directory is uploaded to HCP Terraform. You can define
paths to ignore from upload via a `.terraformignore` file at the root of your configuration directory. If this file is not present, the archive will exclude the following by default:
- `.git/` directories

35
website/docs/language/settings/cloud.mdx Normal file
View file

@ -0,0 +1,35 @@
---
page_title: HCP Terraform Configuration - Terraform Settings - Configuration Language
description: >-
The nested `cloud` block configures Terraform's integration with HCP Terraform.
---
# HCP Terraform Configuration
The main module of a Terraform configuration can integrate with HCP Terraform to enable its [CLI-driven run workflow](/terraform/cloud-docs/run/cli). You only need to configure these settings when you want to use Terraform CLI to interact with HCP Terraform. HCP Terraform ignores them when interacting with
Terraform through version control or the API.
> **Hands On:** Try the [Migrate State to HCP Terraform](/terraform/tutorials/cloud/cloud-migrate) tutorial.
## Usage Example
To configure the HCP Terraform CLI integration, add a nested `cloud` block within the `terraform` block. You cannot use the CLI integration and a [state backend](/terraform/language/settings/backends/configuration) in the same configuration.
Refer to [Using HCP Terraform](/terraform/cli/cloud) in the Terraform CLI documentation for full configuration details, migration instructions, and command line arguments.
```hcl
terraform {
cloud {
organization = "example_corp"
## Required for Terraform Enterprise; Defaults to app.terraform.io for HCP Terraform
hostname = "app.terraform.io"
workspaces {
tags = ["app"]
}
}
}
```

14
website/docs/language/settings/index.mdx
View file

@ -2,7 +2,7 @@
page_title: Terraform Settings - Configuration Language
description: >-
The terraform block allows you to configure Terraform behavior, including the
Terraform version, backend, integration with Terraform Cloud, and required
Terraform version, backend, integration with HCP Terraform, and required
providers.
---
@ -30,15 +30,15 @@ etc, and may not use any of the Terraform language built-in functions.
The various options supported within a `terraform` block are described in the
following sections.
## Configuring Terraform Cloud
## Configuring HCP Terraform
The nested `cloud` block configures Terraform Cloud for enabling its
The nested `cloud` block configures HCP Terraform for enabling its
[CLI-driven run workflow](/terraform/cloud-docs/run/cli).
- Refer to [Terraform Cloud Configuration](/terraform/language/settings/terraform-cloud) for a summary of the `cloud` block's syntax.
- Refer to [HCP Terraform Configuration](/terraform/language/settings/cloud) for a summary of the `cloud` block's syntax.
- Refer to [Using Terraform Cloud](/terraform/cli/cloud) in the
Terraform CLI documentation for complete details about how to initialize and configure the Terraform Cloud CLI integration.
- Refer to [Using HCP Terraform](/terraform/cli/cloud) in the
Terraform CLI documentation for complete details about how to initialize and configure the HCP Terraform CLI integration.
## Configuring a Terraform Backend
@ -49,7 +49,7 @@ Configuration](/terraform/language/settings/backends/configuration).
## Specifying a Required Terraform Version
> **Hands-on:** Try the [Manage Terraform Versions](/terraform/tutorials/configuration-language/versions) or [Manage Terraform Versions in Terraform Cloud](/terraform/tutorials/cloud/cloud-versions) tutorials.
> **Hands-on:** Try the [Manage Terraform Versions](/terraform/tutorials/configuration-language/versions) or [Manage Terraform Versions in HCP Terraform](/terraform/tutorials/cloud/cloud-versions) tutorials.
The `required_version` setting accepts a [version constraint
string,](/terraform/language/expressions/version-constraints) which specifies which versions of Terraform

36
website/docs/language/settings/terraform-cloud.mdx
View file

@ -1,36 +0,0 @@
---
page_title: Terraform Cloud Configuration - Terraform Settings - Configuration Language
description: >-
The nested `cloud` block configures Terraform's integration with Terraform
Cloud.
---
# Terraform Cloud Configuration
The main module of a Terraform configuration can integrate with Terraform Cloud to enable its [CLI-driven run workflow](/terraform/cloud-docs/run/cli). You only need to configure these settings when you want to use Terraform CLI to interact with Terraform Cloud. Terraform Cloud ignores them when interacting with
Terraform through version control or the API.
> **Hands On:** Try the [Migrate State to Terraform Cloud](/terraform/tutorials/cloud/cloud-migrate) tutorial.
## Usage Example
To configure the Terraform Cloud CLI integration, add a nested `cloud` block within the `terraform` block. You cannot use the CLI integration and a [state backend](/terraform/language/settings/backends/configuration) in the same configuration.
Refer to [Using Terraform Cloud](/terraform/cli/cloud) in the Terraform CLI documentation for full configuration details, migration instructions, and command line arguments.
```hcl
terraform {
cloud {
organization = "example_corp"
## Required for Terraform Enterprise; Defaults to app.terraform.io for Terraform Cloud
hostname = "app.terraform.io"
workspaces {
tags = ["app"]
}
}
}
```

2
website/docs/language/state/index.mdx
View file

@ -13,7 +13,7 @@ resources to your configuration, keep track of metadata, and to improve
performance for large infrastructures.
This state is stored by default in a local file named "terraform.tfstate",
but we recommend [storing it in Terraform Cloud](/terraform/cloud-docs/migrate)
but we recommend [storing it in HCP Terraform](/terraform/cloud-docs/migrate)
to version, encrypt, and securely share it with your team.
Terraform uses state to determine which changes to make to your

4
website/docs/language/state/remote-state-data.mdx
View file

@ -14,7 +14,7 @@ from some other Terraform configuration.
You can use the `terraform_remote_state` data source without requiring or configuring a provider. It is always available through a built-in provider with the [source address](/terraform/language/providers/requirements#source-addresses) `terraform.io/builtin/terraform`. That provider does not include any other resources or data sources.
~> **Important:** We recommend using the [`tfe_outputs` data source](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) in the [Terraform Cloud/Enterprise Provider](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) to access remote state outputs in Terraform Cloud or Terraform Enterprise. The `tfe_outputs` data source is more secure because it does not require full access to workspace state to fetch outputs.
~> **Important:** We recommend using the [`tfe_outputs` data source](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) in the [HCP Terraform/Enterprise Provider](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs) to access remote state outputs in HCP Terraform or Terraform Enterprise. The `tfe_outputs` data source is more secure because it does not require full access to workspace state to fetch outputs.
## Alternative Ways to Share Data Between Configurations
@ -42,7 +42,7 @@ limited to) the following:
| Google Cloud DNS<br /><small>(for IP addresses and hostnames)</small> | [`google_dns_record_set` resource type](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/dns_record_set) | Normal DNS lookups, or [the `dns` provider](https://registry.terraform.io/providers/hashicorp/dns/latest/docs) |
| Google Cloud Storage | [`google_storage_bucket_object` resource type](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/storage_bucket_object) | [`google_storage_bucket_object` data source](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/storage_bucket_object) and [`http` data source](https://registry.terraform.io/providers/hashicorp/http/latest/docs/data-sources/http) |
| HashiCorp Consul | [`consul_key_prefix` resource type](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/resources/key_prefix) | [`consul_key_prefix` data source](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/data-sources/key_prefix) |
| HashiCorp Terraform Cloud | Normal `outputs` terraform block | [`tfe_outputs` data source](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) |
| HashiCorp HCP Terraform | Normal `outputs` terraform block | [`tfe_outputs` data source](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) |
| Kubernetes | [`kubernetes_config_map` resource type](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/config_map) | [`kubernetes_config_map` data source](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/data-sources/config_map) |
| OCI Object Storage | [`oci_objectstorage_bucket` resource type](https://registry.terraform.io/providers/hashicorp/oci/latest/docs/resources/objectstorage_object) | [`oci_objectstorage_bucket` data source](https://registry.terraform.io/providers/hashicorp/oci/latest/docs/data-sources/objectstorage_object) |

6
website/docs/language/state/remote.mdx
View file

@ -15,11 +15,11 @@ Terraform at the same time.
With _remote_ state, Terraform writes the state data to a remote data store,
which can then be shared between all members of a team. Terraform supports
storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/),
storing state in [HCP Terraform](https://www.hashicorp.com/products/terraform/),
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
Remote state is implemented by a [backend](/terraform/language/settings/backends/configuration) or by
Terraform Cloud, both of which you can configure in your configuration's root module.
HCP Terraform, both of which you can configure in your configuration's root module.
## Delegation and Teamwork
@ -55,7 +55,7 @@ For fully-featured remote backends, Terraform can also use
[state locking](/terraform/language/state/locking) to prevent concurrent runs of
Terraform against the same state.
[Terraform Cloud by HashiCorp](https://www.hashicorp.com/products/terraform/)
[HCP Terraform by HashiCorp](https://www.hashicorp.com/products/terraform/)
is a commercial offering that supports an even stronger locking concept that
can also detect attempts to create a new plan when an existing plan is already
awaiting approval, by queuing Terraform operations in a central location.

4
website/docs/language/state/sensitive-data.mdx
View file

@ -27,8 +27,8 @@ and some backends can be configured to encrypt the state data at rest.
For example:
- [Terraform Cloud](https://cloud.hashicorp.com/products/terraform) always encrypts state at rest and
protects it with TLS in transit. Terraform Cloud also knows the identity of
- [HCP Terraform](https://cloud.hashicorp.com/products/terraform) always encrypts state at rest and
protects it with TLS in transit. HCP Terraform also knows the identity of
the user requesting state and maintains a history of state changes. This can
be used to control access and track activity. [Terraform Enterprise](/terraform/enterprise)
also supports detailed audit logging.

2
website/docs/language/state/workspaces.mdx
View file

@ -12,7 +12,7 @@ Each Terraform configuration has an associated [backend](/terraform/language/set
The persistent data stored in the backend belongs to a workspace. The backend initially has only one workspace containing one Terraform state associated with that configuration. Some backends support multiple named workspaces, allowing multiple states to be associated with a single configuration. The configuration still has only one backend, but you can deploy multiple distinct instances of that configuration without configuring a new backend or changing authentication
credentials.
-> **Note**: The Terraform CLI workspaces are different from [workspaces in Terraform Cloud](/terraform/cloud-docs/workspaces). Refer to [Initializing and Migrating](/terraform/cli/cloud/migrating) for details about migrating a configuration with multiple workspaces to Terraform Cloud.
-> **Note**: The Terraform CLI workspaces are different from [workspaces in HCP Terraform](/terraform/cloud-docs/workspaces). Refer to [Initializing and Migrating](/terraform/cli/cloud/migrating) for details about migrating a configuration with multiple workspaces to HCP Terraform.
## Backends Supporting Multiple Workspaces

28
website/docs/language/style.mdx
View file

@ -77,7 +77,7 @@ The `terraform fmt` command formats your Terraform configuration to a subset of
We recommend that you run `terraform fmt` before each commit to version control. You can use mechanisms such as [Git pre-commit hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) to automatically run this command each time you commit your code.
If you use Microsoft VS Code, use the [Terraform VS Code extension](https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform) to enable features such as syntax highlighting and validation, automatic code formatting, and integration with Terraform Cloud. If your development environment or text editor supports the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/), you can use the [Terraform Language Server](https://github.com/hashicorp/terraform-ls) to access most of the VS Code extension features.
If you use Microsoft VS Code, use the [Terraform VS Code extension](https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform) to enable features such as syntax highlighting and validation, automatic code formatting, and integration with HCP Terraform. If your development environment or text editor supports the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/), you can use the [Terraform Language Server](https://github.com/hashicorp/terraform-ls) to access most of the VS Code extension features.
## Code validation
@ -449,12 +449,12 @@ For an example, refer to [GitHub's Terraform .gitignore file](https://github.com
This section reviews standards that enable predictable and secure Terraform workflows, such as:
- Pin your Terraform, provider, and module versions.
- Name your module repositories using this three-part name `terraform-<PROVIDER>-<NAME>` when using the Terraform Cloud registry.
- Name your module repositories using this three-part name `terraform-<PROVIDER>-<NAME>` when using the HCP Terraform registry.
- Store local modules at `./modules/<module_name>`.
- Use the [`tfe_outputs`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) data source or provider-specific data sources to share state between two state files.
- Protect credentials by using [dynamic provider credentials](/terraform/tutorials/cloud/dynamic-credentials) or a secrets manager such as HashiCorp Vault.
- Write [tests](/terraform/language/tests) for your modules.
- Use [policy enforcement](/terraform/cloud-docs/policy-enforcement) on Terraform Cloud to set guardrails for infrastructure operations.
- Use [policy enforcement](/terraform/cloud-docs/policy-enforcement) on HCP Terraform to set guardrails for infrastructure operations.
## Version pinning
@ -516,7 +516,7 @@ Review the [module creation recommended pattern documentation](/terraform/tutori
## Local modules
Local modules are sourced from local disk rather than a remote module registry. We recommend publishing your modules to a module registry, such as the [Terraform Cloud private module registry](/terraform/cloud-docs/registry), to easily version, share, and reuse modules across your organization. If you cannot use a module registry, using local modules can simplify maintaining and updating your code.
Local modules are sourced from local disk rather than a remote module registry. We recommend publishing your modules to a module registry, such as the [HCP Terraform private registry](/terraform/cloud-docs/registry), to easily version, share, and reuse modules across your organization. If you cannot use a module registry, using local modules can simplify maintaining and updating your code.
We recommend that you define child modules in the `./modules/<module_name>` directory.
@ -556,7 +556,7 @@ Another approach is to group all modules and infrastructure configuration into a
The advantage of monolithic repositories is having a single source of truth that tracks every infrastructure change. However, monolithic repositories can complicate your CI/CD automation: since any code change triggers a deployment that operates on your entire repository, your workflow must target only the modified directories. You also lose the granular access control, since anyone with repository access can modify any file in it.
If your organization requires a monolithic approach, Terraform Cloud and Terraform Enterprise let you scope a workspace to a specific directory in a repository, simplifying your workflows.
If your organization requires a monolithic approach, HCP Terraform and Terraform Enterprise let you scope a workspace to a specific directory in a repository, simplifying your workflows.
## Branching strategy
@ -569,11 +569,11 @@ To collaborate on your Terraform code, we recommend using the [GitHub flow](http
1. Merge the pull request
1. Delete the branch
Terraform Cloud and Terraform Enterprise can run [speculative plans for pull requests](/terraform/cloud-docs/run/ui#speculative-plans-on-pull-requests). These speculative plans run automatically when you create or update a pull request, and you can use them to see the effect that your changes will have on your infrastructure before you merge them to your main branch. When you merge your pull request, Terraform Cloud will start a new run to apply these changes.
HCP Terraform and Terraform Enterprise can run [speculative plans for pull requests](/terraform/cloud-docs/run/ui#speculative-plans-on-pull-requests). These speculative plans run automatically when you create or update a pull request, and you can use them to see the effect that your changes will have on your infrastructure before you merge them to your main branch. When you merge your pull request, HCP Terraform will start a new run to apply these changes.
## Multiple environments
We recommend that your repository's `main` branch be the source of truth for all environments. For Terraform Cloud and Terraform Enterprise users, we recommend that you use separate workspaces for each environment. For larger codebases, we recommend that you split your resources across multiple workspaces to prevent large state files and limit unintended consequences from changes. For example, you could structure your code as follows:
We recommend that your repository's `main` branch be the source of truth for all environments. For HCP Terraform and Terraform Enterprise users, we recommend that you use separate workspaces for each environment. For larger codebases, we recommend that you split your resources across multiple workspaces to prevent large state files and limit unintended consequences from changes. For example, you could structure your code as follows:
<CodeBlockConfig hideClipboard>
@ -597,7 +597,7 @@ We recommend that your repository's `main` branch be the source of truth for all
In this scenario, you would create three workspaces per environment. For example, your production environment would have a `prod-compute`, `prod-database`, and `prod-networking` workspace. Read more about [Terraform workspace and project best practices](/well-architected-framework/operational-excellence/operational-excellence-workspaces-projects).
If you do not use Terraform Cloud or Terraform Enterprise, we recommend that you use modules to encapsulate your configuration, and use a directory for each environment so that each one has a separate state file. The configuration in each of these directories would call the local modules, each with parameters specific to their environment. This also lets you maintain separate variable and backend configurations for each environment.
If you do not use HCP Terraform or Terraform Enterprise, we recommend that you use modules to encapsulate your configuration, and use a directory for each environment so that each one has a separate state file. The configuration in each of these directories would call the local modules, each with parameters specific to their environment. This also lets you maintain separate variable and backend configurations for each environment.
<CodeBlockConfig hideClipboard>
@ -629,19 +629,19 @@ If you do not use Terraform Cloud or Terraform Enterprise, we recommend that you
Since your state contains sensitive information, avoid sharing full state files when possible.
If you use Terraform Cloud or Terraform Enterprise and need to reference resources across workspaces, use the [`tfe_outputs`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) data source.
If you use HCP Terraform or Terraform Enterprise and need to reference resources across workspaces, use the [`tfe_outputs`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) data source.
If you do not use Terraform Cloud or Terraform Enterprise but still need to reference data about other infrastructure resources, use data sources to query the provider. For example, you can use the [`aws_instance` data source](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/instance) to look up an AWS EC2 instance by its ID or tags.
If you do not use HCP Terraform or Terraform Enterprise but still need to reference data about other infrastructure resources, use data sources to query the provider. For example, you can use the [`aws_instance` data source](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/instance) to look up an AWS EC2 instance by its ID or tags.
## Secrets management
If you do not configure remote state storage, the Terraform CLI stores the entire state in plaintext on the local disk. State can include sensitive data, such as passwords and private keys. Terraform Cloud and Terraform Enterprise provide state encryption through HashiCorp Vault.
If you do not configure remote state storage, the Terraform CLI stores the entire state in plaintext on the local disk. State can include sensitive data, such as passwords and private keys. HCP Terraform and Terraform Enterprise provide state encryption through HashiCorp Vault.
If you use Terraform Cloud or Terraform Enterprise, we recommend the following:
If you use HCP Terraform or Terraform Enterprise, we recommend the following:
- When using Terraform Enterprise, define and enforce a Sentinel policy to prevent use of the `local_exec` provisioner or external data sources.
- When using Terraform Cloud or Terraform Enterprise, use [dynamic provider credentials](/terraform/tutorials/cloud/dynamic-credentials) to avoid using long-lived static credentials.
- When using HCP Terraform or Terraform Enterprise, use [dynamic provider credentials](/terraform/tutorials/cloud/dynamic-credentials) to avoid using long-lived static credentials.
If you use Terraform Community Edition, we recommend the following:
@ -663,7 +663,7 @@ Tests differ from validation methods such as variable validation, preconditions,
## Policy
Policies are rules that Terraform Cloud enforces on Terraform runs. You can use policies to validate that the Terraform plan complies with your organization's best practices. For example, you can write policies that:
Policies are rules that HCP Terraform enforces on Terraform runs. You can use policies to validate that the Terraform plan complies with your organization's best practices. For example, you can write policies that:
- Limit the size of a web instance
- Check for required resource tags

10
website/docs/language/v1-compatibility-promises.mdx
View file

@ -301,13 +301,13 @@ order to use those plugins, and state storage backends other than those
listed above may be removed from later versions of Terraform CLI once
equivalent plugins are available.
### The `remote` Backend and Terraform Cloud
### The `remote` Backend and HCP Terraform
The `remote` backend is maintained by the Terraform Cloud team and so its
behavior may change along with ongoing changes to Terraform Cloud.
The `remote` backend is maintained by the HCP Terraform team and so its
behavior may change along with ongoing changes to HCP Terraform.
There will be a supported mechanism to use Terraform CLI with Terraform Cloud
throughout the v1.x releases, but the exact details may change. Terraform Cloud
There will be a supported mechanism to use Terraform CLI with HCP Terraform
throughout the v1.x releases, but the exact details may change. HCP Terraform
evolves independently of Terraform CLI and is therefore not subject to these
compatibility promises.

6
website/docs/language/values/variables.mdx
View file

@ -328,7 +328,7 @@ the module where it was declared.
When variables are declared in the root module of your configuration, they
can be set in a number of ways:
* [In a Terraform Cloud workspace](/terraform/cloud-docs/workspaces/variables).
* [In an HCP Terraform workspace](/terraform/cloud-docs/workspaces/variables).
* Individually, with the `-var` command line option.
* In variable definitions (`.tfvars`) files, either specified on the command line
or automatically loaded.
@ -385,7 +385,7 @@ Windows `cmd.exe`:
terraform apply -var-file="testing.tfvars"
```
-> **Note:** This is how Terraform Cloud passes
-> **Note:** This is how HCP Terraform passes
[workspace variables](/terraform/cloud-docs/workspaces/variables) to Terraform.
A variable definitions file uses the same basic syntax as Terraform language
@ -522,7 +522,7 @@ precedence over earlier ones:
* Any `*.auto.tfvars` or `*.auto.tfvars.json` files, processed in lexical order
of their filenames.
* Any `-var` and `-var-file` options on the command line, in the order they
are provided. (This includes variables set by a Terraform Cloud
are provided. (This includes variables set by an HCP Terraform
workspace.)
~> **Important:** In Terraform 0.12 and later, variables with map and object