Environment variables are how projects get their configuration, and managing them by hand is a mess: you export things in your shell, forget to unset them, and leak one project's settings into another. direnv automates it. You put an .envrc file in a project directory, and direnv loads those variables when you cd in and unloads them when you leave - so each project's environment appears and disappears automatically as you move around.
The Environment Follows the Directory
Drop the variables (or logic) in .envrc, approve it once for safety, and it just works:
# .envrc in a project root
export APP_ENV=local
export DATABASE_URL=mysql://localhost/mydb
# Approve it (required once, for security)
direnv allow
More Than Variables
Because .envrc is shell, it can do more than set variables - add a project's bin directory to your PATH, activate a language environment, or source secrets from a manager. And direnv's explicit allow step means an untrusted .envrc can't run without your say-so.
Rough Edges and Limitations
- Security needs attention. The allow model is there because an
.envrcruns shell - review before allowing. - Secrets need care. Don't commit a secret-bearing
.envrc; reference a manager instead. - Shell hook required. A one-time init line in your shell config.
Once direnv is set up, per-project environments stop being something you manage and become something that just happens.
Internal link suggestion: link "source secrets from a manager" to the sops post for encrypted secret handling.