What LiteLLM upgrades and support involve
This service covers keeping a self-hosted LiteLLM proxy current without breaking the routing, fallbacks and virtual keys your applications depend on. The work starts with choosing a release. LiteLLM publishes stable releases tagged with a -stable suffix after 12 hour load tests, and the team should pin a specific tag rather than follow the main branch. Upgrades then move the proxy between minor versions, and LiteLLM maintains support for the four most recent stable minor versions for both open source and Enterprise deployments. Confirm your current minor against that window before planning the next move, because falling outside it changes your support options.
Database migrations are the highest-risk step. Virtual keys, budgets and spend records live in PostgreSQL, so each minor upgrade may run schema changes against production data. The work includes a tested backup and restore point, a dry run against a copy of production data, and a rollback decision made in advance. Before rollout, test routing order, retries, cooldowns and fallbacks against each provider you use, and confirm that a sample of virtual keys still hits its intended models and stops at its budget or TPM and RPM limits. Record the results so the next upgrade starts from evidence.
Expect upgrades to be triggered by a new minor release, a security patch, a provider change (new credentials, new model names or a provider leaving your approved list), a database upgrade, or a move to multiple proxy instances. A move to several instances adds Redis 7.0 or newer for shared rate limits and router state, so it changes the test plan as well as the deployment. A team with a staging environment, a named owner and a tested rollback can often handle patch releases alone. A partner adds the most value when a minor move coincides with schema changes, a multi-instance move or a compliance deadline, or when no one on the team has run the proxy under load.
Support after go-live covers triage of gateway incidents, guidance on release notes and configuration drift, and planned upgrades on a schedule you agree. LiteLLM Enterprise offers a dedicated engineering channel and optional 24/7 SLAs, including a 1 hour response for critical issues and 72 hours for security patches, according to its enterprise documentation. Ask any partner which of those response targets they contract for themselves, which ones depend on the LiteLLM vendor, and what is excluded from the retainer.
What the work includes
Each work package ends with a deliverable you keep after the engagement. Optional retainer support can follow handover for future upgrades, release monitoring and repeat regression runs.
Release selection and upgrade plan
We compare your running version with the four most recent stable minor versions LiteLLM supports, then select a -stable release tag and record the reason. The plan lists changelog items that touch your providers, callbacks and config. Deliverable: a written upgrade plan with target tag, ordered steps and go or no-go criteria.
Staging, version pinning and image verification
We build a staging environment that matches production's proxy image, configuration and database engine, then pin the image by version and digest. Before promotion, we verify the image signature with cosign against the GHCR image that LiteLLM publishes. Deliverable: a pinned staging deployment and a verification record for each promoted image.
PostgreSQL migration rehearsal and cutover
Virtual keys need PostgreSQL, so schema changes between versions must be rehearsed on a restored copy of your data. We time the migration, check key and spend records afterward, and define the cutover window with a tested fallback. Deliverable: a rehearsal log, a cutover runbook and post-migration data checks.
Redis and multi-instance checks
Once more than one proxy instance runs, shared rate limits, router state and cache depend on Redis 7.0 or newer. We confirm the Redis version and failover behavior, check that every instance enforces the same limits after upgrade, and confirm cooldown state survives an instance restart. Deliverable: a multi-instance test report and Redis configuration notes.
Regression tests for gateway behavior
We write regression tests that exercise routing, including cooldowns and fallback order, plus virtual key model restrictions, budgets and TPM or RPM limits, all run against the candidate version. Failures block promotion until your team decides whether the change is intended. Deliverable: a versioned test suite your team runs before each upgrade, with results for the target release.
Rollback plan and runbook handover
Each upgrade gets a rollback plan that names the previous image digest, identifies which database steps can be reversed, and sets the decision point for reverting. We then walk your operators through the runbook so upgrades do not depend on one engineer. Deliverable: a rollback plan, a handover runbook and a handover session with your team.
What drives cost and duration
This table lists the factors that change how much work an upgrade and support engagement takes, why each one adds effort, and how to keep it manageable, so you can compare your own environment against the written scope.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Proxy instances and Redis | Each proxy instance must be upgraded, drained and verified in turn. Once more than one instance runs, Redis 7.0 or newer holds shared rate limits, router state and cache, so Redis versions and failover must be tested with every release. | Confirm the instance count and Redis topology before scoping. Standardize deployment manifests so rolling upgrades follow one pattern. |
| PostgreSQL size and migration history | Virtual keys, spend records and logs live in PostgreSQL. Larger databases and long gaps between versions mean longer migrations, more rollback planning and more time for backup and restore checks. | Upgrade on a regular cadence instead of skipping versions. Ask for a tested backup and restore before each migration. |
| Virtual keys, teams and budgets | More keys, teams and budget rules mean more test cases for limits, model restrictions and temporary budget increases after each upgrade, and more spend data to reconcile. | Keep a documented baseline of teams, budgets and key scopes. Test a representative sample rather than every key. |
| Providers and private models in routing | Each provider and private model has its own credentials, quotas and behavior. Routing, retries, cooldowns and fallback order need checks against each one after every change. | Limit the active provider list to what is approved. Keep a routing test set that exercises each model group. |
| Custom callbacks and guardrails | Custom code runs in the request path and can break when LiteLLM changes internal interfaces. Each callback or guardrail needs retesting after every upgrade. | Keep custom code small and isolated. Maintain automated tests for each callback and guardrail and record their owners. |
| Edition and Enterprise features | Open source and Enterprise differ in governance features such as SSO beyond the free five-user limit, audit logs, RBAC and secret manager integrations. Each enabled feature adds configuration to verify and support terms to confirm. | Confirm which features are in use and which are planned. Ask the vendor to confirm current license terms and support options before quoting. |
| Kubernetes and deployment tooling | Helm charts, GitOps pipelines, ingress and secret sync each have their own version lifecycle. Changes to any of them can affect the proxy during an upgrade. | Pin tool versions and document the deployment pipeline. Include the cluster version in each upgrade test plan. |
| Compliance evidence requirements | Assessors may ask for change records, test results, version approvals and access reviews for each upgrade. Producing this evidence adds documentation work to every release cycle. | Agree the evidence list at scoping. Generate test and change records from the same pipeline that deploys the release. |
| Number of environments | Each environment such as development, test, staging and production needs its own upgrade run and verification. Differences between environments are a common source of late surprises. | Keep environments configured from the same source. Promote the same tested release artifact through each environment. |
Project phases and outputs
The upgrade sequence moves a LiteLLM gateway from a documented current state to a tested target version in production, then hands it over with a rollback path and a support runbook.
Inventory the current state
DeployOpen records the running LiteLLM version, proxy configuration, PostgreSQL and Redis versions, custom callbacks and any patched code, plus the virtual keys, teams and budgets in use. The output is a written baseline that the upgrade is measured against, and the client confirms it before any change is made.
Select the target version
The team chooses a target from releases tagged -stable, checks the release notes and the changes between the current and target minor versions, and confirms the target sits within the four most recent stable minor versions that LiteLLM supports. The output is a named target version with a documented reason for choosing it and a list of configuration changes it requires.
Rehearse the upgrade in staging
The target version is deployed to a staging environment built from a copy of the production configuration. The database migration is run against a restored copy of production data and timed and logged, so the team knows what the migration changes and whether it can be reversed. The output is a staging deployment and a migration record that the client signs off.
Run the functional test pass
Testing covers routing strategy, retries, cooldowns, failover order, virtual key model restrictions and budget enforcement, using scripted requests that match the approved models and key patterns in use. Each behavior is compared with the baseline from the inventory. The output is a test report listing pass, fail and accepted differences, with failures fixed and retested before cutover is scheduled.
Cut over production with a rollback path
The production upgrade follows a written change plan that includes a database backup taken immediately before the migration, a defined rollback procedure and the named people who approve each step. Service checks confirm that keys authenticate, models respond and spend is recorded after the switch. The output is a completed change record and a tested rollback plan kept until the client accepts the upgrade.
Hand over after hypercare
During an agreed hypercare period, DeployOpen watches logs, spend data and error rates and resolves issues that appear under real traffic. The handover then delivers an updated runbook, the upgrade record and a support plan for future releases. The output is a signed handover document, and the timing of hypercare and the support terms are confirmed in the written scope.
What stays in-house and what goes to a partner
This table lists each recurring LiteLLM upgrade and support task with its usual owner and the skills it needs, so you can see where a partner adds the most value.
| Work part | Usual owner | Skills needed |
|---|---|---|
| Routine minor upgrades | Client platform team, with partner review of release notes | Kubernetes rollouts, Python package checks, staging test runs |
| Change approval | Client change board, with partner preparing the change record | Documented risk and rollback steps, mapped to the client's change policy |
| PostgreSQL backup and restore checks | Client database team | PostgreSQL backups, point-in-time recovery, restore tests on a separate copy |
| Redis operation | Client platform team | Redis 7.0 or newer administration, persistence, failover and monitoring |
| Provider credential rotation | Client security team, with the platform team applying the change | Identity and secret manager workflows, key scoping, Kubernetes secrets |
| Routing and budget regression tests | Partner builds the test suite, client team accepts results | Python test scripting, virtual key and budget behavior, access limit testing. Partner adds the most value here. |
| Custom callback maintenance | Engineers who wrote the callbacks, with partner updates | Python, the LiteLLM callback interface, regression tests on each new release |
| Security patch triage | Client security team, with partner impact assessment | Security testing, reading vendor advisories, deciding patch timing |
| First-time major or multi-instance moves | Partner leads, client platform team pairs on the work | Kubernetes, PostgreSQL, Redis, load balancing and cutover planning |
What goes wrong and how to prevent it
Most LiteLLM upgrade incidents trace back to version choice, untested data changes or behavior that shifted without anyone checking. Each card names a failure, why it matters for your gateway and the check that prevents it.
Unsupported or unverified releases
Jumping several minor versions at once can land on a release outside the four most recent stable minors that LiteLLM supports for open source and Enterprise. Pin an explicit -stable tag, read the release notes for every minor version you pass, and verify the cosign signature on the GHCR image before it reaches any cluster.
Migrations without a tested restore
Proxy upgrades can run database migrations against PostgreSQL, the primary supported database, and a failed migration can block startup. Take a backup, restore it into a scratch database, and confirm the proxy starts and serves a test virtual key before the production migration runs. Record how long the restore took so the rollback window is known.
Rehearsal without production-like data
A staging run against a small or empty database can pass while the migration, spend-log tables and key lists behave differently at production volume. Rehearse on a copy of production data sized close to production, with the same PostgreSQL and Redis versions, and time each step so the maintenance window is based on measured results.
Mixed replica versions and unowned patches
Replicas that roll out at different times can serve different versions behind one load balancer, and shared Redis state may then behave inconsistently. Use one image tag for every pod, confirm Redis is 7.0 or newer once more than one instance runs, and assign a named owner to track new stable releases and security patches.
Routing and custom code behavior changes
After an upgrade, router settings such as retries, cooldowns, failover priority and session affinity can produce different outcomes, and custom callbacks or guardrails can break if the interface they depend on changes. Replay a fixed set of model aliases, force a primary provider failure in staging, and run your custom code tests before cutover.
Budgets and keys misreporting spend
Virtual keys, per-team budgets and temporary budget increases depend on PostgreSQL, and spend updates are batched to the database every 60 seconds at scale. After an upgrade, compare budget and spend totals with a sample of provider invoices, confirm existing keys keep their limits and model restrictions, and check for unexpected budget resets.
How the work differs by starting point
A single proxy with configuration embedded in the deployment is the simplest starting point, and the one where a rollout is easiest to reason about. Because there is no shared state between instances, the main risk is that a change to the image or configuration takes the gateway down for every application at once.
- Testing: Run the candidate version against a copy of the configuration and a restored copy of the database, then replay representative model requests through each configured provider and alias.
- Sequencing: Apply database migrations in a planned window, then switch the running container, keeping the previous image available for rollback.
- Handover: Document the image tag, the configuration source, and the single restart procedure so the platform team can repeat it without the partner.
- Confirm: Whether your change window allows a brief full outage, and who approves it.
Several proxy instances behind a load balancer share rate limits, router state and cache through Redis. An upgrade now has to account for instances running different versions at the same time, and for the Redis state those versions read and write.
- Testing: Include a test where instances on the old and new versions serve traffic together, and confirm that rate limits and cooldowns still behave consistently.
- Sequencing: Run database migrations once, before any instance changes version, then roll instances one at a time while health checks watch each one.
- Redis: Confirm the Redis version meets the production guide's minimum of 7.0 and check that a Redis restart does not reset budgets in a way your finance team would notice.
- Handover: Record the rolling order, health check criteria and the rollback point for each instance.
On Kubernetes, LiteLLM's guidance is one Uvicorn worker per pod with horizontal scaling. Upgrades then become a deployment rollout, and the work shifts toward manifests, probes, secrets and autoscaling behavior.
- Testing: Verify readiness and liveness probes against the new image, and load test at the pod counts your autoscaler will actually reach.
- Sequencing: Keep the master key and provider credentials in a secret manager, and confirm that a new pod can start with the same secret references before rolling the deployment.
- Handover: Hand over the Helm or manifest versions, the rollout strategy, and the steps for pausing or reverting a rollout.
- Confirm: Your cluster's upgrade calendar and whether a separate staging namespace is available for load tests.
An older minor version outside the support window usually means several releases of changes to the database schema, configuration keys and routing defaults. The work is more of a migration than a patch, and it needs a clear path through intermediate versions.
- Assessment: Compare your configuration and key usage against the release notes between your current version and the target, and list any settings that changed meaning.
- Testing: Restore a recent database backup into a staging environment and run the full migration sequence, not just the final version.
- Sequencing: Plan stepping stones if the release notes or migration history require them, and check the current release on the GitHub releases page before choosing a target.
- Handover: Document which intermediate versions were tested, what was changed in configuration, and what the new support window means for your next upgrade.
Where the proxy runs on a restricted network, images and dependencies must be mirrored internally and verified before they reach production. Upgrades depend on the mirror process as much as on the software itself.
- Verification: Check the cosign signature on the image against the published signing identity, and keep the verification record with the change ticket.
- Mirroring: Mirror the tagged -stable image, its digest and any Python or database driver dependencies, and confirm the mirror is updated on your own schedule.
- Testing: Run load tests and provider connectivity tests inside the restricted network, since outbound calls to model providers may be blocked or proxied.
- Handover: Hand over the mirror procedure, signature verification steps and the list of egress destinations that must stay open.
An environment using SSO, JWT authentication or secret manager integrations depends on Enterprise features, so the upgrade must be tested against identity and secret flows, not just model requests. Enterprise support terms also become part of the handover.
- Testing: Sign in through the identity provider, check role mapping and team assignment, and test JWT validation with tokens from your identity provider after each version change.
- Secrets: Confirm that each secret manager integration still resolves the references used by the configuration, including after a rotation.
- Sequencing: Check Enterprise license terms and free-user limits for the target version before rollout, since SSO limits are tied to versions.
- Handover: Record the support channel, the severity process and any optional SLA terms your organization has agreed to in writing.
What you need to provide
Before DeployOpen can plan an upgrade or support handover for your LiteLLM gateway, your team needs to name owners and supply access. Assign one named owner each for the gateway, the PostgreSQL database and the Redis instance, since virtual keys, budgets and shared rate limits all depend on them. Provide access to staging and production clusters or hosts, and a current configuration export of the proxy so the work starts from what is actually running.
Supply the business inputs that routing and budget tests depend on. This means the list of teams, virtual keys, budgets and models in use, plus the test cases your business relies on, such as a specific application's model alias, a team's spend limit or a fallback order that must hold during a provider outage. Confirm the change windows when upgrades can run and who approves them. Provide recent backup and restore evidence for PostgreSQL, since a database migration between LiteLLM versions is the step most likely to need a rollback.
Decide in advance who holds decision rights for choosing a release, including whether you run a -stable tag, when you move to a newer minor version within the four supported minor versions, and who authorizes a rollback. State your licensing position for any Enterprise features you use or expect to use, such as SSO beyond the free five-user limit, audit logs or team RBAC. The licensing position determines which configuration can be upgraded without a change in edition.
Confirm with LiteLLM before you commit. Support terms, response times and any SLA for Enterprise customers are set in your agreement with LiteLLM, not in DeployOpen's scope. Ask LiteLLM which support channel and response commitments apply to your edition, and whether security patch timelines are included. Record the answers so that the upgrade plan and the support runbook reflect the terms you actually hold.
Frequently asked questions
How much does a LiteLLM upgrade cost and what drives the price?
The price follows the written scope, and DeployOpen does not publish a price list. The main drivers are the number of proxy instances and Kubernetes environments, how many providers and private models are connected, how many custom callbacks, guardrails or pricing overrides need retesting, and whether PostgreSQL and Redis change in the same window. A minor version upgrade that touches only the proxy usually takes less effort than one that also changes the database. Ask for a quote that lists each environment, test cycle and rollback rehearsal as separate line items.
How long does a LiteLLM upgrade take in production?
No duration applies to every environment, so confirm the timeline in the written scope for your setup. Elapsed time depends on how many environments move through staging, how large your routing and budget configuration is, how many teams must sign off on test results, and which change windows your operations team allows. Upgrades that stay within one minor line and skip schema changes generally move faster. Ask for staging, production and rollback steps to appear as separate phases with their own dates.
Can our own team upgrade LiteLLM without an outside partner?
Many teams can, provided they have engineers who understand Kubernetes, PostgreSQL and Redis, plus a staging environment that mirrors production. The harder parts are reviewing release notes for each version, replaying routing and budget tests, and handling a failed migration during a change window. An outside team helps when staff are thin, when several environments must move together, or when the upgrade record must support an assessment. DeployOpen plans, implements and documents upgrades in your infrastructure under a fixed scope, and ongoing support is available as a retainer after go-live.
Which LiteLLM release tag should we run in production?
Run a tagged -stable release. LiteLLM publishes these releases after 12 hour load tests, which gives you a tested baseline that untagged main builds do not carry. Pin the exact image tag and verify the cosign signature before deployment. The GitHub releases page lists v1.105.1, published October 14, 2026, so confirm the current -stable tag when you plan the work.
How many LiteLLM minor versions get support, and what does that mean for planning?
LiteLLM maintains support for the four most recent stable minor versions, for both open source and Enterprise deployments. That gives you a window to upgrade, not an open-ended one. Plan one upgrade cycle for each minor version you fall behind, and treat dropping out of the supported four as a forced upgrade. Watch the release page for new minor versions, schedule upgrades on a calendar, and budget test time for each jump, since skipping several minor versions at once means reviewing more configuration and schema changes.
Are LiteLLM database migrations reversible, and how do we roll back?
Confirm reversibility in the release notes for your target version, because it depends on each migration. Do not assume that reverting the proxy image also reverts the database schema. Take a verified PostgreSQL backup before each migration, rehearse restoring it in staging, and record the exact image tag running before the change. Your rollback plan should state whether it restores the database, reverts the image, or both.
How DeployOpen delivers LiteLLM upgrades and support
DeployOpen plans, tests and runs LiteLLM upgrades inside your own infrastructure, from choosing a release to handing over a documented runbook. Support after go-live is available as a retainer, sized to the written scope.
How we scope
- Written scope names the LiteLLM version, the deployment topology and the upgrade path agreed before work starts.
- We confirm which of the four supported minor versions you will run and the target -stable release.
- Scope lists the providers, virtual keys, budgets, routes and database migrations that must be re-tested after the change.
How we build
- We stage the upgrade in a non-production environment that mirrors your PostgreSQL and Redis setup.
- We test routing choices, retries, cooldowns and fallback order against your model list before any rollout.
- We verify virtual key budgets, TPM and RPM limits and model restrictions against expected results, and record the outcomes.
How we hand over
- You receive the upgrade runbook, database migration steps, rollback procedure and the test evidence from staging.
- Configuration, secret locations and image provenance checks are documented so your team can repeat the upgrade.
- We walk your operators through the cutover and post-upgrade checks, and confirm who owns each step afterward.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, with responsibilities written into the agreement.
- Support can cover tracking new -stable releases and planning each minor version move before the support window closes.
- Ask your quote to name response expectations, release review cadence and whether LiteLLM Enterprise support is included or separate.
