Moving LiteLLM from open source to Enterprise

The SSO user limit is usually what forces the Enterprise license decision, so count who signs in before you request a license. The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID (Azure AD), Okta and generic OIDC providers. From v1.76.0, SSO is free for up to 5 users, and an Enterprise license is needed beyond that. Confirm the exact release line you plan to run, because the free allowance applies only from that version onward and your upgrade plan should match it.

Count the people who will sign in to the admin UI, not the people who will send requests through the gateway. Admin UI users are the platform engineers, security reviewers, finance approvers and team leads who create keys, set budgets, change routing or read spend. Set disable_env_credential_login: true before exposing the admin UI, which means every administrator needs an SSO identity. Also list break-glass accounts and decide whether they stay outside SSO. Ask LiteLLM in writing how it counts service accounts, automation identities and users who only hold virtual keys, because the answer changes your total.

SCIM is a separate decision from SSO. Enterprise adds SCIM beyond the free limit. SCIM provisions and deprovisions users and groups from your identity provider into LiteLLM, which matters when staff change roles or leave and when team membership should follow directory groups. Check whether your Okta, Entra ID, Google or generic OIDC setup can push groups to LiteLLM, who owns the deprovisioning steps, and how you will prove that a removed user lost access. Without SCIM, someone must disable accounts by hand in both places.

JWT authentication is also a separate decision. Enterprise adds JWT authentication with identity provider tokens, so calls to the gateway can carry tokens issued by your identity provider instead of relying only on virtual keys. Whether this fits depends on what your provider issues, which claims identify the user or team, how signing keys are rotated, and whether your applications can obtain tokens. Choose the identity provider first, then confirm claim mapping against the LiteLLM documentation and test with a non-production token before you commit to either pattern.

Before requesting a quote, write a short table with each identity group, its approximate count, whether it needs admin UI access, SCIM, JWT or only virtual keys, and who approves changes. Ask the vendor to price the license against that table and to state how SSO, SCIM and JWT are counted and included. Also ask which support terms apply. LiteLLM's enterprise documentation describes a dedicated engineering channel and optional 24/7 SLAs, with a 1 hour response for critical issues and 72 hours for security patches, so decide whether you need those options.

Without Redis, each LiteLLM gateway instance enforces rate limits and budgets on its own. A team's virtual key can be throttled on one instance while another instance, which has not seen the same requests, still accepts calls. If traffic is spread across instances by a load balancer, that team can exceed its TPM or RPM limit by roughly the number of instances, and the budget check may lag behind actual spend. Once the Enterprise deployment runs more than one gateway instance or worker, Redis 7.0 or newer becomes a requirement, not an optimization. It holds the shared rate limit counters, router state and cache that every instance reads from. Before go-live, confirm that each instance points at the same Redis endpoint and that the limit counters move together when you send test traffic through different instances.

PostgreSQL is the primary supported database and holds the keys, teams, models and spend records that the Enterprise license leaves in place. Redis does not replace it. Your platform team should decide who operates each service, what availability it needs, and how a Redis outage is handled, since the gateway's shared limit behavior depends on it. Ask your Redis provider or internal team to confirm the version in use, persistence settings and failover behavior, and test a failover while the gateway is under load. Record what the gateway does during the interruption so that the security team knows which limits may be temporarily unenforced.

LiteLLM's production guide suggests 1 vCPU and 4 GiB memory per worker as a starting point. Treat that as a baseline for sizing, not a finished capacity plan. Your numbers depend on request volume, prompt and response size, the number of models and providers in routing, logging volume and how many keys are active. On Kubernetes, LiteLLM recommends running one Uvicorn worker per pod and scaling out with more pods. This keeps resource limits and autoscaling predictable. Run a load test that matches your peak traffic, watch memory and latency per pod, and set resource requests and limits from that result. Confirm the autoscaling thresholds with the same test, because a pod that restarts under load can look like a limit failure to the user.

At scale, LiteLLM recommends batching spend updates to the database every 60 seconds. This reduces write pressure on PostgreSQL, but it also means budget totals in the database can trail real spend by up to that interval. For a team with a hard monthly budget, confirm with your finance and security owners whether that lag is acceptable, and whether Redis-backed counters or the gateway's own enforcement is the check that matters at the moment a limit is reached. Store LITELLM_MASTER_KEY, which must start with sk-, in a secret manager rather than in a config file, and make sure the key rotation process does not depend on the Admin UI.

