Remove `Loading env from encrypted .env.vault` console log when loading from .env.vault file.
Hi! When a .env.vault file is being loaded a console.log is printed out every time (even with debug: false) which breaks usage in CLI apps where the stdout will be fed into another process and it only expects a single JSON in stdout.
will try and get to this soon. in the meantime, have you seen dotenvx ?
.env.vault files are now deprecated and I'm slowly trying to move everyone over to encrypted .env files using dotenvx.
Dotenvx still misses some key features from dotenv...
Not having granular control of who can read/write envs in an environment because there's only one decrypting key is not safe. Combine that with the absence of a rotatekey command I see no value in migrating to dotenvx yet.
Changing the approach of granular control just for the sake of being able to encrypt things without being able to decrypt can kill a lot of common enterprise use cases.
The last time I tried dotenv hub it did not work and the documentation around it does not seem mature enough :/
Anyways, this is my general feedback for dotenvx. Amazing work you've been doing and I hope to move to dotenvx in the future :)
good feedback around dotenv-vault and .env.vault files
dotenvx hub has been deprecated so yes, it is not going to fill your need - i've deleted that docs page (had missed it a while back).
working on dotenvx pro that will give you everything you mention here.
And thanks for your patience and appreciation of the hard work. I think we are very close to a really solid ecosystem for the industry:
- encrypted .env files independent of any 3rd party with light granular control (private/public key)
- dotenvx pro zero-knowledge solution adding granular access control, auditing, and more
oh btw @arthurfiorette, dotenvx DOES currently load .env.vault files. So you could choose to use it for loading .env.vault files and then continue using dotenv-vault for push/pulling them. Bit round about, but it is there. If you do that you get way more control over the logs and additional commands like get:
https://github.com/dotenvx/dotenvx/blob/main/src/cli/actions/run.js#L48
We did this so eventually we can provide an easy migration path.
Using dotenvx is not a viable option because the library that utilizes and loads dotenv is outside of our control. We cannot change it or switch multiple community packages that rely on the well-established, documented, and widely-used package dotenv to a newer (even if "better") alternative.
We cannot change it or switch multiple community packages that rely on the well-established, documented, and widely-used package dotenv to a newer (even if "better") alternative.
can you elaborate? both are written by me and I am recommending dotenvx because it is actually better documented and covers more edge cases now than dotenv.
When a .env.vault file is being loaded a console.log is printed out every time (even with debug: false)
You can use { quiet: true } now to hide this message. https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md#1660-2025-06-26