Dotvault vs direnv

direnv is one of those quietly-essential developer tools — you cd into a project directory and direnv automatically loads the right environment variables into your shell; you cd out again and they unload. Dotvault is a macOS desktop app for editing the .env files that often feed into setups like that. They solve completely different problems and work together without any friction at all. If you already use direnv, nothing about Dotvault gets in its way.

Quick comparison

Feature	Dotvault	direnv
What it is	macOS desktop app for editing .env files	Shell extension that loads env vars on cd
When it runs	When you open it to edit a file	Automatically, every time you enter a directory
Primary job	Managing .env files (edit, diff, snapshot)	Getting per-directory env vars into your shell
Interface	GUI	Shell integration, .envrc file
Platform	macOS	macOS, Linux, BSD, WSL
Pricing	£29 one-time	Free, open source
Best for	Editing the file sensibly	Loading env vars into an interactive shell

Shell loader versus visual editor

direnv’s job is getting environment variables into your active shell automatically based on where you are in the filesystem. You write an .envrc in a project directory, direnv allow it once, and from then on every time you cd into that directory (or any subdirectory), the values from .envrc are loaded. Leave the directory and they unload. You can use dotenv inside .envrc to load a plain .env file, so direnv composes cleanly with projects that already use the dotenv format.

Dotvault’s job is the file itself. Not the shell integration, not the loading mechanism — the bit where you actually open .env and change something. Snapshots so you can see previous versions of the file. Side-by-side diffs. Inline annotations. Framework awareness. Encryption at rest. It runs as a desktop app, not a shell extension.

Nothing about these two is in conflict. direnv doesn’t care which editor put the text there; Dotvault doesn’t care what runs after the file is saved.

What each one does

direnv’s contribution shows up in your terminal. When it’s set up, you stop needing to source ~/.env_whatever by hand before running your app, and you stop accidentally running your staging commands with your development environment loaded. Per-directory, deterministic, invisible once it’s working. It’s the sort of tool where you forget it’s there until you switch to a machine without it and immediately miss it.

Dotvault’s contribution shows up when the file itself needs attention. You’re adding a new variable. You want to compare what the local file looks like against what the example file in the repo expects. You broke something and need to get back to the state from ten minutes ago. You want to know, three weeks later, what FEATURE_FLAG_EXPERIMENT_X actually was for. None of those are things a shell extension should be expected to help with, and Dotvault is built specifically for them.

Using both together

The normal case. A project has a .env file (or a couple of them) that feed into direnv via .envrc. A developer uses direnv to avoid manually exporting variables every time they move between projects. When the .env file itself needs editing, they open it in Dotvault — make the change, save, and direnv picks up the new values on the next cd.

There’s no configuration needed to make this work. Dotvault reads and writes standard .env files in the format direnv’s dotenv loader already understands. Comments, blank lines, quoted values, multi-line values — all preserved. Direnv doesn’t care what wrote the file, just that the file exists and parses.

If anything, Dotvault makes direnv-heavy workflows smoother, because it gives you a better picture of what any given .env actually contains before direnv loads it into your shell. Fewer surprises that way.

Who should use which

Use direnv if you want per-directory environment variables loaded automatically into your interactive shell. It’s free, it’s been around forever, it’s rock-solid, and if you haven’t set it up yet, it’s worth the twenty minutes.

Use Dotvault if you want a better way to read and edit the .env files themselves — specifically on a Mac — with snapshots, diffs, framework awareness, and encryption at rest. £29 once, no subscription, no account.

Plenty of developers use both. direnv handles the shell side; Dotvault handles the file side. Neither tool has an opinion about the other, and neither gets in the other’s way. If you’re already a direnv user, adopting Dotvault is as simple as opening the files direnv already knows about.