The Incident
It’s the classic startup nightmare: a .env file gets committed by accident, a scraper bot picks it up in under 30 seconds, and you wake up to depleted API credits and surprise cloud bills.
After a credential leak burned our DeepSeek credits and threatened our AWS account, I realized that telling developers to "be more careful" is a broken security model. The real architectural fix is simple: Developers and client apps should never possess real production secrets in the first place.
Introducing Llavero 🔑
To solve this, I built Llavero (Keyring in Spanish), an open-source Credential-Aware Reverse Proxy / Secret Injection Gateway built with Node.js 24, TypeScript, Fastify, and SQLite.
Application
│ Authorization: Bearer llv_dev_xxx
▼
Llavero ── validate token ── policy (deny-by-default)
│── decrypt credential in-memory (AES-256-GCM) ── apply auth driver
▼
External API (OpenAI, Stripe, AWS...)
Architecture Highlights
In-Memory Decryption: Secrets are encrypted at rest using AES-256-GCM. The master key lives strictly in memory (LLAVERO_MASTER_KEY).
Deny-by-Default Policies: Clients must be explicitly granted permission for specific services, paths, and HTTP methods.
Pluggable Auth Drivers: Handles complex authentication mechanisms like OAuth2 refresh token caching and AWS SigV4 request signing automatically.
Streaming & WebSocket Support: Native proxying for SSE (Server-Sent Events) and WS handshakes without buffering payload.
Log Redaction & SSRF Guard: Strict origin validation and automatic redaction of sensitive headers in Pino logs.
Join the Project!
Llavero is fully open-source under the MIT license. I’m actively looking for feedback, security reviews, and contributions:
GitHub: Go to REPO
Needs: Security auditing, additional auth drivers, and HA storage adapters.
Let me know what you think in the comments below!
Top comments (0)