Vaultlier

Security

How Vaultlier keeps secret values sealed — from your machine, through the wire, to disk at rest.

The core guarantee

Secret values are resolved in memory and never written to disk, logs, or environment files by Vaultlier. The files the CLI generates contain metadata only.

Secrets never touch disk

  • The runtime SDK fetches values over HTTPS and holds them in memory for the client's lifetime. Nothing is persisted.
  • vaultlier.json / vaultlier.config.json and lib/vaultlier.ts contain metadata only — key names, types, and scopes — never values or keys.
  • Error objects expose only a stable code, a safe message, and a request id. They never carry the API key, headers, or decrypted values.

Encryption at rest

Secret values are encrypted with a per-project key before storage. Each write produces a new immutable, encrypted version, so history is preserved and rotations are auditable. The database stores ciphertext, not plaintext.

Credential handling

  • API keys (vlt_live_…) are stored as a SHA-256 hash plus a display prefix. The raw key is shown once and never retrievable.
  • Account tokens (vlt_acct_…) from login are stored per-user in ~/.vaultlier/auth.json with owner-only permissions — outside any repository.
  • The CLI masks keys in all output (e.g. config get, whoami, the dev UI).
  • The set command validates key names and scopes locally before any value leaves your machine.

Trust boundaries

  • Account tokens authorize listing and creating projects only — they cannot read or write secrets.
  • API keys are scoped to one project and bounded by their role (viewer reads; member writes).
  • The device-login flow requires a signed-in user to approve each CLI session in the browser; the code in the terminal must match the code shown on the page.
  • The dev UI binds to loopback and only ever surfaces dev-environment values — staging and prod stay sealed.

Production checklist

  • Set VAULTLIER_API_KEYin your platform's secret store — never in source control.
  • Use a viewer-role key for runtime reads; reserve member keys for CI writes.
  • Add an IP allowlist and expiry to keys where practical.
  • Revoke unused API keys and CLI device sessions from the portal.
  • Keep .vaultlier/ (the local credential cache) out of version control.

Related: API Keys for roles and rotation, and the CLI reference for output controls.