An easier and more secure way to work with secrets during local development. It’s open source, cloud/vault agnostic, and doesn’t require a single line of code change to use. I call it RunSecret.
RunSecret is a CLI that replaces your static secrets with “secret references” in your ENV VARs (or .env files). These references are then replaced when your application starts up by reaching out to your secret vault of choice - making your .env safe to share across your whole team and removing a slew of gotchas when you use git ignored env files. Even better RunSecret redacts any instance of these secrets from your application output, reducing your chances for accidental leaks.
The approach is inspired by the 1password CLI, but built for the rest of us. I’ve got AWS Secrets Manager support pretty well baked, but the goal is to support all major secret vaults within the next couple of months (Azure KeyVault is already in progress).
Thanks for checking it out! The pain point for me has largely been during local development, especially in a team setting when secrets change or people onboard or roll off and those manually managed .env files get unwieldy.
Gitlab Secrets looks cool, but that hits at another reason I think RunSecret is valuable even for CI - we don’t use GitLab at my day job so it’s not an option for me! I think GitLab and 1password have interesting proprietary solutions that definitely have inspired RunSecret, but I’d love to see an open source, universal solution here - which I’m hoping RunSecret can be!
The disadvantage to GitLab is to get the feature mentioned is you need to pay for the premium version. We host it ourselves and looking to buy the Enterprise version to get us the vault integrations (specifically AKV)
Ahh, yup! The RunSecret CLI is completely free and open source.
Azure KeyVault support is in progress and should land soon. I will notate it in the release changelog once it’s ready, but I’m also happy to reply here or let you know another way if you are interested!
Yea that is a hard problem to solve. Right now RunSecret depends on the host system (your laptop, CI runner, or application container) having access to the secret vault(s) of choice that you reference. This can be through ENV VARS, OIDC, or IAM roles (in some cases) but currently there is no HSM support.
An easier and more secure way to work with secrets during local development. It’s open source, cloud/vault agnostic, and doesn’t require a single line of code change to use. I call it RunSecret.
RunSecret is a CLI that replaces your static secrets with “secret references” in your ENV VARs (or .env files). These references are then replaced when your application starts up by reaching out to your secret vault of choice - making your .env safe to share across your whole team and removing a slew of gotchas when you use git ignored env files. Even better RunSecret redacts any instance of these secrets from your application output, reducing your chances for accidental leaks.
The approach is inspired by the 1password CLI, but built for the rest of us. I’ve got AWS Secrets Manager support pretty well baked, but the goal is to support all major secret vaults within the next couple of months (Azure KeyVault is already in progress).