What causes "'env_var': environment variable '{var}' not found" in dbt-labs/dbt-core?

Export the variable before invoking dbt: `export MY_VAR=value` (or set it in CI/job environment config).

dbt-labs/dbt-core · error · minijinja::Error (InvalidOperation)

'env_var': environment variable '{var}' not found

Error message

'env_var': environment variable '{var}' not found

What it means

The `env_var` Jinja function throws this when the requested environment variable is not set in the process environment and no `default` kwarg was supplied. The match on `(std::env::var(var), default)` falls into the catch-all arm when the lookup fails and `default` is `None`, producing this error.

Source

Thrown at crates/dbt-jinja-vars/src/env_var.rs:94

            if is_secret {
                debug_assert!(placeholder_on_secret_access);
                let value = Value::from(SECRET_PLACEHOLDER.replace("{}", var));
                Ok(value)
            } else {
                if let Some(tracker) = tracker {
                    tracker(var, &value);
                }
                Ok(Value::from(value))
            }
        }
        (Err(_), Some(default)) => {
            if let Some(tracker) = tracker {
                tracker(var, DEFAULT_ENV_PLACEHOLDER);
            }
            Ok(default.clone())
        }
        _ => {
            let err = Error::new(
                ErrorKind::InvalidOperation,
                format!("'env_var': environment variable '{var}' not found"),
            );
            Err(err)
        }
    }
}

View on GitHub (pinned to 0267ce9170)

Solutions

Export the variable before invoking dbt: `export MY_VAR=value` (or set it in CI/job environment config).
Provide a fallback: `{{ env_var('MY_VAR', default='localhost') }}`.
Verify the exact variable name/spelling — env var lookups are case-sensitive.
If the value must come from a test/programmatic runner, supply it via the `overrides_fn` override mechanism.

Example fix

// before (Jinja)
{{ env_var('DB_HOST') }}
// after
{{ env_var('DB_HOST', default='localhost') }}

Defensive patterns

Strategy: fallback

Try / catch

// Prefer defaults over hard failure in templates
{{ env_var('MY_VAR', default='') }}  // then handle empty value explicitly

Prevention

Always pass default= for env vars that are optional per environment
Document required env vars and validate them at job start (e.g. `: ${DB_HOST:?DB_HOST not set}`)
Set env vars before launching dbt, not in later shell steps

When it happens

Trigger: `{{ env_var('MY_VAR') }}` where `MY_VAR` is not exported in the environment that launched dbt and no `default=` argument is given. Note the earlier secret/internal checks must already have passed (name not starting with `DBT_ENV_SECRET` or `_DBT`).

Common situations: Running `dbt run` locally without the env vars a CI pipeline sets (e.g. `env_var('DBT_WAREHOUSE_HOST')`); profiles.yml referencing vars set only in another shell; shell typos in `export` statements; vars defined after launching dbt rather than before.

Understand the failure class

Background: "environment variable is not set" and "Missing keys in environment" errors: what missing required env var messages mean and how to fix them — this error's family across 28 libraries.

Related errors

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/64ffed950b502adb. Report an issue: GitHub.