Vaultic

Secrets rotation

Rotate a credential with a grace window instead of a hard cutover, with an always-on audit trail.

Rotating a secret means replacing its value while keeping the old one briefly fetchable — so in-flight requests using the previous credential don't fail mid-rotation.

vaultic secrets rotate DB_URL

The grace window

vaultic secrets rotate DB_URL --grace 1h

For the grace window, the previous value stays fetchable via:

vaultic secrets get DB_URL --previous

Omit --grace and the previous value stays fetchable indefinitely. A secret.rotated webhook always fires on rotation, regardless of the grace window, so downstream automation can react either way.

Provider-assisted rotation

For credentials Vaultic knows how to rotate at the source — not just swap a value — pass --provider:

vaultic secrets rotate DB_URL --provider postgres --admin-conn-string "$DB_ADMIN_URL"

The rotation itself runs server-side: the CLI never connects directly to the target system. Only the Vaultic server needs network access and credentials to reach it, and the rotation is authorized and audit-logged the same way any other secret write is.

Rotation providers

How server-side rotation execution works, and every provider (postgres, mysql, redis, aws-iam, generic-webhook) in detail.

Manual rotation, without a provider

Pass a new value directly, or read one from stdin — the grace window and webhook behave identically whether or not a provider computed the value:

vaultic secrets rotate STRIPE_KEY sk_live_new
echo "$NEW_VALUE" | vaultic secrets rotate STRIPE_KEY -

Staying ahead of rotation

Set a reminder cadence when you create or update a secret, and both vaultic status and the web app's Secrets Health dashboard will flag it once it's due:

vaultic secrets set STRIPE_KEY --remind-every 30d

On this page