Secret rotation
Replacing a value with no downtime and no manual work.
Four phases
create → set → test → finish
- create — create the new value in the target system (for example, a second user in PostgreSQL);
- set — apply it where it should take effect;
- test — make sure it works;
- finish — move the
currentlabel so consumers start reading the new value.
The automaton is idempotent: a run resumes from any phase, so a failure midway doesn't leave the system in an undefined state.
Why test cannot be skipped
Rotation without verifying the new value is worse than no rotation: you get
confidence instead of working access. That is why the phase is mandatory,
and a failed run raises a rotation.failed event, a webhook, and a metric.
The pending label
Between create and finish the new value is already stored under the
pending label. This is not an implementation detail: if the process dies
after creating the password in the database but before writing it to
env-master, the password is lost — while already in effect. The value
becomes durable before it starts being applied.
Consumers keep reading current at that point and notice nothing.
Rollback
One action: the previous value is published as a new version. History stays monotonic; a repeated rollback moves forward instead of swinging the value back and forth.
What's already available
A PostgreSQL rotator using the two-user scheme — zero downtime for consumers. The engine core is not tied to a specific database: adding a rotator means implementing four methods.