Upgrade and recovery

An upgrade must preserve policy, routing, session, and audit behavior. A restored process is not ready for traffic until its configuration and dependencies are valid.

Prepare the change

Identify the current verified release and rollback target. Verify the new image signatures and SBOM. Back up durable PostgreSQL state, including configuration, credential references, audit metadata, session metadata, and outbox records.

Valkey is hot state that can be rebuilt. Recovery must still reject revoked or terminated sessions; rebuilding a cache must not restore their authority.

Drain before replacement

1. Mark the affected path draining through the supported operational procedure.
2. Confirm new stateful sessions are rejected.
3. Allow existing work to finish or terminate within the configured timeout.
4. Replace the runtime and wait for dependency and projection readiness.
5. Run a harmless allowed call, a denial test, and an audit lookup before normal admission resumes.

Managed admission has additional durable quota and outbox ordering requirements. Use the matching release runbook rather than treating all state as disposable cache.

Roll back on an enforcement failure

If a policy, route, schema, or audit gate fails, stop admission and return to the prior verified release using the deployment’s rollback procedure. Repeat the governed request checks. A chart dry run cannot establish that rollback worked in the deployed environment.

Consult release and recovery for the implementation procedure.