Skip to main content

​
Rate limits

deepface.dev applies rate limiting and queue controls at the gateway.

​
Enforcement points

  • Per-account requests per minute within the configured limiter scope
  • Maximum inflight compute requests
  • Queue depth
  • Queue timeout

​
Retry behavior

429 rate_limited responses include:
  • Retry-After
  • RateLimit-Limit
  • RateLimit-Remaining
  • RateLimit-Reset
These headers describe the limiter that enforced the request. With a configured shared Redis limiter, gateways share the account counter. Without Redis, each gateway process has its own in-memory counter; multiple gateway Machines do not provide one strict fleet-wide RPM allowance. A configured required shared limiter fails closed when unavailable. Concurrency and queue admission remain local to each gateway process, with account overrides within its global limits. 503 queue_full, 503 queue_timeout, and 503 request_body_budget_full indicate temporary capacity pressure. Treat them as retryable with bounded backoff unless your own SLA policy says otherwise. A body-budget rejection is zero-rated, does not dispatch inference, and includes Retry-After: 5. 503 gateway_draining also rejects before compute and may omit request and rate-limit headers. For explicit model 503 model_not_ready, model_busy, and model_queue_timeout responses, the gateway already retries admission with jittered backoff within one 240-second upstream deadline. These retries do not consume another account RPM token or create a separate billing request. A client’s new HTTP request passes through admission and rate limiting again. Generic 502, connection loss, and 504 upstream_timeout do not prove that compute failed to run: preserve the request ID and investigate before replaying. See Errors for request-ID and timeout behavior.

​
Capacity planning

If you need higher sustained throughput, dedicated queue capacity, or custom limits, contact the deepface.dev team before scaling traffic abruptly.