Terraform tfvars to Env Vars Converter

Convert .tfvars assignments into TF_VAR_ exports for a shell or a pipeline. Two things catch people: complex values must be JSON, and these are the lowest-precedence source there is.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Convert. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A map value

The export has to hold JSON, because Terraform only parses primitives from an environment variable

region = "eu-west-1"
tags = {
  env = "prod"
}

A reference in a tfvars file

There is no expression language while a tfvars file is read, so this cannot work at all

region = var.region

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Exporting TF_VAR_ and finding it ignored

    Environment variables are the lowest-precedence source. A terraform.tfvars or an *.auto.tfvars in the working directory silently wins.

    Instead:Check the directory for a tfvars file setting the same name. Use -var on the command line if you need to override everything.

  2. Writing HCL syntax into an environment variable

    A list or a map in an environment variable must be JSON. TF_VAR_tags='{env="prod"}' fails as a type mismatch, which points at the declaration rather than the value.

    Instead:Use JSON: TF_VAR_tags='{"env":"prod"}'.

  3. Uppercasing the variable name

    TF_VAR_REGION does not set var.region. On Windows the shell hides the difference, so the same script behaves differently across platforms.

    Instead:Keep everything after TF_VAR_ identical to the variable name, character for character.

Environment variables lose to every tfvars file in the directory

The precedence order explains the commonest complaint about TF_VAR_, which is that setting it appears to do nothing at all.

The order, lowest to highest

Environment variables, then terraform.tfvars, then terraform.tfvars.json, then every *.auto.tfvars in alphabetical order, then -var-file and -var on the command line, with later winning. So exporting TF_VAR_region while a terraform.tfvars in the working directory also sets region has no effect, and nothing warns you.

Lists and maps must be JSON, not HCL

Terraform parses a primitive from an environment variable directly. A collection has to be valid JSON, so TF_VAR_tags='{"env":"prod"}' works and the HCL form with = between key and value does not. The error is a type mismatch rather than a syntax complaint, which sends people looking at the variable declaration.

The name after the prefix is case-sensitive

TF_VAR_REGION does not set var.region. This bites hardest on Windows, where the shell treats environment variable names as case-insensitive and Terraform does not, so a script that works in one shell fails in another with no visible difference.

An exported secret is visible more widely than a file

Every process the shell starts inherits it, it is readable from /proc for the process lifetime on Linux, and typing the export puts it in shell history. A tfvars file with restrictive permissions is often the safer option, and reading from a secret manager at the point of use is better than either.

Single quotes keep the shell out of the value

Anything with a space, a dollar sign, a backtick or a bracket needs quoting, and single quotes are the form that does not interpret. A value containing a single quote needs the '\'' dance, which the output here already does.

A tfvars file holds literals only

There is no expression language available while it is read: no variables, no locals, no functions. So a reference in a tfvars file is a parse error rather than something to convert, and the logic belongs in a local in the configuration.