What Is a Secrets Manager (and Do You Need One)?

Quick answer
A secrets manager is a service that stores credentials encrypted, controls who can read them, records access, and often issues short-lived credentials instead of storing them.
Its main advantage over an environment file is not encryption but access control and audit: each consumer gets only the secrets it needs, and every read is logged.
Dynamic secrets — database credentials generated on request with a short TTL — remove long-lived passwords entirely.
A small project can start with the platform’s built-in secret store; a separate manager earns its cost when multiple environments, teams, or systems need the same controls.
A secrets manager does not fix a secret baked into a container image or printed in a log; it only manages secrets that are requested at runtime.

What does a secrets manager do?

It stores secrets in an encrypted backend and exposes them through an authenticated API. Consumers — an app, a CI job, an operator — authenticate to the manager, request a specific path, and receive the value if policy allows. The manager records the request, so there is a trail of who read what and when.

Beyond storage, many managers generate credentials on demand: a database role that issues a username and password valid for an hour, a cloud token scoped to a role, a certificate with a short lifetime. That turns a static-secret problem into a lifecycle problem the platform can automate.

How is it better than an environment file?

An environment file is a plaintext copy of every secret the app uses, readable by anyone with filesystem access and copied into backups, images, and debugging sessions. A secrets manager gives each consumer a narrow path and an identity to authenticate with, so a compromised service cannot read the whole set.

The audit difference matters during an incident. With a file, you cannot answer whether the credential was read by an unexpected process. With a manager, the read log answers it directly, provided the consumer authenticates with its own identity rather than a shared admin token.

# The app authenticates as itself, then reads only its own path.
export DB_PASSWORD=$(vault kv get -field=password secret/app/prod/db)

# Better: ask for a short-lived database credential instead of a stored one.
vault read database/creds/app-prod
# -> username, password, lease_duration; expires without manual rotation.

Do you need a dedicated secrets manager?

Not always. Cloud platforms provide a managed secret store, CI platforms provide scoped secrets, and Kubernetes provides secret objects, though those are only base64-encoded and need encryption at rest plus strict RBAC to be meaningful. For a single app on one platform, the built-in store is usually enough.

A dedicated manager becomes worthwhile when secrets must be shared across platforms, when dynamic credentials are required, when audit evidence is needed, or when the number of secrets and consumers makes per-app configuration unmanageable. Adopting one early adds an availability dependency: if the manager is down, the app cannot start unless it caches credentials.

What does it not solve?

It does not remove secrets from a container image that baked them in, from a log line that printed them, or from a repository that committed them. Those are copies outside its control. It also does not fix over-broad permissions: a manager that lets every service read every path is an encrypted shared folder.

And it does not decide rotation. Some managers can rotate certain credential types automatically; others only store. The policy, the owner, and the schedule are still yours, and a manager with no rotation policy mainly improves the storage location.

Where this bites vibecoders
A generated app reads process.env and expects the platform to provide values, which is fine. The problem appears when the same .env file is committed for local development, then copied to the server because it already works. Moving the production values into the platform’s secret store, with a distinct identity per environment, is a contained change with a large reduction in exposure.

Where AI coding assistants get this wrong

Committing a .env file as a template with real values in it.
Giving every service the same manager token with read access to all paths.
Storing secrets in Kubernetes Secret objects without encryption at rest or RBAC.
Assuming a secrets manager rotates credentials automatically when it only stores them.
Fetching secrets at build time and baking them into the image.
Caching secrets indefinitely in the app, so revocation has no effect.

Checklist

List every secret the app needs and who consumes it.
Use the platform’s built-in store for a single-environment app.
Give each workload its own identity and path.
Prefer dynamic, short-lived credentials where supported.
Fetch at runtime, not at build time.
Define rotation ownership and a fallback if the manager is unavailable.

FAQ

Is a secrets manager the same as a password manager?

No. A password manager is designed for people to retrieve credentials interactively. A secrets manager is designed for applications to authenticate and retrieve credentials programmatically, with machine identity, policy, audit, and often dynamic issuance. The threat models and interfaces differ.

Are Kubernetes Secrets a secrets manager?

They are a secret store, not a full manager. Values are base64-encoded rather than encrypted by default, access is controlled by RBAC, and anyone who can read the object or the etcd backup can read the value. With encryption at rest and tight RBAC they can be adequate, but they do not provide dynamic credentials or a strong audit trail.

What happens if the secrets manager goes down?

An app that fetches on every request fails; an app that caches with a bounded TTL keeps running until the cache expires. Design for a degraded mode: cache with a short TTL, avoid a hard dependency at startup, and test the failure path. Availability is part of the secrets architecture.

Should I use one for a side project?

Usually the hosting platform’s secret store is enough. A dedicated manager adds a service to operate and a dependency to monitor. Adopt one when you have multiple environments, multiple consumers, or an audit requirement that the platform store cannot meet.