Dotvault vs dotenvx

dotenvx and Dotvault both work with .env files, which is about where the similarities end. One is a CLI for encrypting your .env so you can safely commit it to git. The other — Dotvault, which I built — is a macOS desktop app for editing those same files day-to-day. They’re not really competing, and most developers who already use one will find room for the other.

Quick comparison

Feature	Dotvault	dotenvx
What it is	macOS desktop app for editing .env files	CLI for encrypting and decrypting .env files
Pricing	One-time purchase, 14-day free trial, twelve months of updates included	CLI free and open source; paid Dotenvx Armor tiers
Interface	Graphical editor	Command line
Primary job	Day-to-day editing, diffing, snapshots	Encrypt for git commit, decrypt at runtime
Where secrets live	On your Mac as plain text, never synced; snapshots encrypted	Encrypted inside your git repo
Team workflow	Single developer, local-only	Share keys across machines and CI
Open source	Closed-source commercial	Yes, BSD-3-Clause

Different tools for different jobs

dotenvx comes from the same family as the original dotenv library, and its whole reason for being is a genuinely clever answer to an old problem: people commit plain-text .env files to git all the time, which is a terrible idea. dotenvx solves that by encrypting the file with a key you keep out of the repo. The encrypted version can sit in git harmlessly, and your deploy pipeline decrypts it at runtime on whichever machine needs it.

Dotvault doesn’t do that. Dotvault runs on your Mac, it doesn’t touch your git history, and it doesn’t know or care where your .env lives once you’ve finished editing it. What it does is sit between you and the file, so you’re not fumbling around in a terminal or a text editor every time you want to change an API key or flip a feature flag.

The two tools solve problems that aren’t in each other’s way. dotenvx asks “how do I safely deploy my secrets?” Dotvault asks “how do I stop dropping bits of my .env on the floor while I’m editing it?”

Where each one fits in your workflow

Think of a normal day. You’re building a feature. You need to add a new third-party API key to .env.local. You want to check what the staging version of that key looks like. You realise you broke the local database URL three hours ago and need to get back to the working version. And before you push, you want to make sure the production config you’ve been tweaking still looks sensible.

That’s where Dotvault lives. It’s the tool for the “I’m editing” part of the loop. Snapshots so you can see and restore previous versions of the file. Side-by-side diffs. Inline annotations so you remember what a variable is for. Framework awareness so it knows the difference between a Laravel .env and a Next.js one. An encrypted snapshot history, so the trail of every change you’ve made isn’t sat on disk in the clear. The .env file itself stays plain text, because your framework has to read it, so if your Mac walks out of the coffee shop it’s FileVault protecting that file, not me.

dotenvx lives in the “I’m shipping” part of the loop. You’ve got the file right, you need it in CI and on the production box, and you don’t want to paste secrets into a deploy platform’s UI or store them in plain text anywhere. You encrypt the file once, commit the encrypted version, and let dotenvx handle decrypting at runtime on every machine that needs it.

Neither of those jobs is the other’s job.

Privacy and control

Both tools put you in control of your secrets in a way cloud platforms deliberately don’t. Neither sends your .env to an account-based service, neither charges you per secret, and neither puts a vendor between you and the thing you’re trying to do.

There is a paid side to dotenvx now, mind: Dotenvx Armor is a subscription that adds audit logging, key rotation and access control on top. The CLI itself stays free and BSD-licensed, so nothing above changes, but it’s worth knowing the free tool has a commercial product sat next to it.

dotenvx gets there by making the encrypted file portable — it’s just text, safely committed to your own repo, decrypted only by something that has the key. Dotvault gets there by being a local app that literally never phones home with the contents of your files. The encrypted snapshot data sits on your Mac, and the key that unlocks it is itself encrypted, with the macOS Keychain holding the master key that protects it. No cloud sync, no account, no option to accidentally leak a file to someone else’s server.

If you’ve ever pushed a plain-text .env into git in a rush and then had to rewrite history to undo it, dotenvx is what fixes that category of mistake for good. If you’ve ever lost half a morning trying to remember which value of DATABASE_URL was working yesterday, Dotvault is what fixes that one.

Who should use which

I’d reach for dotenvx any time I needed to get secrets onto other machines — deploy targets, CI runners, teammates — without committing them in plain text. I’d reach for Dotvault — and I do, every day — when I want a faster, less error-prone way to read and edit those files on my own Mac.

Plenty of developers will end up using both. dotenvx takes care of deployment. Dotvault takes care of the editing loop that feeds into deployment. If you’re already a dotenvx user, Dotvault doesn’t replace anything — it just removes a different kind of friction you might not have realised you were putting up with.

And if you’re neither? The trial is 14 days with no account, which is a reasonable amount of time to find out whether you’ve been quietly living with a bad .env workflow.