»The CLI-driven Run Workflow

Hands-on: Try the Log in to Terraform Cloud from the CLI tutorial on HashiCorp Learn.

Terraform Cloud has three workflows for managing Terraform runs.

• The UI/VCS-driven run workflow, which is the primary mode of operation.
• The API-driven run workflow, which is more flexible but requires you to create some tooling.
• The CLI-driven run workflow described below, which uses Terraform's standard CLI tools to execute runs in Terraform Cloud.

»Summary

The CLI integration brings Terraform Cloud's collaboration features into the familiar Terraform CLI workflow. It offers the best of both worlds to developers who are already comfortable with using the Terraform CLI, and it can work with existing CI/CD pipelines.

You can start runs with the standard terraform plan and terraform apply commands and then watch the progress of the run from your terminal. These runs execute remotely in Terraform Cloud; they use variables from the appropriate workspace, enforce any applicable Sentinel policies, and can access Terraform Cloud's private registry and remote state inputs.

Terraform Cloud offers two kinds of CLI-driven runs, to support different stages of your workflow:

• terraform plan starts a speculative plan in a Terraform Cloud workspace, using configuration files from a local directory. You can quickly check the results of edits (including compliance with Sentinel policies) without needing to copy sensitive variables to your local machine.

  Speculative plans work with all workspaces, and can co-exist with the VCS-driven workflow.

• terraform apply starts a normal plan and apply in a Terraform Cloud workspace, using configuration files from a local directory.

  Remote terraform apply is for workspaces without a linked VCS repository. It replaces the VCS-driven workflow with a more traditional CLI workflow.

To supplement these remote operations, you can also use the optional Terraform Enterprise Provider, which interacts with the resources supported by Terraform Cloud. It can be useful for editing variables and workspace settings through the Terraform CLI.

»Configuration

To enable the CLI-driven workflow, you must:

1. Run terraform login to authenticate with Terraform Cloud. Alternatively, you can manually configure credentials in the CLI config file.

2. Add the cloud block to your Terraform configuration. The example below shows how you can map your CLI workspaces to Terraform Cloud workspaces that have a specific tag.

   terraform {
     cloud {
       organization = "my-org"
       workspaces {
         tags = ["networking"]
       }
     }
   }
   

   terraform {  cloud {    organization = "my-org"    workspaces {      tags = ["networking"]    }  }}

   Copy

   Note: The cloud block is available in Terraform v1.1 and later and Terraform Enterprise v202201 and later. Previous versions can use the remote backend to configure the CLI workflow and migrate state.

3. Run terraform init.

   $ terraform init
   
   Initializing Terraform Cloud...
   
   Initializing provider plugins...
   - Reusing previous version of hashicorp/random from the dependency lock file
   - Using previously-installed hashicorp/random v3.0.1
   
   Terraform Cloud has been successfully initialized!
   
   You may now begin working with Terraform Cloud. Try running "terraform plan"
   to see any changes that are required for your infrastructure.
   
   If you ever set or change modules or Terraform Settings,
   run "terraform init" again to reinitialize your working directory.
   

   $ terraform init
   Initializing Terraform Cloud...
   Initializing provider plugins...- Reusing previous version of hashicorp/random from the dependency lock file- Using previously-installed hashicorp/random v3.0.1
   Terraform Cloud has been successfully initialized!
   You may now begin working with Terraform Cloud. Try running "terraform plan"to see any changes that are required for your infrastructure.
   If you ever set or change modules or Terraform Settings,run "terraform init" again to reinitialize your working directory.

   Copy

Refer to Using Terraform Cloud for more details about how to initialize and configure the integration.

»Implicit Workspace Creation

If you configure the cloud block to use a workspace that doesn't yet exist in your organization, Terraform Cloud will create a new workspace with that name when you run terraform init. The output of terraform init will inform you when this happens.

Automatically created workspaces might not be immediately ready to use, so use Terraform Cloud's UI to check a workspace's settings and data before performing any runs. In particular, note that:

• No Terraform variables or environment variables are created by default, unless your organization has configured one or more global variable sets. Terraform Cloud will use *.auto.tfvars files if they are present, but you will usually still need to set some workspace-specific variables.
• The execution mode defaults to "Remote," so that runs occur within Terraform Cloud's infrastructure instead of on your workstation.
• New workspaces are not automatically connected to a VCS repository and do not have a working directory specified.
• A new workspace's Terraform version defaults to the most recent release of Terraform at the time the workspace was created.

»Variables in CLI-Driven Runs

Remote runs in Terraform Cloud use:

• Run-specific variables set via the command line or in your local environment. Terraform only uses the environment variables from your shell environment that are prefixed with TF_VAR.
• Workspace-specific Terraform and environment variables set in the workspace.
• Variable sets applied to the workspace.
• Terraform variables from any *.auto.tfvars files included in the configuration.

Refer to Variables for more details about variable types, variable scopes, variable precedence, and how to set run-specific variables through the command line.

»Remote Working Directories

