💡 Feedback and Feature Requests

[motdotla]

Post your feedback, suggestions, and feature requests here.

dotenv-vault is great but it's just getting started. We have a long way to go to improve the DSX (developer security experience) around managing secrets and environment variables.

Share your ideas to improve its capabilities and improve that experience. Thank you for using dotenv-vault. 🙏🎩

[romainPrignon]

Thanks for making dotenv-vault. It's the logical continuation to .env

Do you guys plan to add 2FA on the GUI and CLI ?
It would be great to be able to do:

npx dotenv-vault pull --otp=...

Thanks !

[motdotla]

You are welcome.

Yes, we do have plans for both.

What you can use in lieu of that in the moment (for the CLI) are Infrastructure tokens.

1. Click 'Infrastructure' for your project
2. Add the somewhat generic 'Docker' integration
3. This will generate an Infrastructure token for you
4. Use that with dotenv-vault pull: npx doten-vault pull --dotenvMe it_1234

Those infrastructure tokens are ONLY permitted to pull and ONLY for a specific environment. We have plans to add auto-expiration to them as well. At the moment, they never expire.

[LaCocoRoco]

I thought i post these points in this topic because they are probably more feature requests then issues.

Nr. 1

The default development environment is set to .env and can't be changed to .env.development.
I would prefer a more flexible way to set a specific filename per environment.
Workaround: npx dotenv-vault pull development .env.development and npx dotenv-vault push development .env.development.

Nr. 2

Pulling the environment with IT token will always write into the .env file.
So far i am aware the IT token is unique per repository and environment.
In my opinion IT token should pull into the corresponding .env.* file.
Workaround: npx dotenv-vault pull --dotenvMe it_token default .env.name.

Nr. 3

A quick edit button for the secret in the DotENV Web UI would be desirable.
Always clicking edit and save can get some kind of anyoing.
I mostly use push pull, so for me this problem is negligeable.

Nr. 4

The DotENV Vault extension is not avilable for coder/code-server VSCode Web .
Probably it is also not available on other web IDEs like GithHub Codespace or Gitpod.
The extension can still be installed via VSIX file.

Nr. 5

About 14 million people using Material Icon Theme Extension.
Probably you could request to add a custom icon for .env.vault and .env.me to the icon list.

Side Note

On the whole it is a very good development experience and i hope for future improvement!

[motdotla]

Thank you @LaCocoRoco. These are great thoughts.

Nr. 1: Good thought. Let us think about this one.

Nr. 2: Let us think on this one as well. We actually have a new 'Deploy Everywhere' feature coming that will make IT tokens less important. Stay tuned.

Nr. 3: Agree. Added to our internal todos.

Nr. 4: Started this process. Tracking here: dotenv-org/dotenv-vscode#41

Nr. 5: Nice idea. We'll make the request.

[motdotla]

Nr. 5: Request made material-extensions/vscode-material-icon-theme#1699. Please upvote :)

[LaCocoRoco]

Nr. 5: Request made PKief/vscode-material-icon-theme#1699. Please upvote :)

Done!

[jameswyse]

Could the slack app support private channels? They currently do not show up in the list of channels, even after inviting the bot to the channel

[motdotla]

Possibly we have a regression bug. It used to work with private channels. We will take a look.

[dimitrihilverda]

We like this tool, Thanks for this,
One thing I noticed, is that, when you use variable inside the value, that this variable is replaced by the value.
E.g.:
If I have these 2 line:
CDN_PATH="/var/www/mydomain/"
CDN_UPLOAD_BONIMAGES_PATH="${CDN_PATH}uploads/bonimages/"

the result in the vault, after push will be:
CDN_PATH="/var/www/mydomain/"
CDN_UPLOAD_BONIMAGES_PATH="/var/www/mydomain/uploads/bonimages/"

Why is that? I like to keep those placeholders in there for offius reasons.

And would it be possible in the GUI, that you can copy/apply the value from one .env to the others. Maybe next to the copy icon, copy to other environment? especially for key's that you use for 3th party api's that are the same for all environments.

Again, thanks for this great tool,

Dimitri

[motdotla]

Hi @dimitrihilverda,

Great to hear you are enjoying the tool. It is going to get even better. Take a look at Deploy Everywhere™ if you haven't already.

Why is that? I like to keep those placeholders in there for offius reasons.

