Production configuration
The deployment-time decisions that turn the Redax application into an operated production boundary.
Redax does not select your cloud provider, region, Redis plan, telemetry vendor, DNS zone, or SLO for you. Those are deployment inputs. This page names what must be chosen, why it matters, and which Redax settings carry the choice into the runtime.
Hosting target and region
What: run the API and worker on one machine, private containers, or the checked-in Kubernetes reference topology. Why: the region determines network latency to your application/model provider and where request-derived operational data is stored. How: choose the target in your platform deployment configuration; Redax receives the resulting host, port, trusted-host, and Redis/telemetry endpoints as environment variables.
deploy/kubernetes/ for replicas, probes, PDBs, rollout budgets, autoscaling, and network policies. Supply the external Redis Secret and ingress.Redis, HA, and backups
What: Redis backs rate limiting, response cache, idempotency leases, durable jobs, worker coordination, and optional centralized audit events. It is optional only when those features are disabled; the standard and scaled paths depend on it.
Production expectation: use a TLS endpoint, authentication, private network access, replication/automatic failover, persistence appropriate to the job durability you promise, scheduled backups, and a tested restore. Set REDAX_REDIS_URL, REDAX_REDIS_NAMESPACE, REDAX_REDIS_REQUIRED=true, bounded pool/timeouts, and the Redis audit settings. A Redis outage makes readiness fail and rejects new durable jobs; cache-only failures may recompute.
Telemetry destination
Redax emits structured stdout logs, Prometheus metrics at /metrics, and optional OpenTelemetry traces through REDAX_OTLP_ENDPOINT. Send each signal to an approved internal destination, define retention, and keep raw request values out of labels and attributes. To disable traces, leave the OTLP endpoint empty; keep metrics and error logs available for the SLOs you operate.
/metrics from the private network. Alert on readiness, errors, latency, queue age, Redis pool, audit, and worker saturation.REDAX_OTLP_ENDPOINT to an OTLP gRPC collector. Validate metadata-only spans and exporter failure behavior.Secrets, identity, and rotation
Store secrets in the platform secret manager or an equivalent protected injection mechanism. Required production values include REDAX_API_KEYS, REDAX_HASH_SALT, REDAX_JOB_PAYLOAD_ENCRYPTION_KEY, trusted hosts, and an audit integrity key when using the Redis audit backend. API keys can overlap during rotation: add the replacement, deploy, verify it, then revoke the old key with REDAX_API_KEY_REVOCATIONS. Treat hash salt, encryption keys, and audit keys as deployment-scoped credentials; rotation may require coordinated redeployment and can invalidate correlation or encrypted queued payloads depending on the key.
Redax does not ship a cloud IAM/control-plane integration. Use your platform’s workload identity for container-to-service access where available, and keep human/API-client identity at the API-key boundary.
DNS, TLS, and routing
Terminate HTTPS at your reverse proxy or ingress, point a DNS record at that endpoint, and set REDAX_TRUSTED_HOSTS to the accepted hostname. Redirect HTTP to HTTPS at the proxy. Forward request bodies within REDAX_MAX_BODY_BYTES, preserve SSE streaming for /v1/redact/stream, and allow the configured stream timeout. Local Compose intentionally uses HTTP on localhost; it is not a public TLS configuration.
Recommended production SLOs
These are starting targets, not guarantees. Measure them against your workload and record the chosen values with the deployment.
Use the production launch gate to run synthetic canaries and failure drills before exposing real traffic.