MiniEnv vs
sending the .env file
Sending the file works. That is why almost everybody does it, and why a comparison page that pretends otherwise is not worth reading. The problem is not the sending. It is that you cannot unsend it, nobody records who has it, and changing one value means finding every copy.
| MiniEnv | Sending the .env file | |
|---|---|---|
| Cost | Free to five people, then $29.99/mo flat | Nothing, ever |
| Setup | Download, sign in, share a project | None. You already know how. |
| Who has a copy | The current members of the project | Unknown, and unknowable |
| Changing one value | Everyone has it on their next pull | Find every thread you sent it in |
| When somebody leaves | Every value re-encrypted before the removal is accepted | Nothing happens. They keep the file. |
| Secrets that are not KEY=value | A vault of up to 100 entries per project, alongside the env vars | Whatever you attach, carrying every problem above |
The comparison is against the practice, not a product, so the only checkable figures here are ours and the popularity of the .env format itself.
What MiniEnv does not do. The app runs on macOS 12 or later, on Apple Silicon. There is a CLI, which does the same encryption with the same Keychain identity and covers projects, members, teams, devices and the vault, but it is macOS only as well and it needs Node 20.19. So: no Windows, no Linux, no iOS, no Android, on either. Nothing injects secrets into a running service and nothing fetches values at boot. If any of that is a requirement, stop reading here: the tool on the other side of this page is the right one.
Why it is so hard to beat
The .env file is not a bad format. It won because it is the
smallest thing that works: one file, one line per value, readable by everything.
The dotenv package recorded 178,126,632 npm downloads in the week of 23 to 29
August 2026, which is not a fashion.
And sending it is free, instant, needs no account from the person receiving it, and has no failure mode on the day you need it. Every tool on this site, including ours, is worse than that on all four counts.
What it actually costs, stated plainly
Not "it is insecure". That is the version of this argument nobody acts on. Three specific things:
- There is no list. Six months in, nobody can say which people, laptops and chat histories hold a copy of your production database URL. Not because anyone was careless: there is simply no record being kept.
- Changing a value is a broadcast. One value rotates and you are messaging people individually, and somebody's local copy stays stale until their build breaks.
- Leaving changes nothing. A contractor finishes on Friday and still has the file on Monday. Whatever you do about that, you do by hand, from memory, at the source.
MiniEnv does not fix the third one retroactively either. Removing somebody re-encrypts everything so they read nothing new, but a value they already pulled is on their machine and stays there. Rotate it at the provider. Anybody selling you a tool that claws a secret back is selling you something that does not exist.
And the things that are not in the .env file at all
The .env is only half of what gets sent. The other half is the
service-account JSON, the Apple .p8, the PEM, the deploy key, the
recovery codes. Those get attached to a message, and they are worse than the
env file on every count above: bigger, longer-lived, and harder to rotate.
MiniEnv keeps them in a vault beside the env vars, encrypted to exactly
the same people, up to 100 entries per project at up to 65,536 bytes each. It
is a separate collection rather than a flag, so nothing that writes a
.env or pushes to Vercel can reach one.
One thing it does not hide: the relay can see that a project holds an entry labelled "Firebase admin (prod)" of kind service_account. The label and the kind are plaintext to us. The value never is.
When sending the file is still right
A side project with one contributor. A value that is not a secret. A one-off handover to somebody who is about to have production access anyway. Anything where the list of who holds a copy is short enough to keep in your head and short enough to stay there.
The moment that list stops fitting in your head is the moment any of this is worth paying for, and that moment usually arrives somewhere around the third or fourth person.
When to keep sending the file
- You work alone. There is nobody to share with, so there is nothing to manage.
- The recipient is not on a Mac. MiniEnv cannot help them at all.
- It is genuinely once. Setting up an account for a single handover is more work than the handover.
- The values are not secret. Feature flags and public API bases do not need any of this.
Where these numbers came from
Every figure above, including ours. If one of them has gone stale, it is a bug on this page and worth telling us about.
- The dotenv package recorded 178,126,632 npm downloads in the week of 23 to 29 August 2026.
https://api.npmjs.org/downloads/point/last-week/ · read 30 August 2026 - dotenv has 20,527 GitHub stars and was last pushed to on 4 August 2026.
https://api.github.com/repos/motdotla/dotenv · read 30 August 2026 - A vault entry label and kind are plaintext to the MiniEnv relay. The value never is.
https://minienv.dev/ · read 30 August 2026 - MiniEnv Free is $0 and covers five people, including the admin.
https://minienv.dev/ · read 30 August 2026 - MiniEnv Pro is $29.99 per month, flat, with no per-seat charge, and one subscription covers up to 3 teams you run.
https://minienv.dev/ · read 30 August 2026 - The MiniEnv app runs on macOS 12 or later, on Apple Silicon. There is no Windows, Linux, iOS or Android client.
https://minienv.dev/ · read 30 August 2026 - There is a MiniEnv CLI. It does the same encryption on your machine, with the same Keychain identity as the app, and covers projects, members, teams, devices and the vault. It ships inside the app and is installed from Settings in the app, so it is the same release as the app; it needs Node 20.19 or later, and is macOS only, because private keys live in the macOS Keychain.
https://minienv.dev/ · read 30 August 2026 - A MiniEnv project has a vault: a separate collection for secrets that are not KEY=value, such as a service-account JSON, an Apple .p8, a PEM or SSH deploy key, recovery codes or a note. A project holds up to 100 entries, each at most 65,536 bytes once encrypted.
https://minienv.dev/ · read 30 August 2026 - The vault is a different collection from a project's env vars, so a pull cannot write a vault entry into a .env file and a Vercel push cannot send one. Removing a member re-encrypts the vault and the env vars in the same write, and a client that submits one without the other is refused.
https://minienv.dev/ · read 30 August 2026
The other comparisons
They are already in the building, and Environments is included in the plan you pay for. The case for looking anyway is narrow, and it is about what happens when somebody leaves.
Encrypt the .env file and commit it, versus keep the values out of the repo. Both are defensible. They differ most on the day somebody leaves.
Built for machines fetching secrets at runtime. We do not do that at all, which makes most of this comparison a question of which problem you have.
Open source, self-hostable, and free for five identities. The catch is what an identity is, and it is worth understanding before you plan around the free tier.
Encrypt it and commit it. Free, portable, and used heavily. The manual part is key management, and that is the part we automate.
If your workloads are in AWS, this is not really a competitor, and the free Parameter Store option is the one that deserves your attention first.