They are expanded, but I agree.

I'm putting that on our todos to fix up.

would it be possible in the GUI, that you can copy/apply the value from one .env to the others. Maybe next to the copy icon, copy to other environment

Also agree. This is on our TODOs already but we haven't got to it yet.

[MarcHurst]

Hey guys,

I don't see it in the documentation, but it's possible I just missed it. You can specify a custom path for dotenv files (config/.env for example) but as far as I can tell, you can only sync a .env in the root directory.

Am I missing something? Is this in the plan, or is having non-root .env files nonstandard, and I should just learn to keep them in root project directory?

[motdotla]

You can do that now.

$ npx dotenv-vault push ENVIRONMENT FILENAME

Here are a few real world examples:

$ npx dotenv-vault push production .env.production
$ npx dotenv-vault push development .env.local
$ npx dotenv-vault push development .env.dev

Does that help?

[motdotla]

Here's a path example:

$ npx dotenv-vault push development folder/.env

[MarcHurst]

npx dotenv-vault push production config/config.env
remote:   Securely pushing production (config/config.env)... done
remote:   Securely pushed production (config/config.env)

Run npx dotenv-vault open to view in the ui

Thank you so much! That worked like a charm.

[dimitrihilverda]

You can use a complete path to a .env when you pull or push Op wo 26 okt. 2022 02:55 schreef Marc Hurst ***@***.***>:

…

Hey guys, I don't see it in the documentation, but it's possible I just missed it. You can specify a custom path for dotenv files (config/.env for example) but as far as I can tell, you can only sync a .env in the root directory. Am I missing something? Is this in the plan, or is having non-root .env files nonstandard, and I should just learn to keep them in root project directory? — Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEN2MP6CGU5FWAAN3FAEDX3WFB6P5ANCNFSM54WMYVNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sirajulm]

Hello,
First of all thank you to the entire team working behind dotenv-vault.
I can see integrations for Node.js, Ruby, Next, etc. But I've a requirement to run some applications via shell script inside docker, where I would need the dotenv to be populated.
I know I can use the pull command to pull the environment variables into a .env file. But I could now see the integrations for Docker, Github actions etc are deprecated in favour of build and using the variables with the app using decryption keys.

Is there a way I can use the encrypted .env.vault file and use a corresponding key to decrypt the values into a .env file? Or what is the alternative to using pull with integration tokens, if integration is considered to be deprecated?

Something like npx dotenv-vault decrypt would be good to have in my opinion.

[motdotla]

Hi @sirajulm,

I agree, completely.

For now, use the External Share integration to unblock yourself.

Meanwhile, we'll start adding this functionality. Will probably be implemented as you suggested npx dotenv-vault decrypt dotenv://vlt_1234@dotenv.org/v1/vault?environment=production

[sirajulm]

Thank you @motdotla, that would be a great addition. Awaiting to see it come live. I can continue using the integrations until then.

[motdotla]

Tracking here. #235

Should have ready soon.

[motdotla]

This is done. https://github.com/dotenv-org/dotenv-vault#decrypt

[dawidvdh]

Amazing work! I have a team using this for a mobile app, we are however using Fastlane to handle deployments. I would love to see a Fastlane plugin for this!

[motdotla]

We'll start work on this soon!

[dawidvdh]

Hi, I am just curious if you have managed to find time for this or if you have a suggestion of what commands to use to implement this manually. Basically, depending on an env param provided to Fastlane I need to use dotenv to pull down different environments. so if I pass in DEV it should pull the latest dev dot files and so on.

Let me know if you have any suggestions so far I can only see ways of setting pulling the envs and setting them on the OS's envs but not so much pulling the different files as we have a build process that also uses API_KEYS from the .env file and doesn't read the OS environment variables for it.

[motdotla]

Hi @dawidvdh - with fastlane, what language(s) can you write in?

The way to do this would be to use the encrypted .env.vault file. Store that with your fastlane code, and then pass a different DOTENV_KEY to decrypt either development or production, and so on.

[TheRealFlyingCoder]

Hey @motdotla!

I've just got two suggestions at the moment :D

1, UI should include a way to group related keys together

Many devs use comments to break up their env files, and this is lost with vault currently, if you included a syntax for comment grouping that could translate into the local file as well that'd be awesome:

