support specifying path to .env.keys file

[motdotla]

this would unlock the ability to store the .env.keys file as a secret file - similar to what Render and others support:

[insanity54]

I'm going to +1 this, with some context.

I have made the mistake of adding, .env* to .gitignore, but forgetting to add .env* to .dockerignore, resulting in plaintext .env in a docker build artifact.

As long as .env.keys is present in my git repo, I think it's vulnerable to being leaked this way, or another way I haven't thought of yet. I would prefer it be out-of-band, safe in a place like ~/.config/dotenvx/

[motdotla]

use dotenvx ext prebuild to make sure that never happens again in Docker.

RUN curl -fsS https://dotenvx.sh | sh

...

RUN dotenvx ext prebuild
CMD ["dotenvx", "run", "--", "node", "index.js"]

use dotenvx ext precommit --install to make sure it never happens in git.

$ dotenvx ext precommit --install
[dotenvx][precommit] dotenvx precommit installed [.git/hooks/pre-commit]

source

[motdotla]

I would prefer it be out-of-band, safe in a place like ~/.config/dotenvx/

this is a good idea and something we'll consider.

ease of use and per project is still very important so I don't think it will be the default, but it will be an option that it will be easy to switch to as your default.

[RIP21]

Another use case I would prefer is for monorepos to be able to have global .env.keys at the root of the repository. Having to copy-paste keys to multiple apps on onboarding is annoying.

So going up, up, up, up like, let's say, prettier and Node does when resolving modules to the root, is another good option. As doing --keys ../../.env.keys while OK and better than the workaround (like script that copies root one to apps below), is a tiny bit annoying/verbose :)

[SongRongLee]

I believe this feature would be highly beneficial, allowing users to decide how to manage .env.keys files within a monorepo or any type of project. In my use case, I prefer a project structure like this:

.
├── .env.keys
└── apps
    ├── app1
    │   └── .env.encrypted
    └── app2
        └── .env.encrypted

With this setup, I can define scripts in my package.json while specifying the key file (maybe using a -k option), for example:

...
"scripts": {
  "app1:encrypt": "dotenvx encrypt -f ./apps/app1/.env.encrypted -k ./env.keys",
  "app1:serve": "dotenvx run -f ./apps/app1/.env.encrypted -k ./env.keys -- serve-app1",
  "app2:encrypt": "dotenvx encrypt -f ./apps/app1/.env.encrypted -k ./env.keys",
  "app2:serve": "dotenvx run -f ./apps/app2/.env.encrypted -k ./env.keys -- serve-app2",
},
...

This approach avoids dealing with key concatenation for identical .env.xxx filenames (as discussed in #242). Additionally, if someone prefers to have separate .env.keys files for each app, they can do so by specifying the corresponding .env and .env.keys files easily. With such flexibility, we don't need to come up with new mechanism for different monorepo design. I hope this feedback helps improve the tool, and thank you for your hard work.