Show HN: RunSecret – An open source secrets management CLI for developers
runsecret
rsec
Go2025–2025
runsecret / rsec
rsec
RunSecret CLI
2Distinct people
4Mentions
0Explicit recommenders
7GitHub stars
What to know before exploring
What it is
RunSecret CLI
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by day4 dated mentions
Observed mentions: 2025-04-28 21:41:34 UTC to 2025-05-20 12:57:34 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Apr 28 | 2025-04-28 00:00:00 UTC | 2025-04-29 00:00:00 UTC | 1 | 0 | 1 |
| Apr 29 | 2025-04-29 00:00:00 UTC | 2025-04-30 00:00:00 UTC | 0 | 0 | 0 |
| Apr 30 | 2025-04-30 00:00:00 UTC | 2025-05-01 00:00:00 UTC | 2 | 0 | 2 |
| May 1 | 2025-05-01 00:00:00 UTC | 2025-05-02 00:00:00 UTC | 0 | 0 | 0 |
| May 2 | 2025-05-02 00:00:00 UTC | 2025-05-03 00:00:00 UTC | 0 | 0 | 0 |
| May 3 | 2025-05-03 00:00:00 UTC | 2025-05-04 00:00:00 UTC | 0 | 0 | 0 |
| May 4 | 2025-05-04 00:00:00 UTC | 2025-05-05 00:00:00 UTC | 0 | 0 | 0 |
| May 5 | 2025-05-05 00:00:00 UTC | 2025-05-06 00:00:00 UTC | 0 | 0 | 0 |
| May 6 | 2025-05-06 00:00:00 UTC | 2025-05-07 00:00:00 UTC | 0 | 0 | 0 |
| May 7 | 2025-05-07 00:00:00 UTC | 2025-05-08 00:00:00 UTC | 0 | 0 | 0 |
| May 8 | 2025-05-08 00:00:00 UTC | 2025-05-09 00:00:00 UTC | 0 | 0 | 0 |
| May 9 | 2025-05-09 00:00:00 UTC | 2025-05-10 00:00:00 UTC | 0 | 0 | 0 |
| May 10 | 2025-05-10 00:00:00 UTC | 2025-05-11 00:00:00 UTC | 0 | 0 | 0 |
| May 11 | 2025-05-11 00:00:00 UTC | 2025-05-12 00:00:00 UTC | 0 | 0 | 0 |
| May 12 | 2025-05-12 00:00:00 UTC | 2025-05-13 00:00:00 UTC | 0 | 0 | 0 |
| May 13 | 2025-05-13 00:00:00 UTC | 2025-05-14 00:00:00 UTC | 0 | 0 | 0 |
| May 14 | 2025-05-14 00:00:00 UTC | 2025-05-15 00:00:00 UTC | 0 | 0 | 0 |
| May 15 | 2025-05-15 00:00:00 UTC | 2025-05-16 00:00:00 UTC | 0 | 0 | 0 |
| May 16 | 2025-05-16 00:00:00 UTC | 2025-05-17 00:00:00 UTC | 0 | 0 | 0 |
| May 17 | 2025-05-17 00:00:00 UTC | 2025-05-18 00:00:00 UTC | 0 | 0 | 0 |
| May 18 | 2025-05-18 00:00:00 UTC | 2025-05-19 00:00:00 UTC | 0 | 0 | 0 |
| May 19 | 2025-05-19 00:00:00 UTC | 2025-05-20 00:00:00 UTC | 0 | 0 | 0 |
| May 20 | 2025-05-20 00:00:00 UTC | 2025-05-21 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
4 sourcesDEdevenjarvis·May 20, 2025Submission
Hey everyone!
I’m excited to share RunSecret (aka: rsec), an open source CLI I built to make working with secrets during local development easier and more secure.
If your experience is anything like mine, your team probably has secrets they need to use during local development (ex: API Keys, JWT Signing Secrets, DB credentials, etc) and you may have solved that problem with a git-ignored .env file, like many of my past teams have. If this sounds familiar then you may have also experienced my pain of securely bootstrapping secrets for every new team member, accidental commits when the .env file gets renamed to .env_tmp (yes, that actually happened), tripping over rotating secrets on every local machine, and explaining to your security team that everybody who offboards has all those secrets in plaintext on the laptop they just took with the
m. If you’ve felt any of this pain, then you know why I built RunSecret!
The core idea behind RunSecret is based on secret references: URL-like addresses that point to a secret in your team’s vault of choice. These references can be generated by RunSecret and used to replace instances of that secret currently stored in .env files or ENV VARS. When you run any command with RunSecret those references will be loaded and replaced with the real deal - but only during runtime, and only for that command! This means two, pretty-cool things:
1. .env files are safe to commit and share across your team again. This means access to secrets is controlled by your vault, and onboarding, rotation and offboarding access to these secrets is all automated now. (Big plus, your security team is also happier!)
2. If you are already using env vars to pass secrets into your application, you can use RunSecret without changing a single line of code.
RunSecret is built to be vault agnostic, and current supports AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault (with more on the way). I’ve also built in some bells and whistles, like automatic redaction of any referenced secret in your application's stdout/stderr to reduce the chance of leaks. It’s still early days, and there’s a lot more I want to build out for RunSecret, but the core functionality is there and I’d love to start getting feedback from others and their use cases.
If you are interested you can check it out on GitHub here: https://github.com/runsecret/rsec
I’d be remiss if I didn’t credit the original inspiration for RunSecret. If you’ve ever used 1Password’s very well done CLI, `op` , this all probably looks familiar to you. RunSecret was an itch I had to scratch after working on a team that used 1Password as its team vault, and then dealing with withdrawals when I switched to an org that used AWS Secrets Manager instead. For anyone who has or currently uses `op` , and misses that functionality with other secret vaults you work with, RunSecret might be interesting to you!
I hope you enjoy RunSecret, and would love any and all feedback you have to make this better. Thanks for checking out my project!
You may want to do your own Show HN about it, so folks don't have to be "MCP curious" to find out that it exists
That said, given https://github.com/runsecret/rsec#aws-secrets-manager presumably in order to keep AWS credentials off disk one would then have to have this?
"vantage-mcp-server": {
"command": "/opt/homebrew/bin/aws-vault",
"args": [
"exec", "--region=us-east-1", "my-awesome-profile",
"--", "/opt/homebrew/bin/rsec", "run",
"--", "/opt/homebrew/bin/vantage-mcp-server"
],
"env": {"VANTAGE_BEARER_TOKEN": "rsec://012345678912/sm.aws/VantageBearerToken?region=us-east-1"}
}
in contrast to the op binary that is just one level of indirection, since they already handshake with the desktop app for $(op login) purposes
In Show HN: An MCP server for understanding AWS costsThe 1pass CLI is great! However if you aren’t using 1password as your secrets vault, I’m building an open source, vault-agnostic alternative called RunSecret (https://github.com/runsecret/rsec)
In Show HN: An MCP server for understanding AWS costshttps://github.com/runsecret/rsec
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 t
Read the rest
he goal is to support all major secret vaults within the next couple of months (Azure KeyVault is already in progress).