Every secret in my homelab has exactly one home: how I run a self-hosted secrets manager, and the traps that bit me

Description and use

The article explains moving to a single secrets manager in a homelab, storing all secrets in Infisical and accessing them via machine identities. It introduces a resolver layer, a bootstrap secret, and hash‑based verification to simplify rotation and improve security.

Problem

Secrets were scattered across compose files, env files, and backups, making rotation hard and stale copies likely.

Outcome

Secrets are now centralized, auditable, and rotatable from one place; services run without stale credentials and with scoped access.

Workflow

• 1. Store all secrets in Infisical (or similar).
• 2. Create a machine identity per service with scoped access.
• 3. Deploy a tiny resolver that resolves env → vault → default.
• 4. Keep a single bootstrap credential in a tightly-permissioned env file per host.
• 5. Use SHA‑256 fingerprints to verify secrets without printing values.
• 6. Rotate secrets by updating only the vault entry.
• 7. Revoke machine identities when retiring services.
• 8. Ensure automated identities are read‑only.

Evidence

The test I use to know it's working is brutal and simple: can I rotate any password in the estate by changing it in exactly one place?

Source

A service read its secrets from an env_file in compose, and it restart-looped on boot with an authentication failure — using a password I could see, plainly correct, sitting right there in the file.

Source