Comment on: Where .env Went Wrong
No it isn't.Your local .env should NOT be shared, but should also be assumed to be leaked at any given time. Security should be done using a secrets manager through the cloud platform that's being used, e.g. AWS'secrets manager (or ssm param store too i guess)Pasting it into chatgpt should not be a problem.It also doesn't belong in git repos, but a much bigger issue is what process led to it. It's pretty standard to ignore it in a .gitignore, I'd be very surprised if modern agents made that mistake. And even if they did, agents should call tools that scaffold deterministically so that this isn
Comment on: Where .env Went Wrong
I'm working with .env and secrets and teamwide configs for the first time, trying to understand solutions from first principles.Are these valid observations so far?- .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?- .env.example seems like a nice home for documentation about secrets- but I'd rather avoid writing sensitive credentials at all -- instead, teams can use a cloud-based secrets manager and the project fetches secrets at runtime. Is this ever a hassle / any downsides? How standard is this practice these days? I hear this also helps updatin
Comment on: Where .env Went Wrong
> - .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?I don't see a reason to ever pass them. Sensitive production values should never be accessible to everyone, and for development the team should be able to create them themselves.I usually keep very stupid values in .env.example, with the instructions to `cp .env.example .env`. In development it doesn't matter if the password is "password". In production the privileged admin sets up actual values.> - non-sensitive environment variables also need a home. I don't like the idea of cluttering the proje