Skip to main content

Buyer guide

LiteLLM Gateway Rollout Playbook

Deploy LiteLLM with Postgres and Redis. Issue team keys with budgets, route coding tools through them, and schedule upgrades before company-wide rollout.

Reading time
3 min read
Sources
16 cited
In this piece
LiteLLM+8 Mixed

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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

  1. Who owns the gateway's uptime, Postgres, and Redis, and who is on call for it?
  2. Which minor line are we pinned to, and when does it leave the four-line support window?
  3. Which teams and apps get keys, with which models and budgets?
  4. Which coding tools are approved through the gateway, and has each been tested against it?
  5. 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
  1. LiteLLM docs: Docker image securityOfficial documentationdocs.litellm.ai
  2. LiteLLM blog: Security update, suspected supply chain incident (Mar 24, 2026)Official documentationdocs.litellm.ai
  3. LiteLLM blog: LiteLLM release v1.107.0 compromised (Oct 21, 2026)Official documentationdocs.litellm.ai
  4. LiteLLM blog: The attack chain behind the v1.107.0 LiteLLM release (Oct 23, 2026)Official documentationdocs.litellm.ai
  5. LiteLLM docs: Production best practicesOfficial documentationdocs.litellm.ai
  6. LiteLLM docs: Shared responsibility modelOfficial documentationdocs.litellm.ai
  7. LiteLLM docs: Budgets and rate limitsOfficial documentationdocs.litellm.ai
  8. LiteLLM docs: Virtual keysOfficial documentationdocs.litellm.ai
  9. LiteLLM docs: SSO for the Admin UIOfficial documentationdocs.litellm.ai
  10. LiteLLM docs: Load balancingOfficial documentationdocs.litellm.ai
  11. LiteLLM docs: Release cycleOfficial documentationdocs.litellm.ai
  12. LiteLLM docs: Version supportOfficial documentationdocs.litellm.ai
  13. LiteLLM blog: How Pfizer improved LiteLLM gateway performance and resiliency (Sep 11, 2026)Official documentationdocs.litellm.ai
  14. BerriAI/litellm issue #25762: the 5-user SSO limit during evaluation (Apr 15, 2026)Public sourcegithub.com
  15. BerriAI/litellm issue #15526: cascading readiness failures under provider 429s (Oct 14, 2025)Public sourcegithub.com
  16. BerriAI/litellm issue #19921: performance regression from 1.80.5 to 1.81.x (Jan 28, 2026)Public sourcegithub.com