I came here to mention the 1Password cli[1] which has a great DX for solving this problem since one can check in the reference to the Secret[2] and it will be resolved by anyone who has permissions to said Secret at the time of consumption

They also have a plugin system[3] that makes it work moderately seamlessly with various other CLI utilities which expect credentials in the environment, such as the `gh`[4] CLI and bazillions of others

1: https://developer.1password.com/docs/cli/

2: https://developer.1password.com/docs/cli/secret-reference-sy...

3: https://github.com/1Password/shell-plugins#-see-it-in-action

4: https://github.com/1Password/shell-plugins/tree/main/plugins...

I tried to get my head around the 1Password implementation of this, but as far as I could work out, every single secret is stored as an individual item in 1Password and the 1Password app makes no accommodations for the differences between a server secret and a login. We have maybe 100 projects, with multiple environments for each, and multiple secrets in each environment - managing this in 1Password looks like it would be an absolute nightmare.

Edit: to expand on this a little, even the image [0] they show on their secrets management landing page is baffling. It's showing an entry in the 1Password app called `AWS - Access Key`, which for some reason has a username and password. Now if I need to inject that into the environment variables on my server, what's the name of the envvar, because `AWS - Access Key` isn't going to work. How do I separate staging variables from production variables? How do I know which project this is the AWS access key for?

[0] https://images.ctfassets.net/b71sid4v0oel/7zRNbDUY8dxGuKxUtV...

just guessing but since access keys are paired with secrets that’s why you see a username and password there.

1p lets you create arbitrary fields in an entry, so you could create one with a VARNAME field or something, or just use a naming convention on the entry. for project isolation you could create separate vaults or use tags to distinguish.

You can use different vaults for different projects and different environments. IIRC you can then automatically switch between, for example, dev and prod vaults using environment variables in the references in the .env files.

So on a dev machine it could use the dev vault for your project, but when you deploy it could use the prod vault.

Within vaults you can name and organise how you like, you’re not limited to usernames and passwords. You can have arbitrarily named fields, whole text blocks, or files.