Core concepts

• Server vs. CLI. The keephippo binary is both. keephippo server runs the long-lived process that holds your encrypted secrets; every other command is a thin client that talks to it over HTTP.
• Seal / unseal. On disk, everything is encrypted by a barrier key that is itself protected by the root key. A fresh server starts sealed (the root key is not in memory). You initialize once to generate unseal key shares and a root token, then unseal by supplying the shares. Dev mode auto-unseals.
• Tokens. Every request carries a token (the X-Vault-Token header). The root token can do anything; you create scoped tokens for day-to-day use.
• Mounts & paths. Secrets engines and auth methods are mounted at a path (e.g. secret/, transit/, auth/userpass/). A request path like secret/myapp/db routes to the engine at secret/.
• Policies. ACL policies written in HCL grant capabilities (read, create, update, delete, list, sudo) on path patterns. Tokens carry policies; the default deny means "no policy, no access".
• Environment. The CLI reads KEEPHIPPO_ADDR then VAULT_ADDR for the server address, and KEEPHIPPO_TOKEN then VAULT_TOKEN then the token stored by keephippo login (~/.keephippo-token) for the token.