Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
LiteLLM Proxy can put multiple model/provider deployments behind one OpenAI-compatible gateway. In production, the value is not only endpoint unification; virtual keys, team/model access, budgets, usage tracking, retries/fallbacks, routing and observability become centralized.
Current LiteLLM production docs use Postgres for persistent state such as virtual keys, users/teams, spend tracking and UI data, while Redis shares rate-limit, cooldown, usage-aware routing and cache state across workers/replicas. Redis is especially recommended once multiple workers are used.
Applications use LiteLLM virtual keys instead of raw provider keys; the gateway applies authentication, budget and routing controls before forwarding to a deployment and recording usage/traces.
Persistent key/team/spend data lives in the database, while fast shared state for rate limits, caching and routing lives in Redis.
LiteLLM Router can load-balance across deployments and provide retries, timeouts, cooldowns and fallbacks. Multiple provider or self-hosted replicas can sit behind one model name.
Adapt port and key values to your deployment.
Turkey (Turkish)
Germany (German)
Worldwide (English)
curl -s http://127.0.0.1:4000/health | headcurl -s http://127.0.0.1:4000/v1/models -H 'Authorization: Bearer sk-your-key' | headdocker compose psdocker compose logs --tail=100 litellmss -lntp | grep ':4000'Do not distribute master/provider secrets to applications. Apply team/user model allowlists, budgets, rate limits and logging policies at the gateway.
It can provide a similar multi-model gateway pattern, but LiteLLM is self-hostable proxy software while OpenRouter is a hosted routing service.
A basic proxy can, but virtual keys, usage tracking and UI persistence require database-backed state.
Some features can, but official docs strongly recommend Redis for multi-worker production because limits and routing state otherwise fragment per worker.
Share models/providers, virtual-key count, peak RPS, budgets and fallbacks; we can design LiteLLM + Redis + Postgres.