Where Are You Storing Your API Keys? (And Why Slack Isn't It)

Be honest for a second.

Where are your API keys right now?

Not the answer you'd write in a security audit. The real answer.

• Pinned message in your team's #dev-private Slack channel?
• A .env file someone scp'd from a colleague's laptop last summer?
• That one Notion page titled "secrets — don't share"?
• A shared 1Password vault that hasn't been audited since 2023?
• An email thread from when the newest hire was onboarded?

If even one of those gave you a tiny twinge of "yeah… that's where mine are," keep reading. There's a pattern across dev teams that's worth naming, and there are tools that fix it without costing you a year of engineering or a four-figure annual bill.

The 30-second pattern almost every startup hits

Talk to any startup CTO who's onboarded more than five engineers and the story is the same.

A lead dev quits. No drama, they just leave. And suddenly:

• Half the team's API keys lived in that person's head
• The other half are spread across DMs and .env files on four laptops
• Nobody knows which OpenAI key is charging which project
• Someone shipped a feature using a Stripe test key by accident because they copied the wrong line from a screenshot

Cue four days of auditing keys, rotating secrets, and quietly hoping nothing leaks before rotation completes.

The fix is obvious in hindsight. Treat API keys like the production assets they are. Don't share them in chat. Don't email them. Don't put them in a Notion page.

But here's the question nobody answers honestly: where, then?

How bad is "keys in random places" actually?

Two stats are enough.

• 31% of breaches over the past decade involved stolen credentials — Verizon 2024 Data Breach Investigations Report
• 23+ million secrets exposed in public GitHub commits in 2023 alone — GitGuardian's State of Secrets Sprawl

The pattern: it's almost never a James Bond villain. It's a .env file accidentally committed to a public repo. A Slack export shared with a contractor. A laptop left on a train. A junior dev who pushed a hotfix in a panic and forgot to add .env to .gitignore.

The tools to prevent this all exist. They've existed for a decade. So why do most teams still have keys in Slack?

Because the existing tools are either expensive, overengineered, or both.

The honest landscape, ranked by what dev teams actually feel

Let's walk through the real options. No marketing fluff.

1. HashiCorp Vault

The "real" answer that everyone respects and nobody on a 5-person team actually deploys.

Vault is genuinely a great tool, but it's a tool for operations people who do nothing but security. Not for a frontend dev who just needs to share the staging Stripe key with the new backend hire.

2. AWS Secrets Manager

$0.40 per secret per month. Plus API calls.

Let that sink in.

Fifty keys across dev / staging / prod for a dozen services — and let's be honest, you have at least that many — is $240/year minimum, before request charges. You're also welded to AWS. If your team is on Vercel, Fly, Render, or Cloudflare Workers, congratulations: you're calling a cross-cloud API every time you need to read your own credentials.

And the UI? IAM policies. Eight pages of documentation to grant one engineer read access to one secret. Bring snacks.

3. 1Password / Bitwarden Teams

Honestly, decent. Real encryption, real teams, real UX.

But they're built for passwords, not API keys. There's no first-class concept of "this is the staging Stripe secret for the payments project." It's folders, items, custom fields. You can make it work. People do. It feels like using a hammer to drive a screw — it sort of goes in, but you can tell something's wrong.

Also: $7–$9 per user per month. A 10-person team is $70–$90/month. That's $840–$1,080 a year, every year, forever, for a tool that wasn't designed for the job.

4. The default: Slack, email, .env files

• Zero cost
• Zero encryption at rest
• Zero access control — if Bob can see the channel, Bob can see every key forever, even after he leaves
• Zero audit trail. "Who used that key last and when?" "Uh."

Pretty much the highest-risk path on this list, and the most popular one in the wild. Be honest: this is what your team is using.

What "good" actually looks like (in plain English)

If you sat down and wrote out what a sane API-key sharing tool should do, the list looks something like this:

1. Encrypt at rest. Not "we use TLS." TLS is for the network. The actual blob in the database is ciphertext, and the encryption key isn't in the same place as the data.
2. Per-project, per-environment organization. "Payments-staging" and "Payments-production" are two different things. Stop treating them the same.
3. Role-based access. Read, write, admin. The intern needs read on one project, not the keys to the kingdom.
4. Read-only members should not see plaintext. Underrated. If you give someone "read" access, the value should be ••••••••••••. They can see the key exists. They can't copy it. The server doesn't even send the real value.
5. An audit log. Who looked at what, when. No exceptions. This is what saves you when someone leaks a key — you can prove rotation and trace blast radius.
6. Team invitations that can't be hijacked. If you send "you've been added to the team" via email, and someone forwards that email, the recipient should NOT auto-join the org. Most invitation systems get this wrong.
7. Cheap or free for small teams. A 4-person startup should not be paying $300/year to not put keys in Slack.

Almost no commercial tool ticks all seven.

The tool that's getting traction in 2026: KeyVault

A free option that's been showing up in dev forums lately is KeyVault (apisharing.vercel.app). Worth a closer look because it's the first thing in this category that's actually built for small teams.

What it does, in one paragraph

You sign up and you're the boss of a fresh organization (it creates one automatically). You make a project "payments-production." You add an API key to it. It's encrypted with Fernet (AES-128-CBC + HMAC-SHA256). You invite a teammate by email. You give them read, write, or admin access per project. Read-only members see masked values. Every action is logged.

That's the product. No HCL, no IAM, no $0.40 per secret per month, no "talk to sales."

The boring details that matter (and that competitors get wrong)

A few things to highlight because they're rare in this space:

• Read-only really means read-only. The masking happens on the server, not in the browser. If you give a teammate read access, the API response sends •••••••••••• with a masked: true flag. The actual ciphertext never leaves the database for that role. You can't right-click → Inspect → see the secret.
• Invitation links can't be replayed against existing accounts. If your email already has a KeyVault account, accepting an invitation requires you to be signed in with that email first. The token alone doesn't grant access. (Many invitation systems are exploitable here.)
• Tenant isolation enforced in SQL, not in app code. Every query has AND organization_id = %s baked in. A bug in a route handler can't accidentally leak another org's data the SQL itself refuses to return rows.
• Login is constant-time. A dummy bcrypt comparison runs even when the email doesn't exist, so an attacker can't probe "is this email registered?" by timing the response.
• Lockout is per (email, source-IP). Lock by email alone and any attacker can pre-lock arbitrary accounts as a denial-of-service. Per-IP keeps the legit user working from their own network.

A full technical breakdown lives at apisharing.vercel.app/llms-full.txt. It doubles as a public transparency report on how the system is built.

Pricing, plain

• Free: 1 project. Unlimited keys, unlimited team members, all the security features. Forever. No card required.
• Pro — $10/month for the whole org. Unlimited projects. That's the only difference.

Compare to AWS Secrets Manager at ~$240/year for the same number of secrets. KeyVault Pro is $120/year flat, for the entire team. The free tier is enough for a side project or a 2-person team that just wants to stop sharing the OpenAI key in Slack.

"Can I trust some new tool with my keys?"

Fair question. The honest answers:

1. Don't trust anyone blindly. Look at what they do, not what they say. The Fernet scheme is published. The masking behavior described above is testable make a read member and watch the API response. The audit log is queryable. The tenant isolation is in the SQL.
2. The encryption key isn't theirs. In production, KeyVault refuses to start without an explicit ENCRYPTION_KEY environment variable. The server-side admin can't dump plaintext keys without it.
3. The tradeoff is honest. Self-host Vault if there's time and a team for it. Use AWS Secrets Manager if the whole stack is AWS and budget isn't a factor. Use KeyVault if the team is small, tired of Slack, and doesn't want to spend a quarter setting up Vault.

The only thing worse than overpaying for security is not having it at all.

TL;DR — pick your fit

Try the cheapest option first

The honest move: spend 30 seconds at apisharing.vercel.app/signup before committing to anything more expensive. Free tier is enough to migrate one project off Slack today. If the team grows, $10/month covers everyone forever.

The worst-case outcome is finding out it's not for you — total time invested, two minutes.

The best case: it's the last time you ever paste an API key into Slack.

---

Found this useful? Drop a 💜 or share it with the teammate who keeps pasting prod keys into the wrong channel.

About the Author

I am a freelance AI engineer. I build AI agents, RAG systems, and AI tools for real businesses. I have shipped more than 20 AI systems across 7 countries, and I finished every single project I started.

I am open for AI consulting, RAG work, AI agent work, and LLM app work. Most first versions are ready in 2 to 4 weeks.

• Portfolio: muazashraf.org/portfolio
• Case studies: muazashraf.org/case-studies
• Hire me: muazashraf.org/contact

If this helped you, follow me here. I share simple lessons from real AI work.