linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Lessons
  • How it works
  • Knowledge base
  • Cheat sheet
  • Capstone
  • Interview prep
home/terraform/kb/Terraform basics/tf-cli-config

kb/core ── Terraform basics ── beginner

Terraform CLI configuration: terraformrc, env vars, TF_LOG

You configure the Terraform CLI through the ~/.terraformrc file and the TF_* environment variables. This is where the plugin cache lives, along with TF_LOG for debugging, TF_VAR_* for variables, and TF_CLI_ARGS for global flags.

view as markdownaka: terraformrc, tf-env-vars

Where Terraform reads its settings

The CLI is configured in two places:

  1. The ~/.terraformrc file (Linux/macOS) or %APPDATA%\terraform.rc (Windows). HCL format. Read once when any command starts.
  2. The TF_* environment variables. Read on every terraform run. Where values overlap, they take priority over terraformrc.

These files are about the CLI, not about project configuration. They hold no resources and no state. They describe how you prefer to work with terraform, not what terraform creates.

~/.terraformrc and what usually goes in it

hcl
plugin_cache_dir   = "$HOME/.terraform.d/plugin-cache"
disable_checkpoint = true
credentials "app.terraform.io" {
  token = "..."
}
  • plugin_cache_dir is a shared folder for downloaded plugins across all your projects. Without it, every terraform init downloads the providers again into the local .terraform/, and you end up with duplicated gigabytes. With the cache, init for a new project takes seconds.
  • disable_checkpoint = true turns off the background check for "is there a newer version of Terraform". It is not critical, but on offline networks it removes the noise.
  • credentials is a token for private registries (Terraform Cloud, Spacelift). You usually do not need it in a learning course.

You have to create the folder for plugin_cache_dir yourself: mkdir -p ~/.terraform.d/plugin-cache.

Environment variables

Controlling output and behavior

  • TF_LOG is the log level. Values: TRACE, DEBUG, INFO, WARN, ERROR. At DEBUG you see every HTTP call to the provider. This is your main debugging tool when apply fails with an error you cannot make sense of:
    bash
    TF_LOG=DEBUG terraform apply 2> debug.log
  • TF_LOG_PATH is where to write the log. If it is not set, the log goes to stderr.
  • TF_INPUT=0 turns off the interactive prompts (for CI).
  • TF_IN_AUTOMATION=true tells terraform it is running in a pipeline. It trims the output and drops the hints about next steps.

Passing variables into HCL

  • TF_VAR_name sets the value of the variable "name" from HCL. For example:
    bash
    export TF_VAR_bucket_name="my-bucket-from-env"
    terraform plan
  • TF_CLI_ARGS adds flags to any command. For example, to always pass -input=false on every run without writing it out in each call:
    bash
    export TF_CLI_ARGS="-input=false"
  • TF_CLI_ARGS_plan, TF_CLI_ARGS_apply, and so on. The same thing, but only for a specific command.

Controlling the cache and backend

  • TF_DATA_DIR is where terraform creates .terraform/. By default it sits next to the .tf files; you can move it to /tmp/ if the project is on a read-only filesystem.
  • TF_CLI_CONFIG_FILE is the path to an alternative terraformrc file. This helps when CI needs one configuration file and your local machine needs another.

How to use TF_LOG

The most common case: terraform apply fails with "Error: failed to get versions..." and no detail. You run the same thing with DEBUG:

bash
TF_LOG=DEBUG TF_LOG_PATH=./tf.log terraform apply

tf.log will hold the full HTTP exchange: which URL it went to, what response it got, and where the provider broke. You can often see that it hit a proxy, hit DNS, or got a 429 from the registry.

Levels:

LevelWhen to use it
ERRORErrors only. The default with no flag.
WARNPlus warnings (deprecated, retries).
INFOPlus the basic steps (init, plan, apply phases).
DEBUGPlus HTTP calls. The most useful level for everyday debugging.
TRACEPlus the internals (graph expansion, parsing). Verbose, rarely needed.

Pitfalls

  • TF_VAR_name is case sensitive. TF_VAR_Region feeds the variable Region, not region. It is best to keep your variable names lowercase.
  • TF_CLI_ARGS is concatenated with the real flags. If the env has TF_CLI_ARGS="-no-color" and you run terraform plan -no-color, the provider sees two -no-color flags. That is usually harmless, but when a meaningful flag is duplicated the behavior is unpredictable.
  • plugin_cache_dir does not lock versions. The cache only saves you the download. Versions are still pinned by the [[tf-lockfile|lockfile]].
  • TF_LOG can print secrets. A DEBUG log shows the headers and bodies of HTTP requests. Do not post a raw log in an issue: filter out Authorization, *_token, and *_key.
  • ~/.terraformrc and the project provider configuration are different things. terraformrc has no regions and does not name resources; the region goes in the [[tf-provider-block|provider block]].

§ команды

bash
TF_LOG=DEBUG terraform apply 2> tf-debug.log

Run apply with a detailed log written to a file. The most common debugging move.

bash
export TF_VAR_region=eu-central-1 && terraform plan

Pass a variable through the env. Handy for CI and one-off runs, without cluttering the command with -var flags.

bash
mkdir -p ~/.terraform.d/plugin-cache

Create the folder for the shared plugin cache before you set `plugin_cache_dir` in terraformrc.

bash
terraform -version

Shows the terraform version and the list of current providers. The first thing people ask for in any issue.

§ см. также

  • tf-initterraform init: the first command in any projectterraform init downloads the provider plugins (AWS, GCP, and so on), creates a lockfile that pins their versions, and prepares the working directory. Without it, neither plan nor apply will run.
  • tf-lockfile.terraform.lock.hcl: pinning provider versionsThe lockfile pins the exact provider versions and their hashes, so you and CI always run the same build. It is created on terraform init and updated through init -upgrade. Commit it to git.
  • tf-init-backendsBackends in Terraform: where state livesA backend is where the state file is stored. The default is local, next to your HCL. Remote backends (S3, GCS, Terraform Cloud, http) give you shared access and locking. This course uses only local; remote is covered as an overview.
  • tf-version-constraintsVersion constraints in Terraform: required_version and providersrequired_version pins which versions of terraform may run this code. required_providers.version does the same for providers. The pessimistic operator ~> 5.60 is the standard: it allows minor updates and blocks major ones.
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies