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_URLThe grace window
vaultic secrets rotate DB_URL --grace 1hFor the grace window, the previous value stays fetchable via:
vaultic secrets get DB_URL --previousOmit --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