For my use case, I really need a way to specify different values of a key based on the environment an application is running in. For example, let’s say I have a key called MY_NEAT_API_KEY in a project called My_API.
Within My_API I want three environments DEV, STAGING, and PROD. MY_NEAT_API_KEY would have a different value for each environment. Then in an SDK client, I could specify which environment I want keys for.
For the sake of example, using the node SDK (with typescript here) the client setting could have an extra parameter “environment”
Environments remain on our roadmap, though it will still be some time before we get to them. The goal is to allow multiple environments per project, with names shared across environments by default while values can differ.
Environments per project are an essential feature. Without it, we’re forced to create a separate project for each real-world environment. This makes bws rather cumbersome in a real application.
I’m actually struggling to see how bws can be used effectively without support for environments on anything but the simplest, most basic systems. If you have even 2 developers, a staging environment, and a production environment, managing and syncing the environments with bws is much more difficult and error-prone than just using .env files and a build script.
Larger clouds like GCP don’t have environment-specific secrets management but that’s because they have a lot of additional supporting infrastructure that helps scaffold and automate them.
Direct competitors like Doppler do have environments per project because they recognize the necessity. It’s a core feature, not a nice-to-have.
Please prioritize this feature. I’m very sad to say that bws is, unfortunately, next to useless without it.
One option here is to use the Varlock bitwarden plugin
You could then have multiple .env files which contain references to individual bitwarden secrets. Lots of options on how you compose values together… Plus you get validation, type safety, and extra security guardrails.