HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
runsecret
rsec
Go2025–2025
runsecret / rsec

rsec

RunSecret CLI

2Distinct people
4Mentions
0Explicit recommenders
7GitHub stars
REPOSITORY AT A GLANCE

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.

0122025-04-28 00:00:00 UTC to 2025-04-29 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsApr 282025-04-29 00:00:00 UTC to 2025-04-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-30 00:00:00 UTC to 2025-05-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-05-01 00:00:00 UTC to 2025-05-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-02 00:00:00 UTC to 2025-05-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-03 00:00:00 UTC to 2025-05-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-04 00:00:00 UTC to 2025-05-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-05 00:00:00 UTC to 2025-05-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-06 00:00:00 UTC to 2025-05-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-07 00:00:00 UTC to 2025-05-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-08 00:00:00 UTC to 2025-05-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-09 00:00:00 UTC to 2025-05-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMay 92025-05-10 00:00:00 UTC to 2025-05-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-11 00:00:00 UTC to 2025-05-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-12 00:00:00 UTC to 2025-05-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-13 00:00:00 UTC to 2025-05-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-14 00:00:00 UTC to 2025-05-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-15 00:00:00 UTC to 2025-05-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-16 00:00:00 UTC to 2025-05-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-17 00:00:00 UTC to 2025-05-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-18 00:00:00 UTC to 2025-05-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-19 00:00:00 UTC to 2025-05-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-20 00:00:00 UTC to 2025-05-21 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsMay 20

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Apr 282025-04-28 00:00:00 UTC2025-04-29 00:00:00 UTC101
Apr 292025-04-29 00:00:00 UTC2025-04-30 00:00:00 UTC000
Apr 302025-04-30 00:00:00 UTC2025-05-01 00:00:00 UTC202
May 12025-05-01 00:00:00 UTC2025-05-02 00:00:00 UTC000
May 22025-05-02 00:00:00 UTC2025-05-03 00:00:00 UTC000
May 32025-05-03 00:00:00 UTC2025-05-04 00:00:00 UTC000
May 42025-05-04 00:00:00 UTC2025-05-05 00:00:00 UTC000
May 52025-05-05 00:00:00 UTC2025-05-06 00:00:00 UTC000
May 62025-05-06 00:00:00 UTC2025-05-07 00:00:00 UTC000
May 72025-05-07 00:00:00 UTC2025-05-08 00:00:00 UTC000
May 82025-05-08 00:00:00 UTC2025-05-09 00:00:00 UTC000
May 92025-05-09 00:00:00 UTC2025-05-10 00:00:00 UTC000
May 102025-05-10 00:00:00 UTC2025-05-11 00:00:00 UTC000
May 112025-05-11 00:00:00 UTC2025-05-12 00:00:00 UTC000
May 122025-05-12 00:00:00 UTC2025-05-13 00:00:00 UTC000
May 132025-05-13 00:00:00 UTC2025-05-14 00:00:00 UTC000
May 142025-05-14 00:00:00 UTC2025-05-15 00:00:00 UTC000
May 152025-05-15 00:00:00 UTC2025-05-16 00:00:00 UTC000
May 162025-05-16 00:00:00 UTC2025-05-17 00:00:00 UTC000
May 172025-05-17 00:00:00 UTC2025-05-18 00:00:00 UTC000
May 182025-05-18 00:00:00 UTC2025-05-19 00:00:00 UTC000
May 192025-05-19 00:00:00 UTC2025-05-20 00:00:00 UTC000
May 202025-05-20 00:00:00 UTC2025-05-21 00:00:00 UTC110

What Hacker News says

4 sources

Show HN: RunSecret – An open source secrets management CLI for developers

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
Read the rest
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!
2 points · Open discussion
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 costs
https://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).
In Ask HN: What are you working on? (April 2025)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.