Secrets Management: API Keys and Encryption Keys

The full executive answer

Secrets live in exactly one place: encrypted environment variables in the deployment platform (Vercel), injected at runtime into server-side code only. The codebase enforces a naming firewall — anything prefixed NEXT_PUBLIC_ is deliberately public and shippable to browsers; everything else is server-only and structurally unavailable to client code. Every new secret must be declared in a template file (.env.example) with a placeholder, so the inventory of what secrets exist is itself version-controlled and reviewable, while the values never are.

On "how do you know one hasn't leaked": we don't rely on knowing — we scan. Gitleaks runs in the Security CI workflow against every push, pattern-matching for credentials across the repository and its history. Our own logging layer masks secrets and personal data before anything is written, so a leak via log files is defended too. And for the customer-facing surface: API keys we issue to customers are stored only as salted scrypt hashes with timing-safe comparison — a database breach yields no usable keys — and webhook secrets support rotation with a grace window so customers can rotate without downtime.

The deepest layer is envelope encryption for sensitive stored fields: data is encrypted with AES-GCM under per-write data keys, which are themselves wrapped by a master key that never leaves AWS KMS — Amazon's hardware-backed key service. Plaintext key material never touches disk. Honest maturity note: we don't yet run a dedicated secrets-manager product with automatic scheduled rotation for our own operational secrets; rotation is manual-but-fast today, and scheduled rotation policy is written into the SOC 2 readiness workplan for Q4 2026.