tfvars & Shell Variables

Terraform Variables

Scalr uses Terraform input variables the same exact way they are used in Terraform OSS, no extra configuration is needed other than having the option to create them directly in the Scalr UI. When Terraform variables are set directly in Scalr, Scalr will pass those variables to Terraform as a terraform.tfvars.json file.

Terraform variables can be marked as sensitive or HCL values as needed:

Alternatively, variable files can be passed in as part of the workspace configuration. Values defined in the .tfvars files have a higher priority than ones set in the Scalr UI/backend. To enforce values from the Scalr UI/backend users must specify the variable as final in the Scalr Terraform variables section of the workspace.

📘

terraform.tfvars.json name is reserved

terraform.tfvars.json and terraform.tfvars are reserved filenames and cannot be used as Scalr uses that to pass in variables.

Shell Variables

In addition to Terraform input variables, there are use cases for declaring shell variables in the run time environment. Shell variables can be declared in Scalr and are exported into the Terraform runtime environment using export var=value.

Scalr uses this technique to automatically publish provider credentials to workspaces for the major cloud platforms (See Provider Credentials for more details). But, there are other use cases where the shell variables can be useful as well:

• Provide credentials to providers that are not supported by Scalr Provider Credentials (see individual provider docs).
• Pass in non-credentials configuration values to providers, such as location (see individual provider docs).
• Set values for Terraform input variables with TF_VAR_{variable_name}={value}.
• Pass in data to be used in scripts executed by provisioners or data "external" {}.
• Set custom parallelism with TF_CLI_ARGS_plan="-parallelism=N" and TF_CLI_ARGS_apply="-parallelism=N" (where N is the desired parallelism value).
• Set the log level with TF_LOG=TRACE
• Set Terraform debug/behavioral variables.

Built-In Variables

The following shell variables are built into the runtime environment for use as needed:

• SCALR_RUN_ID - The ID of the current run.
• SCALR_HOSTNAME - The Scalr hostname.
• SCALR_TERRAFORM_OPERATION - The current Terraform operation (plan or apply).
• SCALR_TERRAFORM_EXIT_CODE - The exit code (0 or 1) of the previous operation (plan or apply) and only available in after hooks.
• SCALR_RUN_IS_DESTROY - If the code is 1, then the run is the equivalent to a terraform destroy. If it is 0, then it is a terraform apply. This is helpful for custom hooks that will execute if the apply is a destroy or not.
• SCALR_RUN_VCS_BRANCH - The branch name of the VCS repo i.e. main
• SCALR_RUN_VCS_COMMIT- The commit hash for a VCS triggered run i.e. e59f09e
• SCALR_RUN_MODE - This will return the type of run that was executed. Possible values are:
  • apply - Plan & Apply
  • dry - Plan only
  • refresh - Refresh only
  • skip_refresh - Skip refresh
• SCALR_RUN_SOURCE - The source that triggered the run. Possible values are:
  • vcs - The run was triggered by a VCS provider.
  • cli - The run was triggered from the Terraform or OpenTofu CLI.
  • scalr-cli- The run was triggered from the Scalr CLI
  • run-trigger - The run was triggered from the run triggers feature.
  • schedule - The run was triggered based on a schedule being set in the workspace.
  • api- The run was triggered from the Scalr API.
  • configuration version - When the run is triggered based on auto-queue runs being enabled in the workspace and the first CV uploaded triggers a run.
  • ui - for all runs triggered from the UI.

Setting Shell Variables

Scalr provides multi-scope shell variables that can be set at any scope and inherited at lower scopes. Variables set at higher scopes can, depending on the configuration of the variable, have their value overridden at lower scopes. The hierarchy is as follows.

• Account
• Environment -> Inherits from Account
• Workspace -> Inherits from Account and Environment

Shell variables marked as “final” at any scope cannot be overridden by lower scopes. They can also be marked as “sensitive” to ensure the value is masked out in the Scalr UI, API, provider results, and Terraform plan and state output.

Shell variables are set in the “Variables” section at each scope.

Example: Account scope

Account scope variables are created at the account scope and automatically shared with all environments and workspaces.

Click on the variable to access the configuration details. Make sure to “Save” after any changes to variables.

Example: Environment scope

Environment scope variables are created and assigned within the environments tab at the account scope. Once they are created and assigned to the environment, all workspaces in the environment will inherit the variable:

Note that some provider credential variables are shown. These have been inherited from cloud credentials set at account scope, hence the green icon.

Variables can be overridden by creating a new variable of the same name at a lower scope. An overridden variable is shown as a group with the lowest scope, and therefore applicable value is visible. The variable can be ungrouped using the button on the right so that the variable can be edited or deleted.

Example: Workspace scope

Workspace scope variables are assigned within the variables tab at the workspace scope.