Also wondering how to do this

We could run dotenv-vault pull, which will populate our .env and then run dotenv -- <some-subprocess>, which would pick up those vars

But this will only work when logged in, therefore this would only work for development environment

Curious how to do this without being signed in, when we set the DOTENV_KEY in our env I would expect that there is a CLI command that would read this variable, decrypt the .env.vault and pass it to all sub commands

ChatGPT is suggesting:

Then, you can use the dotenv-vault exec command to automatically decrypt your variables and pass them to a subprocess. For example, if you want to run a Node.js script that requires access to your sensitive variables, you can use the following command: dotenv-vault exec -- node script.js

Well, this command doesn't exit. LOL

Probably duplicate of #174

It's probably not the exact equivalent of dotenv-cli but you could run local-decrypt command to fetch / generate your .env file and then concatenate whatever CLI command you want:

npx dotenv-vault local decrypt $DOTENV_KEY > .env

You can then go through that file to export the variables into your shell environment or adapt your CLI script / tool to read that .env file directly (like the original dotenv).

Similar to what @devidw proposed by using the DOTENV_KEY, without the need of being signed in or having a .env.me file around.

I created dotenv-vault-core-cli to achieve this

npx dotenv-vault-core-cli -e .env -- my-script

The sooner the package is made irrelevant by upstream changes the better

Update

You can now use dotenv-cli instead, with dotenv >= 16.1.0
dotenv-vault-core-cli has been deprecated

Thank you, @hbriese.

We want to make .env.vault support first-class and open. We've been hard at work on that.

There is an RC candidate here: https://github.com/motdotla/dotenv/tree/v16.1.0-rc1

That is just about ready.

We're now wrapping up work on local support (no remote API calls) to generate your .env.vault file. The ruby, python, and golang libs explain it best at the moment.

It's coming for node soon. We've been working in languages where it will have less impact. This update to dotenv nodejs will be its most significant update in many years.

Then everyone downstream using dotenv will have the option to use .env.vault files if they choose.

All local commands will live here: https://github.com/dotenv-org/dotenv-vault/tree/master/src/commands/local

I just want to bump I believe this is resolved now?

I see that support is now in dotenv, and theoretically dotenv-cli can handle it.

There aren't any documented examples though

I just want to bump I believe this is resolved now?

I see that support is now in dotenv, and theoretically dotenv-cli can handle it.

There aren't any documented examples though

Yep dotenv-cli works now with with dotenv >= 16.1.0, I'm using it just as shown in their docs

npx dotenv <command with arguments>

Yep, their package.json as 16 or greater in it: https://github.com/entropitor/dotenv-cli/blob/master/package.json#L11

so as long as you install fresh, you'll get 16.1.4 and should be able to decode .env.vault files. I haven't tried this, though, yet. We'll try to get a guide on our dotenv.org/docs soon.

Yep dotenv-cli works now with with dotenv >= 16.1.0, I'm using it just as shown in their [docs]

Any thoughts on what to do with a non-standard .env path? Just reference the vault file?

for example inside a nested folder that uses a require like this:

require('dotenv').config({
	path: '../../.env',
});

I guess dotenv ../../,env,vault <command> I'll see what happens

Currently, you'll have to cd to the directory where the .env file is and then run:

dotenv-vault push/pull/etc

from there.

On our todos is a better way to handle this - especially with multiple .env files in a monorepo.

Hmmm little confused, so just to clarify:

.env.vault
/workspaces
  /workspace-1
    package.json <-- run script in here with environment variables
  /workspace-2

Both workspaces use the same enviroronment variables (So just 1 .env for all)

With the update you shouldn't have to decode the .env.vault file into an actual .env file anymore

dotenv-cli should be able to just read in the .env.vault, and as long as the process.env.DOTENV_KEY exists it should work?

Yeah I can't get any configuration to work, i'm not sure how you are doing it @hbriese? This is ignoring my path stuff from before, we are just talking:

.env.vault
package.json

dotenv alone shouldn't do anything unless process.env.DOTENV_KEY already exists to decode the .env.vault file.

So to test locally I add it with a few different configurations:

dotenv -v DOTENV_KEY=<key>
dotenv -v DOTENV_KEY=<key> -e .env
dotenv -v DOTENV_KEY=<key> -e .env.vault

None of them load the environment variables in

Yeah I can't get any configuration to work, i'm not sure how you are doing it @hbriese? This is ignoring my path stuff from before, we are just talking:

.env.vault package.json

dotenv alone shouldn't do anything unless process.env.DOTENV_KEY already exists to decode the .env.vault file.

So to test locally I add it with a few different configurations:

dotenv -v DOTENV_KEY=<key> dotenv -v DOTENV_KEY=<key> -e .env dotenv -v DOTENV_KEY=<key> -e .env.vault

None of them load the environment variables in

Looks like you're trying to use dotenv on the cli (if it wasn't a mistype), dotenv-cli is required for cli usage.

Not 100% if this is required, but dotenv-cli still has dotenv"^16.0.0" so I set a dependency resolution to make sure the package uses dotenv "^1.6.1.3"
package.json

"resolutions": {
    "dotenv": "^16.1.3"
},

You can verify it worked with yarn why -R dotenv (npm has an equivalent) and seeing which version dotenv-cli is using

I don't think passing the DOTENV_KEY to -v works as it looks to populate process.env AFTER calling dotenv so pass the variable directly to the process instead.
My .env.vault is in the previous dir so I use DOTENV_KEY=... npx dotenv-cli -e ../.env -- $myScript

Not 100% if this is required, but dotenv-cli still has dotenv"^16.0.0" so I set a dependency resolution

I did the same ^

I don't think passing the DOTENV_KEY to -v works as it looks to populate process.env AFTER calling dotenv so pass the variable directly to the process instead.
My .env.vault is in the previous dir so I use DOTENV_KEY=... npx dotenv-cli -e ../.env -- $myScript

I was just about to try this thinking the same thing ^^^

It's fine on the server, because it's already running DOTENV_KEY before any scripts are called, just locally is the problem

Will confirm if this works in a little while

Confirming @hbriese that the resolutions is indeed necessary! I'll raise a ticket for them to bump it up to support vault

Pushing the DOTENV_KEY in early was the fix.... they might need to implement a way to pass it for Vault files in the future.

I guess we can close this now!

If they need to set it directly in the library that is supported as of a few weeks ago:

https://github.com/motdotla/dotenv#dotenv_key

require('dotenv').config({ DOTENV_KEY: 'dotenv://:key_1234…@dotenv.org/vault/.env.vault?environment=production' })

In order to get the same resolutions hotfix for dotenv-cli as noted by @hbriese working in pnpm we can do:

.pnpmfile.cjs

module.exports = {
  hooks: {
    readPackage(packageJson) {
      if (packageJson.name === 'dotenv-cli') {
        packageJson.dependencies['dotenv'] = '^16.1.3'
      }
      return packageJson
    },
  },
}