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.
It is generally considered a bad idea to use envs for passing secrets since envs for process n are available to other processes which have access and permission.
Seems like the point is that it’s encrypted, so that you are meant to store passwords here, thus why you’d want a separate syncing solution from git?
But uh… I’m inclined to agree it’s not terribly useful, I’d rather have .env files with my public config stuff (optionally overridable via actual environment values if I need a prod config change), per-environment, with environment values for secrets that my deployment tool of choice manages, that aren’t ever stored in a plaintext file. And the tools for that have existed for ages.
The only potential value I see here is for a team that isn’t mature enough to know how to properly manage deployments and secrets, separately syncing a single plain .env in a place that’s meant to handle a blend of secret and public config stuff would sound appealing.
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.
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.
It is generally considered a bad idea to use envs for passing secrets since envs for process n are available to other processes which have access and permission.
Seems like the point is that it’s encrypted, so that you are meant to store passwords here, thus why you’d want a separate syncing solution from git?
But uh… I’m inclined to agree it’s not terribly useful, I’d rather have .env files with my public config stuff (optionally overridable via actual environment values if I need a prod config change), per-environment, with environment values for secrets that my deployment tool of choice manages, that aren’t ever stored in a plaintext file. And the tools for that have existed for ages.
The only potential value I see here is for a team that isn’t mature enough to know how to properly manage deployments and secrets, separately syncing a single plain .env in a place that’s meant to handle a blend of secret and public config stuff would sound appealing.
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.