Variables and Secrets

Terraform Variables & Environment Variables

Using an infrastructure-as-code model, variables are used to customize certain aspects of a configuration for a specific deployment, without having to change the code. In this way, a single configuration can be used in different contexts to create different deployments.

Variables can be anything from ports and IPs to cloud credentials, availability zones, and images.

env0 supports two types of variables:

  • Terraform Variables (Also called Input Variables) - These are defined in the Terraform configuration files. Their values are set by env0 when running Terraform.
  • Environment Variables - These are set by env0 in the shell running Terraform and custom flows.

Terraform Variables and Environment Variables are both managed by the user in env0.

Variables and Scopes in env0

env0 uses hierarchical scopes to manage variables (both Terraform Variables and Environment Variables). You can set variables for an Organization, a Template, a Project, or a specific Environment.

Each scope inherits the variables defined in the higher scopes. Hence, a template will have all the variables that are set for the organization. A project will have all the variables that are set for the template (and organization). And a new environment will have all the variables that are set for the project, template, and organization.

You can change the value of a variable inherited from a higher scope, but not its name.

The different variable scopes reflect the fact that variables are used for different purposes and might be set by different people.



  • An administrator sets cloud credentials in the Organization scope to apply to all the environments managed in an organization.

  • A DevOps engineer creates a new template. They want to have the option for the user to select from two different machine sizes. Therefore they use the same Terraform configuration, with the instance type set as a variable, and create two templates, each with a different value for the instance size variable.

  • A developer creates a new environment. They don't need to know the credentials, or set the instances sizes. They choose a template and let env0 use the variables defined in the higher scopes. They can, however, still make further customizations by overriding a Terraform Variable which specifies which port to use.

Variables Value Types

The env0 platform supports several value types of variables:

Free Text

This is the most-common variable value type that holds a plain text value. To accommodate your variable with a value, simply type your desired text or leave it blank. This value type also supports setting it as secrets.

Dropdown List

This is a variable value that is configured with a predefined set of options that you can select as a value. This allows you to govern your specific variable with a dropdown of available options that any other organization or user can select from. Dropdown List variables can be re-selected in lower scopes but can be configured (aka add/remove options) only in their original scope.

To add/remove options of a Dropdown List variable:

  1. Add a new Dropdown List variable.
  2. Click on its value input and a new select dropdown will be opened.
  3. To add an option, type the desired option and click + Add Option button on the opened select's footer.
  4. To remove an existing option, hit the Trash icon next to the relevant option.
  5. Don't forget to hit the save button to commit your changes.

HCL Terraform Variables

Variables defined in the "Terraform Variables" section currently only support "string" type variables.
If you'd like to use terraform variables that are not of "string" type, (for example: HCL map or list), you'd need to define these in the "Environment Variables" section with a TF_VAR_ prefix for the variable name. See Terraform TF_VAR docs for more info.

So in order to define the terraform variable api_keys to be an HCL map type, we can define an Environment Variable with the name TF_VAR_api_keys, and the value of { key1 = "value1", key2 = "value2" }


For security reasons, some variables needed for flow execution should not be exposed to users executing flows. This is Secrets Management. The most common use case for secrets management is cloud credentials.

In env0, secrets are variables that are marked as sensitive. A sensitive variable has its value masked after you save it. If you'd like to change an existing sensitive variable, simply click on the masked value to clear it, type in the new secret value, and then save.

Like other variables, secrets are inherited and can be defined in any scope.


Secrets in a Self-Hosted Agent

If your organization is managed in a Self-Hosted Agent, then you would not be allowed to create secrets via the "Sensitive" checkbox.

  • Instead, you can simply have a variable point to an existing SSM variable located under the us-east-1 region, using the format of: ${ssm:<secret-id>}

For kubernetes Self-Hosted Agent, you can have a variable point to an existing AWS, GCP or Azure secret manager variable. Read more here

Manage Variables

To manage variables at the organization scope, select the Variables tab on the main screen. This shows a list of the organization's Environment Variables and Terraform Variables. You can edit their names or values, and add new ones.

Don't forget to save any changes before you leave the page, or your changes will be lost.

To manage variables at the Template level, go to the Template tab and select the template you are interested in. Click Settings, and then select the Variable tab. Here you can modify variables for the template.

At the environment level, you can set the variables just before deployment. When you create a new environment or redeploy, a pop up is opened, with environment details to fill in. Select the Variable section, and modify the variables for this specific environment.

For an environment that already exists, you can go into the Environment Details screen and edit the variables settings under Variables tab.



  • Changes to variables in a higher scope will change the variables in all inheriting scopes.
  • Changes to variables for an existing environment will not take effect until the environment is redeployed. When env0 runs a deployment, it stores the variable names to be used in undeploy so changes for an Active environment will not affect the undeploy process.

What’s Next

env0 also has special categories of secrets that it needs for actually running, including

Did this page help you?