Why Muppy Vault¶
The problem¶
Muppy acts on your infrastructure, so it stores the credentials that let it act: SSH
private keys, git and API tokens, database passwords, kubeconfigs — around thirty secret
fields in all. Without encryption, every one of them sits in clear in the database.
Which means every copy of the database is a copy of your keys: a pg_dump, a nightly
backup, a replica, a decommissioned disk, an exported VM image. Whoever holds any of
those holds your infrastructure.
Muppy Vault closes exactly that door: a stolen dump, backup, replica or host image becomes worthless. The secrets in it are encrypted, and the one key that opens them is not in the file — it is in your password manager, and nowhere else.
Why not an external secrets manager?¶
The classic answer is to deploy a dedicated secrets server (HashiCorp Vault and its cousins). It works — for teams staffed to run it. It is also a new moving part: one more service to install, upgrade, monitor, back up and secure, one more thing whose outage stops everything, and one more place your disaster-recovery plan has to cover besides your database backups.
Muppy Vault takes the opposite bet:
- No new infrastructure. Encryption lives inside Muppy. The only companion is
mpy-masterkeyd, a tiny key-holder process that stores nothing — no state, no files to back up. If it dies, you restart it and re-enter the key. Your existing database backups keep containing everything you need to recover (except the master key, which is the point). - The master key is never stored — anywhere. Not on disk, not in the database, not in a config file. It lives in your password manager, and Muppy asks for it when it is needed (after a reboot, for instance). Having to re-enter a key now and then is not a limitation: it is the security property. There is no file an attacker can find. On this axis the guarantee is the same as HashiCorp Vault's default (Shamir) seal — the key exists only in memory while running and in human hands between — with one deliberate simplification: a single key in a single password-manager entry, instead of key shares split across several officers. And unlike auto-unseal setups, there is no stored path to the key (no cloud KMS the machine can reach with credentials it holds): no capture of the machine, its image or its credentials can lift the seal without a human.
- The ergonomics of your existing tool. Your secrets stay where you work: you enter an SSH key or a token on the record that uses it, and read it back — securely, behind the reveal gate — on that same screen. No second application to open, no copy-pasting secrets between a vault UI and Muppy. The vault's own operations (activation, key entry, rotation, health checks) are guided screens in the same interface, with their trail in the chatter. No new CLI to learn, no policies file to write.
- Any addon can use it — including yours. A model declares a field as secret with a single declaration, and that field gains encryption at rest, the reveal gate and membership in the migration tooling. Partner addons get the same protection as Muppy's own, for one line.
An optional feature¶
Muppy Vault is opt-in and semi-autonomous: Muppy runs identically with or without it. Until you activate encryption, nothing changes. When you do, a trial mode — the dry-run of the migration — lets you run encrypted while keeping the plaintext as a safety net, and leave at any time — the point of no return is a deliberate, separate step, taken only once you have certified the vault against your own data.
Where to go next¶
| You want to… | Read |
|---|---|
| Understand what is protected, and from what | What It Protects |
| Turn encryption on | Activating Encryption |
| Operate it day to day (reboots, rotations) | Day-2 Operations |
| Go to production safely | Trial and Production |
| Understand the "Verify to reveal" button | Revealing Secrets |
| Fix something | Troubleshooting |