## OAuth ##
FACEBOOK_ID=
FACEBOOK_SECRET=
GOOGLE_ID=
GOOGLE_SECRET=

would translate to an "Oauth" accordian in the UI, and if you went UI -> .env it would generate with the comments in place

2. Setting up a monorepo example.

One of the key value points with Vault is the ability to simplify difficult systems, and nothing is more annoying than setting up secrets for a monorepo with multiple projects that deploy separately and all share the same keys :)

The key thing this would show is:

1. Storing .env files at the root
2. Referencing thos files from inside a workspaces

[motdotla]

@TheRealFlyingCoder

1. Agree 100%. We're getting closer to this. Under the hood we now keep track of those groupings you send, but we aren't surfacing that in the UI yet.
2. Good point. Need to think on this one more and probably experience the pain myself.

[FullmetalBober]

Hello, is it possible to push .env.local file?

[sirajulm]

The push defaults to environment development and filename .env. I am not sure why .env.local need to be pushed, when it is supposed to be a local change.
If you really need you can still do it using
dotenv-vault push development .env.local and pull in similar way

[jgoux]

I just tried dotenv-vault on my monorepo lab: https://github.com/jgoux/acme and I think the support for monorepo isn't there yet.

My goal:

• one .env file per apps/packages, I don't want to mix them all into a single .env at the root of the monorepo.
• doing a push/pull should be one command that affects all packages together (doable with turborepo and setting up a "env:pull" and "env:push" scripts in each package).
• I should be able to login once for the entire monorepo. For this one, it would mean that the .env.me should be searched by dotenv-vault in the current folder and any of its parent hierarchy (using something like https://www.npmjs.com/package/find-up). Ideally, I would expect to have a single .env.me at the root of my monorepo. Currently this is doable by passing DOTENV_ME to turborepo in the root of the monorepo.
• I should be able to define the scope of the DOTENV_ME. Right now the token is scoped to one project, and this is where it's a deal breaker for monorepos. I think this should be user configurable so we can give our token the authorization to access every projects that are part of our monorepo.

In the end I think dotenv-vault is almost there for monorepos with a proper documentation, but it's not usable in its current state without being able to scope the DOTENV_ME token to multiple projects. Having to login per project in the monorepo is a dealbreaker to me, and it would be complicated to handle all the DOTENV_ME secrets in CI and other environments. It must be one "dotenv-vault pull" to pull all the secrets across the monorepo.

[jgoux]

I think in the meantime, I'll make a unique .env at the root of my monorepo with variables namespaced like:

API__DATABASE_URL=

CLI__VERSION=

WEB__VITE_API_URL=
WEB__CHROMATIC_API_KEY=

And once I pull the file, I'll post-process it to create one .env per namespace using some kind of configuration:

{
  "API": "apps/api",
  "CLI": "apps/cli",
  "WEB": "apps/web"
}

edit: seems like for pulling, DOTENV_ME is required. So I can't use DOTENV_KEY in CI, I'll have to put my runtime environment inside a variable as well in order to do something like dotenv-vault pull $NODE_ENV .env 🤔
Then same as what I'm asking for DOTENV_ME, it should be possible to scope DOTENV_KEY to multiple projects.

[albanv]

Hi,

First of all, thanks for dotenv-vault !
We are migrating from doppler and there is one use case I'm not able to "perfectly" reproduce with dotenv-vault:

Basically before, we were able to tell doppler which env it needs to use at runtime ("test": "doppler run -c test -- jest" for instance).
With dotenv-vault or dotenvx I always needs to perform dotenv-vault pull test to update my local .env.test to be able to have something similar: "test": "dotenvx run -f .env.test -- jest" it can be handy since it lets developer easily customise their envs depending on what they are working on.

Most of the time tho. I think I just want to use the same env than everyone in the team is using, hence using directly what's inside the .env.vault. I would want something like: dotenvx run -c test.

Currently I'm able to achieve what I want with "test": "DOTENV_KEY=$(dotenv-vault keys test) dotenvx run -- jest" and I just wanted to know if there is a better way to achieve the same result and what are you thinking of this use case ?

[motdotla]

your solution is the recommended approach currently but admittedly it is a bit verbose. we'll keep this in mind. it would be nice to tighten this up.

[twardoch]

So there's https://dotenv.org/ (the TOS say Dotenv ("Company")) and https://dotenvx.com/ (the TOS say Dotenvx ("Company")). There are different Github orgs, different X accounts, different "companies" (but without any details). Both use the same logo and the same tagline "dotenv. better.".

Neither project references the other. Are both legit? What's the relationship? Is one a scam? It all looks suspicious, perhaps unnecessarily. Some clarification would be useful.

The projects that are about secret management are a bit too secretive themselves for my taste.

[motdotla]

hi @twardoch. yes, both are legit and both largely written by me - the creator of dotenv.

in terms of tech, dotenv.org (dotenv-vault) was created to solve the syncing of .env files. it's 100% a cloud product. you need the service to use it. but during it's development, I discovered we could provide 90% of the usefulness of it without needing the cloud - that was the invention of the .env.vault file.

we did a lot of work adjusting dotenv.org (dotenv-vault) around the .env.vault file, but foundationally we could never get quite there because of original design decisions a couple years back.

that's when we started building dotenvx. it works 100% without requiring a cloud product. it's a tool/lib (just like dotenv was).

i'm recommending dotenvx going forward, but dotenv-vault is currently more mature for large teams. we have plans to provide an easy migration path, but dotenvx's team features need at least 6 months more to mature before we do that.

so tld. both are NOT a scam. there are now 3 levels of solutions:

• dotenv
• dotenv-vault
• dotenvx

apologies for this, but I'm a developer and not a business man so I tend to prioritize building a new tool - even if that confuses the business offering a bit. Eventually we'll solve this business offering confusion with the migration path I mentioned and by pulling dotenv.org into the dotenvx brand.

as to the legal naming, both are under the same California LLC and 'Dotenv' and 'Dotenvx' are DBAs.

[motdotla]

also to add to this, we had a very well capitalized competitor swoop up the dotenv.com domain and sort of hold it captive as an attempt to acquire us. they are now graciously redirecting it for us, but we will likely never control it or be able to afford to purchase it off them. eventually, I settled on dotenvx.com as a good .com solution to this that also fit well with our goal of making a better dotenv. '10x', 'x-factor' - that sort of vibe. etc.

it seems to be working as dotenvx is now growing even faster than dotenv.org (dotenv-vault).

what do others think? have any ideas on how to clarify this confusion? merge them into one product, something else? better explanation on the websites? i'm all ears.

[twardoch]

Thanks for clarification. I was confused by the user-facing websites, since they might look by the surface as dome kinds of clones/imitations/competitors. (I can imagine others might be as well.)

The repos themselves give a somewhat clearer picture.

I didn't want to imply any foul play actually taking place, but we are aware of "hostile forks", various kinds of imitations, and the recent "xz" hack-drama.

Since dotenv[x] operates on a very sensitive space, having a fake project that might actually steal/collect some credentials would be terrible. That's why I was confused. But it looks like all is fine — I guess just reciprocal linking between dotenvx.com and dotenv.org in their footers might help.

[motdotla]

Since dotenv[x] operates on a very sensitive space

100%.

I can imagine others might be as well

I'm sure. My rule of thumb is usually for each person that brings something up at least 10 thought/experienced the same thing.

So thank you for being the one to bring this up.

Particularly, in light of xz this is even more important than before.

putting on my todos to have a header or footer bar with a link to a page explaining the differences.

[darklight9811]

Is there a way to merge envs from remote and local?

Example where this can be useful: in development I need to use the company auth api keys since we cant replicate that locally, but yet we still need to setup our own database. So it gets kinda cumbersome to maintain two env files, it would be cool if we could allow dotenv to merge two different env files to avoid duplication and allow us to only override the envs we actually need.

That way we could still be in sync with the vault, and have the changes we need to make it work locally too.

[darklight9811]

Actually just noticed we can do this with dotenvx, still needs to suppress the error in case the secondary file is not found (I want it to be an optional overload)

[motdotla]

you can pass --quiet to suppress any warnings:

dotenvx run -f .env.local -f .env --quiet -- node index.js

[darklight9811]

Not really a fan of having 6 files to handle env

[motdotla]

yeah, i feel you. we recommend moving away from the .env.me and .env.vault file actually. dotenvx will replace them coupled with an in-progress dotenvx-pro. this way there is only one additional file to maintain - the .env.keys file.