Run the LiteLLM image pinned by digest on Postgres and Redis, and give every team a virtual key with a budget. Test each coding tool through the gateway and load-test every minor upgrade before production: once every model call uses the gateway, an outage or bad upgrade stops every team. This playbook covers deployment, keys, sign-in, coding tools, routing and the upgrade gate.
When you need this
- Teams hold provider keys in their own apps, and nobody can say who spends what on which model.
- Engineers want Claude Code, Codex, OpenCode, or Cursor on models the company has approved.
- Security asks for one place to log, limit, and revoke model access.
Evaluation criteria
Deploy a pinned image
What exactly are you running?
Look forRun the official image pinned by digest to 1.106.5 or a later patched release, never a floating tag such as latest or main-stable. BerriAI says dependency pins kept that image clear of the March 2026 PyPI compromise. On October 21, 2026, its own pipeline signed and published malicious 1.107.0 images, so verify the cosign signature and check that the provenance names BerriAI/litellm as the source repository. Set LITELLM_MASTER_KEY and LITELLM_SALT_KEY from a secret manager before startup. Never change the salt key once models are stored.
Size and back it
What does the gateway need under it?
Look forRun Postgres for keys, teams, and spend. Add Redis when you run more than one instance. BerriAI recommends 1 vCPU and 4 GiB per pod for requests and limits, with batched spend writes every 60 seconds. Set the database connection cap to maxReplicas times workers. Under BerriAI's shared responsibility model, your team owns database health and gateway uptime.
Issue keys by team
Who holds which key, and what can it reach?
Look forMap business units to organizations and groups to teams. Give each person or app a virtual key with allowed models, max_budget, and budget_duration. Keep provider keys in the gateway, so revoking one virtual key cuts that user off from every model.
Decide how people sign in
Do you need SSO for the Admin UI?
Look forSSO is free for up to 5 users from v1.76.0. Past that, SSO needs an Enterprise license, as do SCIM and audit logs. One team hit the 5-user limit during its evaluation. Without a license, issue keys from your own internal tool through LiteLLM's key management API.
Put coding tools behind it
Which tools reach models through the gateway?
Look forSet each tool's base URL and key to the gateway and name models by purpose so the backend can change. Test each tool first. Developers report Claude Code failing through LiteLLM on new Anthropic headers, and Codex working only with the Responses API turned off.
Route and fall back
What happens when a provider fails?
Look forConfigure multiple deployments under one model name. Set RPM and TPM limits per deployment, with retries and a fallback model. Use Redis to share routing state across instances. Force each fallback in a test. One team reported readiness probes failing across Kubernetes pods when a provider returned 429s.
Gate every upgrade
How does a new release reach production?
Look forLiteLLM ships a stable minor about weekly and supports the four latest minor lines. Pin a line, take its patches, and load-test each move to a new line against fixed baselines in CI. Pfizer's load test caught v1.89.2 halving throughput with an unchanged error rate, and a GitHub issue reports a 50-user gateway slowing across the UI and API after a minor upgrade.
Questions to ask vendors
- Who owns the gateway's uptime, Postgres, and Redis, and who is on call for it?
- Which minor line are we pinned to, and when does it leave the four-line support window?
- Which teams and apps get keys, with which models and budgets?
- Which coding tools are approved through the gateway, and has each been tested against it?
- What load test must a new release pass before production?
Red flags
- Installing LiteLLM from PyPI at deploy time without a pinned version.
- A Docker deployment that follows a floating tag such as latest or main-stable and isn't pinned to a digest.
- The master key handed to apps or engineers when they should get virtual keys.
- A deployment more than four minor lines behind the latest stable release.
- Upgrades going to production without a load test against a baseline.
Products in this piece
Sources
- Official documentation
- 13
- Public source
- 3
- LiteLLM docs: Docker image security
- LiteLLM blog: Security update, suspected supply chain incident (Mar 24, 2026)
- LiteLLM blog: LiteLLM release v1.107.0 compromised (Oct 21, 2026)
- LiteLLM blog: The attack chain behind the v1.107.0 LiteLLM release (Oct 23, 2026)
- LiteLLM docs: Production best practices
- LiteLLM docs: Shared responsibility model
- LiteLLM docs: Budgets and rate limits
- LiteLLM docs: Virtual keys
- LiteLLM docs: SSO for the Admin UI
- LiteLLM docs: Load balancing
- LiteLLM docs: Release cycle
- LiteLLM docs: Version support
- LiteLLM blog: How Pfizer improved LiteLLM gateway performance and resiliency (Sep 11, 2026)
- BerriAI/litellm issue #25762: the 5-user SSO limit during evaluation (Apr 15, 2026)
- BerriAI/litellm issue #15526: cascading readiness failures under provider 429s (Oct 14, 2025)
- BerriAI/litellm issue #19921: performance regression from 1.80.5 to 1.81.x (Jan 28, 2026)