Redax documentation

Deployment

Move from a local proof-of-concept to a private, observable redaction boundary that your team can operate.

Why

Keep raw customer text outside the model boundary.

What

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

How

Run it, send text, pass only the returned text onward.

The recommended path

Start with Docker Compose so the API and Redis wiring are correct. Once your application is integrated, keep the same API contract and move the containers behind your ingress, service identity, durable audit storage, and monitoring.

Choose a deployment tier

Start with the smallest boundary that fits the workload. Redis is optional for a single-process service when caching, rate limiting, and jobs are disabled; production authentication and trusted hosts are still required.

Simple

One process, usually regex-only. Good for a controlled service with structured detection; no Redis required when the related features are disabled.

Standard

One or a few processes with the pinned local GLiNER2 model and Redis for rate limits, caching, idempotency, and jobs.

Scaled

Multiple identical replicas behind an ingress with shared durable Redis, consistent model revisions, policies, and secrets.

The current /v1/jobs path runs in FastAPI background tasks inside the receiving process. It is bounded for modest workloads, not a durable distributed worker queue.

1. Run locally

This gives a developer a repeatable environment with the redaction API and Redis dependency. The health check confirms the service is reachable before you integrate application code.

git clone https://github.com/sachncs/redax.git
cd redax
docker compose up

curl http://localhost:8000/healthz

2. Set the production boundary

The local Compose profile is intentionally marked as development. Production startup requires API keys and trusted hosts, and the service does not enable browser CORS unless you configure it.

REDAX_ENV

Set prod for deployed traffic; only dev permits unauthenticated local development.

REDAX_API_KEYS

Required in prod. Keep keys in your secret manager and rotate them.

REDAX_TRUSTED_HOSTS

Required in prod. List the public hostnames accepted by the service.

REDAX_CORS_ORIGINS

Leave empty unless browser clients need access; list exact origins, never a wildcard in prod.

REDAX_HASH_SALT

Use a unique random value per deployment so hashes and cache keys cannot be correlated across environments.

REDAX_REDIS_URL

Point rate limiting, idempotency, response caching, and jobs at durable Redis.

REDAX_AUDIT_PATH

Mount durable storage or a log shipper. The audit file contains metadata, not raw PII.

REDAX_OTLP_ENDPOINT

Send traces to your internal collector when you need distributed request visibility.

3. Probe the right things

/healthz

Liveness

Is the process running? Use this for restart decisions.

/readyz

Readiness

Is the redactor initialized and able to serve traffic? Use this for load balancers.

/metrics

Metrics

Are latency, errors, queue depth, and detected entities within your operating range?

Production checklist

✓Authentication is enabled and tested with an invalid key.
✓The API is reachable only from the services that need the privacy boundary.
✓Redis and audit storage survive a container restart.
✓Readiness, error rate, latency, and queue depth are monitored.
✓A policy version is committed with the application release.
✓The team has verified that logs, traces, cache keys, and audit events do not contain raw values.