Problem
audit_log grows unbounded — every proxied request is stored (with full headers/bodies) and there's no way to expire rows. In audit/passthrough mode the table eventually fills the Postgres volume. Because gateway auth is DB-backed (GetUserByGatewayAuthToken / GetUserByWebToken run on every request and dashboard load), a full disk doesn't just stop audit writes — the proxy starts returning 407 and the admin UI locks you out. We hit exactly this in production after ~1 month.
Proposal
An optional retention: block in gateway.yaml, off by default (no change for existing deployments):
retention:
enabled: true
max_age: 720h # delete audit_log rows older than this
interval: 6h
batch_size: 10000
A periodic prune deletes aged audit_log rows (batched, using the existing idx_audit_log_timestamp), then clears llm_responses no longer referenced — FK-ordered, so audit_log first. Logs rows pruned per run.
Happy to open a PR if the feature fits!
Problem
audit_log grows unbounded — every proxied request is stored (with full headers/bodies) and there's no way to expire rows. In audit/passthrough mode the table eventually fills the Postgres volume. Because gateway auth is DB-backed (GetUserByGatewayAuthToken / GetUserByWebToken run on every request and dashboard load), a full disk doesn't just stop audit writes — the proxy starts returning 407 and the admin UI locks you out. We hit exactly this in production after ~1 month.
Proposal
An optional retention: block in gateway.yaml, off by default (no change for existing deployments):
A periodic prune deletes aged audit_log rows (batched, using the existing idx_audit_log_timestamp), then clears llm_responses no longer referenced — FK-ordered, so audit_log first. Logs rows pruned per run.
Happy to open a PR if the feature fits!