3 ms·

Ask HN: How do small teams securely share env files?

5 points by tmr_praveen 5mo ago

late_night_fix 5mo ago
I've seen teams spend more time managing secret access than building features.There's definitely a balance between security and keeping developer workflow fast.
- nullsex 5mo ago
  [dead]
- tmr_praveen 5mo ago
  [flagged]
ale_jacques 5mo ago
I tend to use env variables instead of env files (12 Factor Apps - https://12factor.net/ https://12factor.net/). Safer, not safest. As @late_night_fix mentioned, there has to be a balance.
nullsex 5mo ago
[dead]
abstract257 5mo ago
I started to use the croc tool to sent the .env files.
mindwok 5mo ago
IMO env files are a bit of an anti-pattern, env vars should be set outside the context of your app so that your app doesn't need to care where they come from, it just uses standard env var APIs to read them. This means developers can choose how they load them and what tools they use to do so. With that said, the problem still exists just one layer higher. If they are secrets, I use Infisical (https://infisical.com/ https://infisical.com/) which is free and self-hostable, and let's you inject secrets at runtime via their CLI. Very handy for small teams. On top of that, I use direnv (https://direnv.net/ https://direnv.net/) with a hook to infisical's export command. This means when I 'cd' into a project, infisical runs and injects the secrets for my developer environment. Everything that isn't secret just lives in .envrc and gets loaded by direnv, and you can just send those files however you want because they aren't sensitive.
- tmr_praveen 5mo ago
  [flagged]
hiAndrewQuinn 5mo ago
`sops` and `age` are about as barebones as you can get if you want to have something to check into a repo, I suppose. Most CI/CD runners have secret storage you can use to make this a nonissue as well.
skydhash 5mo ago
Why does it needs to be shared? You either have a local copy of the infrastructure and set your own values. Or parts of the infrastructure is shared by the team so anyone can just get their own values. If it's something that's critical, then the usual security practices take place.
- tmr_praveen 5mo ago
  [flagged]
theozero 5mo ago
Check out varlock - it’s a free and open source toolkit to help with this. It has built in validation, extra protection for your secrets, and uses plugins to pull sensitive data from most common sources. Also has built in local encryption with biometric unlock.
chocks 5mo ago
I’ve used 1password secure note feature to share env vars.

5 points by tmr_praveen 5mo ago

I've seen teams spend more time managing secret access than building features.There's definitely a balance between security and keeping developer workflow fast.

nullsex 5mo ago
[dead]
tmr_praveen 5mo ago
[flagged]

ale_jacques 5mo ago

I tend to use env variables instead of env files (12 Factor Apps - https://12factor.net/ https://12factor.net/). Safer, not safest. As @late_night_fix mentioned, there has to be a balance.

nullsex 5mo ago

[dead]

abstract257 5mo ago

I started to use the croc tool to sent the .env files.

mindwok 5mo ago

IMO env files are a bit of an anti-pattern, env vars should be set outside the context of your app so that your app doesn't need to care where they come from, it just uses standard env var APIs to read them. This means developers can choose how they load them and what tools they use to do so. With that said, the problem still exists just one layer higher. If they are secrets, I use Infisical (https://infisical.com/ https://infisical.com/) which is free and self-hostable, and let's you inject secrets at runtime via their CLI. Very handy for small teams. On top of that, I use direnv (https://direnv.net/ https://direnv.net/) with a hook to infisical's export command. This means when I 'cd' into a project, infisical runs and injects the secrets for my developer environment. Everything that isn't secret just lives in .envrc and gets loaded by direnv, and you can just send those files however you want because they aren't sensitive.

tmr_praveen 5mo ago
[flagged]

hiAndrewQuinn 5mo ago

`sops` and `age` are about as barebones as you can get if you want to have something to check into a repo, I suppose. Most CI/CD runners have secret storage you can use to make this a nonissue as well.

skydhash 5mo ago

Why does it needs to be shared? You either have a local copy of the infrastructure and set your own values. Or parts of the infrastructure is shared by the team so anyone can just get their own values. If it's something that's critical, then the usual security practices take place.

tmr_praveen 5mo ago
[flagged]

theozero 5mo ago

Check out varlock - it’s a free and open source toolkit to help with this. It has built in validation, extra protection for your secrets, and uses plugins to pull sensitive data from most common sources. Also has built in local encryption with biometric unlock.

chocks 5mo ago

I’ve used 1password secure note feature to share env vars.