Problem
Engineering teams often store shared API keys, staging credentials, and service tokens in secret managers (such as 1Password, Bitwarden, HashiCorp Vault, or Doppler), requiring developers to manually copy-paste values into .env files.
Proposed Solution
Support secret reference URIs in template comments (e.g. # @source op://Vault/Item/Field or # @source vault://path#key) and a command/flag to resolve and pull secrets directly into the target .env.
Expected Behavior
- Template annotations can specify a secret path:
# @source op://Development/Stripe/api_key.
- When executing with vault integration enabled,
exenv invokes or interfaces with the respective CLI/API to fetch the value and pre-fill the variable.
- If the user is unauthenticated or the secret is unreachable, falls back gracefully to interactive prompt.
Acceptance Criteria
- Supported providers include at least 1Password CLI (
op), Bitwarden CLI (bw), and HashiCorp Vault.
- Secrets are fetched securely in memory without persisting credentials to temporary disk files.
- Clear error messaging when authentication to the vault provider fails.
Problem
Engineering teams often store shared API keys, staging credentials, and service tokens in secret managers (such as 1Password, Bitwarden, HashiCorp Vault, or Doppler), requiring developers to manually copy-paste values into
.envfiles.Proposed Solution
Support secret reference URIs in template comments (e.g.
# @source op://Vault/Item/Fieldor# @source vault://path#key) and a command/flag to resolve and pull secrets directly into the target.env.Expected Behavior
# @source op://Development/Stripe/api_key.exenvinvokes or interfaces with the respective CLI/API to fetch the value and pre-fill the variable.Acceptance Criteria
op), Bitwarden CLI (bw), and HashiCorp Vault.