Stop Putting Secrets in .env Files • Hacker News Board

Post by theozero » Wed, Mar 04, 2026, 10:38 PM UTC

ivannovazzi wrote: post #20

theozero wrote: post #19

Earlier quoted context omitted.

While the 1Password model is not perfect, you can organize your vaults however makes sense for your project. You can do prod/staging/dev, or by projects, etc. Or you can use the new environments feature and create a separate "environment" for each. Service accounts and users can be granted access to specific vaults only. The huge benefit is that if you are already using it for other stuff, there is no additional "sec…

Good points — the "no secret zero" advantage of 1Password is real, especially if the team already uses it. Biometric unlock is a nice UX win too. Where we saw friction was in CI/CD and multi-service setups. 1Password's op CLI adds ~2-3s per secret fetch, which compounds in pipelines with dozens of env vars. KeyEnv batches the pull so it's one round-trip regardless of how many secrets you need. The other gap we kept h…

Reading from 1Password definitely does add some overhead, but at least our integration fetches in bulk so should be ~2s total and not scale with number of secrets. For team members, they don't need any service accounts, so its just making sure they are granted vault access, which can be managed through team settings you likely already have set up anyway. Add new team member to "devs" and you're done. Anyway certainly not perfect, but sure beats a lot of the other options.

Should be easy enough to set up a keyenv plugin - varlock adds a lot of additional last mile tooling to get secrets/config integrated into projects, regardless of where they ultimately live.