Terraform Environment Variables

If you have been working with Terraform for a while, you probably already know that environment variables can make your life easier, especially when running Terraform in CI/CD pipelines. You set them on the server once, and your code stays clean. Let me walk you through the ones I actually use.

TF_INPUT

Set TF_INPUT=0 or TF_INPUT=false to disable interactive prompts. If Terraform asks for a variable value you did not define, it will error out instead of waiting for input. On CI, this is what you want - fail fast, not wait forever.

You might have used -input=false on the CLI before. TF_INPUT does the same thing.

TF_VAR_variable_name

This is the pattern: prefix any variable name with TF_VAR_ and Terraform picks it up automatically.

Say your configuration has:

variable “DB_HOST” {
  type        = string
  description = “Database host”
}

You can set it like this:

export TF_VAR_DB_HOST=”db.example.com”

Then terraform plan or terraform apply will use that value. No extra flags needed.

On GitLab CI, I configure these directly in the Runner settings. Each runner can have different values - prod runners get prod credentials, dev runners get dev ones. No secrets in your repo.

TF_CLI_ARGS

Want to append the same argument to every Terraform command? TF_CLI_ARGS does that.

TF_CLI_ARGS=”-input=false” terraform apply -force

The value of TF_CLI_ARGS gets inserted after the subcommand. That line above is equivalent to:

terraform apply -input=false -force

I use this when I want a consistent set of flags across all commands in a pipeline - things like -input=false or -no-color for CI logs.

There is also a per-subcommand variant: TF_CLI_ARGS_plan, TF_CLI_ARGS_apply, etc. So you can do:

export TF_CLI_ARGS_plan=”-refresh=false”

That appends -refresh=false only to terraform plan commands, leaving other subcommands untouched.

TF_DATA_DIR

By default, Terraform stores its working files (including the .terraform directory and lock file) in the current directory. I ran into a problem once where a server had a read-only filesystem for the directory where the code lived. Terraform could not write its working files there.

TF_DATA_DIR solves this. Point it somewhere writable:

export TF_DATA_DIR=/tmp/terraform-data

Terraform will store its .terraform directory and state lock files there instead of the project directory. Useful when your deployment environment has unusual filesystem restrictions.

TF_WORKSPACE

If you use Terraform workspaces, TF_WORKSPACE sets the active workspace:

export TF_WORKSPACE=dev

Terraform will use that workspace automatically. You do not have to run terraform workspace select each time.

Terraform’s own docs warn about this one: it is easy to forget the variable is set in your shell and accidentally apply changes to the wrong environment. I have done it. Now I always unset TF_WORKSPACE when switching projects.

That is it

There are more environment variables, but these five cover most of what I see in practice. They are not glamorous, but they handle the kind of repetitive configuration work that would otherwise end up baked into scripts or wrapper functions.

Give them a try next time you are setting up a pipeline.