Why I built Dotvault

Every developer I know has a .env problem. You’ve got the same six environment variables smeared across four files in three different projects, half of them out of date, none of them in git, and the one that matters is sitting in a Slack DM from eight months ago.

Nobody talks about it because there’s no fun in it. Secrets management is the chore you keep meaning to get around to. And the tools that do exist mostly want you to rebuild your entire workflow around them — sign up for a service, pipe everything through a CLI, trust a third party with your credentials, pay per seat, lock yourself in. Fine if you’re a team of fifty. Not fine if you’re one person with twelve side projects and a laptop.

So I looked around

I tried the obvious options. Cloud secret managers are great if you want a secret manager and you’re willing to live in their world. I didn’t. The whole point of a .env file — the thing that has kept them alive for twenty years — is that they’re local, boring, and portable. The moment you put your secrets behind someone else’s API, you’ve traded one problem (messy files) for a different one (vendor lock-in, latency, compliance paperwork, a recurring bill).

CLI tools are better but they’re still CLIs. I like terminals as much as the next person, but when I’m trying to figure out why a value in staging doesn’t match dev, I don’t want to write a diff pipeline — I want to see the two files side by side and have the differences shouted at me in colour.

And then there’s the “just use a text editor” camp, which is what most of us actually do. It works until it doesn’t. Until you paste a value into the wrong file. Until you rm -rf a project folder with the only copy of a key. Until you spend twenty minutes trying to work out which environment has the Stripe key that actually charges money.

The thing I actually wanted

I wanted a proper visual editor for .env files. Something that treats them as first-class — with history, with diffs, with the ability to see six files at once and click through them. Something that doesn’t send anything anywhere. Something that runs on my laptop, does its job, and gets out of the way.

So that’s what Dotvault is. A macOS app. No accounts, no CLIs, no cloud, no pricing calculator. You open your project folder, it finds your env files, and you can finally see what’s going on.

Under the hood it’s got snapshots, so every time you change a file you get a little undo-point — browse the history, restore anything, diff between snapshots. It’s got proper multi-environment views so you can compare .env.local against .env.staging against .env.production and instantly see which keys are missing from which. It syncs missing keys across files in one click. It plays nicely with git.

Two things I actually use it for

I’ll give you the two concrete examples of why I built this, because honestly they’re the moments that made me stop putting off the project and start writing code.

Laravel encrypted env files. One of my apps runs on Laravel Vapor, which means the production env file is encrypted on disk. Every time I needed to change something, the loop was: php artisan env:decrypt, open the file in an editor, make the change, php artisan env:encrypt, delete the plaintext, commit, pray. Do that twenty times and you start looking for shortcuts — and shortcuts with encrypted secrets are exactly how you end up committing a plaintext .env to git. Dotvault handles Laravel’s encrypted env files natively. I unlock it once per project, edit like any other file, and it stays encrypted on disk the whole time. No decrypt/reencrypt cycle, no temporary plaintext file sitting around waiting to be committed by mistake.

Snapshots as a safety net for migrations. Right now I’m migrating a project from MySQL to Postgres. That means repeatedly swapping out half a dozen env vars — database driver, host, port, credentials, connection options — and then swapping them back when something breaks and I need to run the old version again. Before Dotvault I’d have a scratch file somewhere with the “old” values pasted in, and I’d copy-paste them back and forth like an animal. Now I take a snapshot before each swap, disable the keys I want inactive rather than deleting them, and when I inevitably need to roll back I restore the snapshot in one click. It’s turned a stressful fiddly operation into a boring one, which is exactly what you want from tooling.

These are the sort of problems that don’t show up in feature comparisons or screenshots. They show up on a random Tuesday when you’re knee-deep in something else and you just want the tool to get out of your way.

Local-first, on purpose

The bit I care about most is that none of your data ever leaves your machine. Everything the app stores is encrypted at rest using your OS keychain. There’s an opt-in anonymous telemetry toggle that tells me if people are actually using the thing, but it’s off by default and it literally can’t see your variable names or values even if I wanted it to. I built it that way on purpose.

I’m one developer. This is the tool I wanted for myself, shipped properly so other people can use it too. It’s not a platform, it’s not a service, it’s not trying to become the next unicorn. It’s an app. You buy it once, it runs on your Mac, and it does a job.

Where it’s up to

Dotvault is out now. If you’ve read this far and any of it sounded familiar, give it a try — there’s a free 14-day trial, no card required.

And if you’ve got opinions about what a .env tool should or shouldn’t do, tell me. I’d rather hear it now than after I’ve shipped something nobody wants.