Introducing OnlyNv: Your one-stop solution for managing environment variables. (onlynv.dev)
from TheCommieAxolotl@programming.dev to programming@programming.dev on 15 Apr 02:48
https://programming.dev/post/28632487

#programming

threaded - newest

mehdi_benadel@lemmy.balamb.fr on 15 Apr 05:25 next collapse

Waiting for the leak announcements

Boomkop3@reddthat.com on 15 Apr 05:31 next collapse

Environment variable abuse

cr1cket@sopuli.xyz on 15 Apr 08:14 next collapse

Oh wow.

That looks like an overly complicated solution to a problem that doesn’t exist. Synching stuff that is in git? Why not just use… git? Also npm… and the example has an env var named “DB_PASS” in it. You never put passwords in version control.

dragonfly4933@lemmy.dbzer0.com on 15 Apr 16:42 next collapse

It is generally considered a bad idea to use envs for passing secrets in general since envs for process n are available to other processes which have access and permission.

TheCommieAxolotl@programming.dev on 16 Apr 23:54 collapse

Exactly, you never check passwords into version control. So what happens when you need to share those values with other team members? The github example is not to put a .env file into a repo but to add the secrets to github’s native secret manager, which is what products like actions use to read envs.

chonkyninja@lemmy.world on 15 Apr 08:17 next collapse

Lmao, use Nix instead, or if that’s too complicated use DevBox.

Also, nobody with more than 0 brain cells will pay for this trash.

bizdelnick@lemmy.ml on 15 Apr 11:14 next collapse

The best way to manage environment variables: don’t use environment variables.

PolarKraken@programming.dev on 15 Apr 15:30 collapse

What do you do instead for dynamic values that are needed at runtime and inappropriate to check in to version control?

Corbin@programming.dev on 15 Apr 22:36 collapse

Nah, just use direnv instead, comrade.