If you manage your Terraform configurations in self-contained repositories, the remote working directory always has the same content as the local working directory.

If you use a combined repository and specify a working directory on workspaces, you can run Terraform from either the real working directory or from the root of the combined configuration directory. In both cases, Terraform will upload the entire combined configuration directory.

»Excluding Files from Upload

CLI-driven runs upload an archive of your configuration directory to Terraform Cloud. If the directory contains files you want to exclude from upload, you can do so by defining a .terraformignore file in your configuration directory.

»Remote Speculative Plans

You can run speculative plans in any workspace where you have permission to queue plans. (More about permissions.)

To run a speculative plan on your configuration, use the terraform plan command. The plan will run in Terraform Cloud, and the logs will stream back to the command line along with a URL to view the plan in the Terraform Cloud UI.

$ terraform plan

Running plan in Terraform Cloud. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.

Preparing the remote plan...

To view this run in a browser, visit:
https://app.terraform.io/app/hashicorp-learn/docs-workspace/runs/run-cfh2trDbvMU2Rkf1

Waiting for the plan to start...

[...]

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + pet_name = (known after apply)

$ terraform plan
Running plan in Terraform Cloud. Output will stream here. Pressing Ctrl-Cwill stop streaming the logs, but will not stop the plan running remotely.
Preparing the remote plan...
To view this run in a browser, visit:https://app.terraform.io/app/hashicorp-learn/docs-workspace/runs/run-cfh2trDbvMU2Rkf1
Waiting for the plan to start...
[...]
Plan: 1 to add, 0 to change, 0 to destroy.
Changes to Outputs:  + pet_name = (known after apply)

Speculative plans use the configuration code from the local working directory, but will use variable values from the specified workspace.

»Remote Applies

In workspaces that aren't connected to a VCS repository, users with permission to apply runs can trigger remote applies with the CLI. (More about permissions.)

When you are ready to apply configuration changes, use the terraform apply command. Terraform Cloud will plan your changes, and the command line will prompt you for approval before applying them.

$ terraform apply

Running apply in Terraform Cloud. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.

Preparing the remote apply...

To view this run in a browser, visit:
https://app.terraform.io/app/hashicorp-learn/docs-workspace/runs/run-Rcc12TkNW1PDa7GH

Waiting for the plan to start...

[...]

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + pet_name = (known after apply)

Do you want to perform these actions in workspace "docs-workspace"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

[...]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

$ terraform apply
Running apply in Terraform Cloud. Output will stream here. Pressing Ctrl-Cwill cancel the remote apply if it's still pending. If the apply started itwill stop streaming the logs, but will not stop the apply running remotely.
Preparing the remote apply...
To view this run in a browser, visit:https://app.terraform.io/app/hashicorp-learn/docs-workspace/runs/run-Rcc12TkNW1PDa7GH
Waiting for the plan to start...
[...]
Plan: 1 to add, 0 to change, 0 to destroy.
Changes to Outputs:  + pet_name = (known after apply)
Do you want to perform these actions in workspace "docs-workspace"?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.
  Enter a value: yes
[...]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Remote applies use the configuration code from the local working directory, but use the variable values from the specified workspace.

»Sentinel Policies

If the specified workspace uses Sentinel policies, those policies will run against all speculative plans and remote applies in that workspace. Policy output is shown in the terminal.

Failed policies can pause or prevent an apply, depending on the enforcement level:

• Hard mandatory checks cannot be overridden and they prevent terraform apply from applying changes.
• Soft mandatory checks can be overridden by users with permission to manage policy overrides. If your account can override a failed check, Terraform will prompt you to type "override" to confirm. (Note that typing "yes" will not work.) If you override the check, you will be prompted to apply the run (unless auto-apply is enabled).

$ terraform apply

[...]

Plan: 1 to add, 0 to change, 1 to destroy.

------------------------------------------------------------------------

Organization policy check:

Sentinel Result: false

Sentinel evaluated to false because one or more Sentinel policies evaluated
to false. This false was not due to an undefined value or runtime error.

1 policies evaluated.
## Policy 1: my-policy.sentinel (soft-mandatory)

Result: false

FALSE - my-policy.sentinel:1:1 - Rule "main"

Do you want to override the soft failed policy check?
  Only 'override' will be accepted to override.

  Enter a value: override

$ terraform apply
[...]
Plan: 1 to add, 0 to change, 1 to destroy.
------------------------------------------------------------------------
Organization policy check:
Sentinel Result: false
Sentinel evaluated to false because one or more Sentinel policies evaluatedto false. This false was not due to an undefined value or runtime error.
1 policies evaluated.## Policy 1: my-policy.sentinel (soft-mandatory)
Result: false
FALSE - my-policy.sentinel:1:1 - Rule "main"
Do you want to override the soft failed policy check?  Only 'override' will be accepted to override.
  Enter a value: override

»Options for Plans and Applies

Run Modes and Options contains more details about the various options available for plans and applies when you use the CLI-driven workflow.