Stop Emailing .env Files: A Practical Guide to Encrypted Vaults

The four most common leak paths, in order of real-world frequency:

• Slack DMs — onboarding, quick handoffs, 'can you try this real quick'. The search index keeps them forever. • Notion / Confluence pages — someone made a 'dev setup' page in 2022 with production values, nobody remembers it's there. • Plaintext Postman collections — shared via workspace, including live tokens in the Authorization header. • Committed .env files — `git rm` removes it from HEAD, but it lives in history until you rewrite.

None of these involve a malicious insider. They're all ordinary workflow shortcuts that become permanent artifacts.

Before picking a tool, name the threats:

• A junior who leaves the company and still has their Slack export on their laptop. • A contractor who had one-day access to your Notion workspace and kept a Markdown backup. • A compromised developer laptop where an infostealer slurped any plaintext secret on disk. • A Github token that was accidentally included in a public gist three years ago.

Each of these is handled the same way by encrypted vaults: the secret is never at rest in plaintext anywhere, so an exfiltrated ciphertext is worthless without the vault key. You're not defending against an APT — you're defending against the mundane attack surface of 'stuff we already wrote down in cleartext'.

EnvVault uses Fernet (AES-128-CBC with HMAC-SHA256) for secret encryption. This is not the most exotic cipher suite available, and that's the point. Fernet is standardized, widely audited, and impossible to misuse in ways that produce insecure output — it enforces authenticated encryption, rejects tampered ciphertext, and bundles a timestamp for rotation.

Critically, the vault uses a dedicated `ENVVAULT_ENCRYPTION_KEY`, not the application's JWT signing secret. Sharing these is a common mistake: if an attacker forges a JWT, they also decrypt every secret. Keeping them separate means a key compromise in one system doesn't automatically cascade. The encryption key lives in a single environment variable, is never logged, and rotates independently of everything else.

One vault for 'everything' is the wrong shape. A production secret has fundamentally different access needs than a development secret.

Structure your vaults as:

• Production — only read by senior on-call, audit log on every access, no bulk export. • Staging — read by any engineer, write by lead only. Same shape as prod but with different values. • Development — everyone can read and write. Useful for third-party sandbox tokens that are safe to share.

Separation isn't just about permissions — it's about blast radius. When a development credential leaks, production is untouched. This structure also gives you real audit data: 'who opened production in the last 30 days?' is a single query.

The single most important operational capability a vault needs is key rotation that doesn't break the running application. The procedure:

1. Generate a new encryption key. Add it to the vault as the `current` key. 2. Keep the old key as `legacy` — decryption tries `current` first, falls back to `legacy`. 3. Run a re-encryption pass: for each secret, decrypt with `legacy`, encrypt with `current`, write. 4. Once re-encryption is complete, remove `legacy`. The old key is dead.

With a dual-key window, no request ever fails because of a rotation. Rotate quarterly; rotate immediately if a key holder leaves.