We run a self-hosted password manager for every credential used across the system. Not a "usually" — new credentials get saved immediately when they're created, not left sitting in a file or a chat transcript.
The credential store is deliberately kept independent of the main fleet's own infrastructure, so credentials stay reachable even if other parts of the system are having an outage — the whole point of a password manager is that it still works when everything else doesn't. Don't "fix" this by moving it somewhere more convenient without recognizing the availability trade-off you'd be giving up.
Admin access uses a pre-hashed credential as its own secret, never a plaintext token.
Credentials are organized by what they belong to, not dumped into one catch-all folder — shared/fleet-wide secrets in one place, product-specific credentials in another. Keep new credentials in the folder that actually matches what they're for.
The CLI tooling can drive the password manager programmatically, but it needs an unlocked session. The safe pattern: have whoever's driving unlock it themselves in their own terminal — their master password never leaves their machine — and hand over just the resulting session key. Lock it again once the work using it is done.
The login endpoint here returns a different HTTP status on a bad login than the generic pattern most standard security-scenario rules watch for. A dedicated local rule exists specifically to catch brute-force attempts against it. See Security Tooling.