VaulticManaging secrets
Creating, reading, updating, and rolling back secrets — from the CLI or the web app's environment matrix.
A secret is a key and a versioned, encrypted value scoped to one environment. Both the CLI and the web app operate on the same underlying data — use whichever fits the moment.
Create and update
vaultic secrets set STRIPE_KEY sk_live_xxxEvery set is a new version; nothing is overwritten in place. Pass - as the value, or omit it
and pipe input in, to read from stdin instead of argv — keeps the secret out of shell history:
cat tls_cert.pem | vaultic secrets set TLS_CERT
echo "$SECRET" | vaultic secrets set STRIPE_KEY -Omitting the value at an interactive terminal instead prompts you for it, terminated by a line
containing only .. Omitting it along with --expires-in/--remind-every/etc. and no piped
input updates just that metadata, without touching the stored value:
vaultic secrets set STRIPE_KEY --expires-in 90d --remind-every 30dSee CLI: secrets reference for the full set of set behaviors.
Read
vaultic secrets list # masked
vaultic secrets list --reveal # real values — audited separately from list/read
vaultic secrets get STRIPE_KEY --revealMasking is the default everywhere a value could otherwise appear on screen or in a log. Revealing is always its own audited event, distinct from a plain list or get.
Visibility: masked, unmasked, restricted
Every secret has a visibility tier, set with --visibility on secrets set or from the
Visibility field in the web app's Add/Edit secret modal:
| Tier | Behavior |
|---|---|
masked (default) | Hidden until revealed, by anyone with read access — today's behavior. |
unmasked | Always shown in plain text in list/get, no --reveal needed. For low-sensitivity values (a port number, a feature flag) where masking just adds friction. |
restricted | Can never be viewed again in the dashboard or CLI once saved — not even a masked placeholder. Only a service token can retrieve the real value, so it still flows into deploys, vaultic run, and integration syncs; it's a human-visibility control, not an access-grant. |
vaultic secrets set SIGNING_KEY --visibility restricted
vaultic secrets set PORT 8080 --visibility unmaskedA restricted secret's value composes into anything that references it too — a masked secret
whose value is ${SIGNING_KEY} is just as unrevealable to a logged-in session as SIGNING_KEY
itself.
Loosening a restricted secret (back to masked/unmasked) requires supplying a new value in
the same secrets set call — there's no way to flip the tier back without proving you know a
value, since the point of restricted is that the old one was never re-displayed to you.
Tightening (e.g. masked → restricted) doesn't need a new value.
Someone who can create a read-scoped service token for an environment can still use that token
to fetch a restricted secret's value out-of-band, even if they're blocked from viewing it
directly. restricted controls the dashboard/CLI-as-a-human surface, not an absolute secrecy
guarantee against anyone who can provision credentials for that environment.
Version history and rollback
vaultic secrets history STRIPE_KEY
vaultic secrets rollback STRIPE_KEY --version 3Every write creates a new, immutable version. Roll back to any prior one, or inspect history from the web app's Secrets tab without leaving the row.
Delete
vaultic secrets delete STRIPE_KEYDeleted secrets go to a 30-day trash, restorable from the web app — nothing is gone immediately.
Personal overrides
Set a value that's visible only to you, on top of the real one:
vaultic secrets override set STRIPE_KEY sk_test_yourlocalkeyOverrides never affect teammates, and service-token reads (export/run, as used by deploys and
CI) never consult them — so a personal override can't accidentally leak into a deploy.
The environment matrix
The web app's Compare view lays out every
key as a row and every environment as a column — the fastest way to spot a key that's missing in
one environment, or see which values are inherited (ref badge) versus overridden locally.
Locked environments
If the target environment is locked,
set and delete don't apply immediately — they queue as a pending change proposal instead. See
Locking & change requests.