REDAX / LAUNCH

Production launch

A concise gate for moving Redax from a working deployment to an evidenced production boundary.

WHYKeep raw customer text outside the model boundary.

WHATA local API that detects, replaces, and records safely.

HOWRun it, send text, pass only returned text onward.

Launch principle

A green process is not the same as a proven production boundary. Verify the exact image, model, policy, Redis, audit, telemetry, and rollback behavior for the deployment you operate.

Before traffic

✓Pin the release image digest, Python lockfile, model revision, policy, and persisted-schema versions.

✓Set production API keys, trusted hosts, unique hash salt, encrypted job-payload key, and independent audit-integrity key in a secret manager.

✓Use durable TLS Redis with a unique namespace, bounded pools/timeouts, backups, and a documented failover owner.

✓Configure readiness, ingress limits, Prometheus alerts, dashboards, and an OTLP collector with a privacy policy.

Synthetic canary

Run /healthz, then /readyz, then one authenticated POST /v1/redact with a synthetic value. Confirm the placeholder, idempotency replay, one durable job reaching a terminal state, and audit/telemetry metadata without the original value.

Failure and recovery evidence

Replica loss

Traffic continues and idempotency remains correct.

Worker loss

Accepted work retries or reaches the documented dead-letter state.

Redis failover

Readiness, recovery, duplicate completion, audit, and measured RPO/RTO match the policy.

10× traffic

429/503 behavior, memory, tasks, connections, and queue age remain bounded and recover.

Rollback

API and worker drain, return to the known-good digest, and pass the synthetic canary.

Stop conditions

Stop the rollout if readiness fails, raw text appears after an internal error, an accepted job disappears, telemetry contains request values, or measured capacity exceeds the published operating boundary. Keep the deployment unready until the cause is understood.