Secrets management is the practice of storing, distributing, rotating, and auditing sensitive credentials — API keys, database passwords.
Secrets management is how your application accesses sensitive credentials — database connection strings, third-party API keys, JWT signing keys, TLS certificates — without those secrets living in code, config files, or engineers' laptops. The alternative — .env files checked into git, credentials pasted in Slack, one engineer with 'the AWS root key' in their password manager — is how most early-stage security incidents happen. Good secrets management is boring infrastructure that prevents dramatic incidents.
(1) .env files, sometimes accidentally committed. Where most projects start. Fine for local dev, dangerous for anything else. (2) Platform environment variables — Vercel, Netlify, Heroku, Render inject secrets into deploys via a dashboard. Adequate for small apps with a handful of secrets and few engineers. (3) Dedicated secrets manager — AWS Secrets Manager, GCP Secret Manager, Doppler, Infisical — centralized storage with versioning, access control, and audit logs. Correct answer for most SaaS companies. (4) Vault-based (HashiCorp Vault, AWS KMS-envelope encryption) with dynamic credentials — secrets are generated per-request and expire after minutes. Overkill until you're at genuine scale or in a regulated industry.
Storing secrets is easy; rotating them without downtime is where implementations fail. Requirements for painless rotation: applications must read secrets at request time (or on a short cache), not just at boot; multiple valid credentials must be accepted simultaneously during rotation (old + new); rotation must be automated because manual quarterly rotation always gets skipped. Long-lived static credentials that everyone knows are used somewhere are the most common source of 'we can't rotate that, it might break something.' The fix is architectural: read from a secrets manager, not from an env var baked into the container image.
Developers still need to run the app locally, which requires access to some form of credentials. Bad approach: everyone copies production secrets into a local .env. Good approach: separate dev credentials for a shared dev environment, distributed via the secrets manager and pulled into each developer's environment via CLI. Doppler, 1Password's secrets automation, and Infisical all support this. Nobody should ever need to know the production database password; production access flows through a bastion or a temporary credential mechanism.
It will happen — someone pastes a key in Slack, a laptop is stolen, a repo is accidentally made public. The response playbook: (1) rotate the secret immediately, not after investigating; the leaked credential is now hostile. (2) audit access logs for anomalous usage. (3) determine blast radius — what could someone do with this credential. (4) file an incident, run a postmortem, tighten the process that allowed the leak. Detection: git-secrets or gitleaks pre-commit hooks, GitHub secret scanning (free), and cloud-provider anomaly detection. Assume every static credential will leak eventually and design for cheap rotation.
Each service should have its own credential with the minimum permissions it needs. Shared credentials — 'the app database user' that all services use — mean any compromised service compromises everything. Per-service, per-environment IAM roles or scoped credentials, generated automatically, are the modern standard. This costs some setup time and prevents the 'root API key was leaked and the attacker had access to everything' incident class.
Investor directory · Fundraising library · Articles A–Z · Company funding database