What is VaultTerm

VaultTerm is two products that belong together: a credential vault for every kind of secret, and an audited access broker that connects you to hosts using those secrets without ever handing them to the connecting device. A password manager stores secrets; VaultTerm also brokers the access those secrets unlock, and records every step.

The model, stated plainly

VaultTerm is an audited access broker — not zero-knowledge, and we say so rather than market a guarantee we can’t keep. The server decrypts a secret in memory only for a specific authorized, audited action, then discards it. Concretely:

• Envelope encryption throughout. Every secret is sealed with a per-record data key that is itself wrapped by a higher key. Keys are never stored beside the data they protect.
• No plaintext at rest. Decryption happens in memory for an authorized action only.
• Every access is on the record. Reads and brokered sessions land in a tamper-evident audit trail.

A strict zero-knowledge design would rule out the things teams actually need — brokering an SSH session, injecting a credential just-in-time, scanning command output for a leaked key. All of those need the plaintext, in memory, at the moment of use. We chose the broker, and we make it accountable.

What you can do with it

• Store logins, SSH keys, API keys, env files, TOTP seeds, payment cards and secure notes in a typed, organised vault — see Credential Vault.
• Connect to hosts through a brokered, fully audited SSH/terminal session with no standing keys on laptops — see Terminal & SSH.
• Share access across a team with roles and just-in-time elevation — see Teams & Organizations.
• Assist with AI that defaults to your own network — see Privacy-First AI.
• Audit everything through a tamper-evident trail — see Security & Architecture.

How a request flows

1. Store — a secret goes into the vault under envelope encryption, typed and organised.
2. Request — when you need a host or a secret, you (or the broker) request access, scoped and just-in-time where it matters.
3. Broker — the server decrypts in memory for that authorized session only, injecting access without leaving standing credentials behind.
4. Audit — every read and session lands in a tamper-evident trail, so access stays attributable.

Where to go next

• New to VaultTerm? Read Core concepts, then Store your first secret.
• Deciding how to run it? See SaaS vs self-hosted.
• Running it yourself? Start at Self-hosting overview.
• Building on it? Start at API overview.