Infisical vs 1Password for homelab machine secrets: why I self-host

Description and use

The homelab now has a single, locally‑hosted secrets store that keeps machine secrets secure, reduces duplication, and allows automated rotation and consistent access via CLI or resolver modules. Root key management and permission separation mitigate risk, while human passwords remain in a separate vault.

Problem

Multiple scripts on a homelab agent box stored the same machine secret in different ways, causing authentication failures and no alerting, while a third script rotated its own credential and pushed it to git, leading to inconsistent secret management.

Outcome

The homelab now has a single, locally‑hosted secrets store that keeps machine secrets secure, reduces duplication, and allows automated rotation and consistent access via CLI or resolver modules. Root key management and permission separation mitigate risk, while human passwords remain in a separate vault.

Workflow

• 1. Deploy Infisical as a native package in a Proxmox container, supervised by systemd.
• 2. Configure the ENCRYPTION_KEY environment variable for the root key.
• 3. Create a machine identity with universal‑auth (client ID/secret) for scripts to fetch secrets.
• 4. Use the Infisical CLI (v0.38.0) with --method=universal-auth to obtain a short‑lived token and export secrets via infisical secrets get or infisical run.
• 5. Store the client ID/secret in a locked‑down file on the agent box and update it atomically when rotating credentials.
• 6. Implement a resolver module in Python that caches the login and resolves secrets at call time, raising errors on failure.
• 7. Separate read and write identities: a viewer identity for reads and a dedicated identity for rotation and write operations.
• 8. Delete secrets explicitly with --type=shared when needed.
• 9. Maintain a nightly inventory script that lists secret names and compares hashes to detect duplicates.
• 10. Keep Vaultwarden for human passwords and Infisical for machine secrets, ensuring no cross‑over of master passwords.

Evidence

Two scripts on my agent box both needed the password for my uptime monitor. Each kept its own copy. When I finally tested them side by side, one logged in and saw every monitor, and the other had been failing authentication for who knows how long:

Source

The same afternoon I found a third script that rotated its own machine credential by rewriting its own source file. That file sat in a directory a nightly backup pushed to my git server. So the rotation worked beautifully, and every rotated credential ended up in version control.

Source

My reasons fit on one line: it's hosted locally, I know where the cryptographic keys live, and I can manage all of it from the CLI.

Source

Infisical runs as the official native package, the omnibus build supervised by systemd, inside its own small Proxmox container.

Source

Infisical's model is different. Its security page says secrets are encrypted at rest with AES-256-GCM under a layered key hierarchy: an operator‑supplied root encryption key (passed in as an environment variable) encrypts an internal KMS root key, which in turn encrypts per‑organisation and per‑project data keys.

Source