Test first whether the switch changes anything that already exists. Build a staging gateway from the same image tag and config.yaml as production, restore a recent snapshot of the production PostgreSQL database into it, and add LITELLM_LICENSE to that staging copy only. Then confirm that existing virtual keys still authenticate, that spend totals, budgets and team membership match the snapshot, and that each key still sees the same model list. Keep the snapshot time recorded so every comparison in the rest of the test is against a known state, and expect that some checks will need the snapshot taken as close to the planned cutover as your data owners allow.

Next, test the controls that depend on shared state. Run at least two gateway instances against one Redis 7.0 or newer instance, send traffic through the same load balancer production will use, and confirm that a per-key budget, a TPM limit and an RPM limit each stop requests at the configured threshold no matter which instance receives them. Repeat the limit test with Redis unreachable to see the behavior you would otherwise discover in production. Also confirm that a key restricted to one model is refused for every other model on both instances, and that routing behaves as configured: force an error on the primary deployment and check the retry, cooldown and priority failover sequence, plus session affinity if you use it.

Then test sign-in and logging, which are where Enterprise features matter most to administrators. Sign in to the admin UI through your chosen provider (Google, Microsoft Entra ID, Okta or generic OIDC) with test accounts that map to each admin role, and confirm the roles granted match your design. Confirm that disable_env_credential_login is true in the staging configuration and that the master key no longer opens the admin UI. Count the SSO users you plan to have: from v1.76.0, SSO is free for up to 5 users, and an Enterprise license is needed beyond that, so include an account beyond that count in the test if you expect more. For per-team logging, create a test team with its own destination, send a request through it, and confirm the record arrives at that destination and nowhere else.

Define the rollback before go-live, and be exact about what it reverses. A rollback can remove LITELLM_LICENSE and redeploy the same image, restore config.yaml from version control, and restore the database from the snapshot. Removing the license turns off Enterprise features, but it does not by itself remove the data those features wrote. Restoring the database returns keys, spend and team changes to the snapshot time, so anything created after that point is lost unless you replay it. Some writes cannot be undone at all: audit log entries, role or team assignments saved after the switch, and records already delivered to external logging destinations. Confirm with LiteLLM and with your data owners which Enterprise settings persist to the database before you decide what a rollback window can accept.

An Enterprise license changes which features the LiteLLM gateway exposes. It does not harden the environment the gateway runs in. The host operating system, the container runtime, the network paths and firewall rules, and the PostgreSQL and Redis instances still need their own patching, access control and configuration review. Provider credentials for OpenAI, Anthropic, Bedrock, Azure and other providers still belong in a secret manager, scoped to the minimum each team needs and rotated on a schedule your team owns. LITELLM_LICENSE is one more secret to protect, and LITELLM_MASTER_KEY, which must start with sk-, should stay out of config files, shell history and logs.

The license also does not replace backups. Keys, teams, models and spend data stay in the existing database after the switch, so that database becomes more valuable to protect, not less. Your team must take backups, store them outside the gateway's failure domain, encrypt them and restore them into a scratch environment to prove they work. Agree the recovery point and recovery time with your risk owners before go-live, and keep the restore test record as evidence. The same restore test should confirm that the master key and license value can be recovered through your secret manager, because a restored database without those secrets does not bring the gateway back.

The Enterprise license does not produce audit reports. The vendor's compliance documentation describes controls and the evidence it can provide, including a SOC 2 Type II page in its docs. A description of controls is not an attestation. An independent auditor issues an attestation about your deployment against your defined system boundary, and a certification body issues any certification. DeployOpen plans and implements the configuration, prepares systems, control records, access reviews and evidence for an assessment, but does not issue audit reports or certifications. Ask the vendor directly for its current compliance statements, the scope and date of each, and whether they describe a self-hosted deployment like yours.

Before you sign, put these questions to the vendor in writing: which compliance statements apply to the release line you will run, what each one covers and excludes, and which support and security patch terms your contract includes. The vendor's enterprise documentation describes optional SLAs with response times for critical issues and security patches, so confirm which of those terms, if any, appear in your agreement. Then build a responsibility matrix that assigns each control to the vendor, your team or DeployOpen. The license should appear in that matrix as one line item among several, with the host, network, database, backups and credentials assigned to named owners.