chore(release): backport #33592 to stable/1.90.x and cut 1.90.5

[yuneng-berri]

Relevant issues

Backports #33592 onto stable/1.90.x and cuts 1.90.5. #30243 narrowed the runtime stage of the three Dockerfiles to an allowlist COPY, which dropped /app/litellm-proxy-extras from published images starting v1.90.0. Deployments that run their own pre-deploy migration job (modeled on the helm migration job: pull the same image the app runs, then prisma migrate deploy against the schema and migrations shipped at that path) broke on upgrade to 1.90.x, and the breakage is silent because prisma migrate deploy exits 0 without applying anything when the schema it is pointed at has no adjacent migrations directory. This restores the folder in the runtime stage of all three Dockerfiles, matching what images up to v1.89.x contained (about 6 MB per image)

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

What is included

• fix(docker): restore litellm-proxy-extras source dir in runtime images #33592 fix(docker): restore litellm-proxy-extras source dir in runtime images (111d447e1b), cherry-picked with -x
• chore: bump 1.90.4 -> 1.90.5
• chore: refresh uv.lock for 1.90.5

Adaptation notes

None. The pick is patch-identical (git patch-id --stable matches the staging squash) and applied without conflicts. The change touches no Python, so the line's Black 88-column format-check scope is unaffected

Known noise on this line

The pick adds or modifies no Python or test files, so there is no targeted pytest delta to judge. The claim was verified directly on images built from this branch (below)

Screenshots / Proof of Fix

Broken behavior, captured on the published ghcr.io/berriai/litellm:v1.90.4 image (the tip of this line before the pick). The folder is gone, and pointing prisma at the /app/schema.prisma that does still ship exits 0 while applying nothing, so a migration job reports success against an unmigrated database:

$ docker run --rm --entrypoint sh ghcr.io/berriai/litellm:v1.90.4 -c 'ls /app/litellm-proxy-extras'
ls: /app/litellm-proxy-extras: No such file or directory
$ echo $?
1
$ docker run --rm -e DATABASE_URL="postgresql://postgres:...@host.docker.internal:55433/mig_base" \
    --entrypoint sh ghcr.io/berriai/litellm:v1.90.4 -c 'prisma migrate deploy --schema /app/schema.prisma'
Datasource "client": PostgreSQL database "mig_base", schema "public" at "host.docker.internal:55433"

No migration found in prisma/migrations

No pending migrations to apply.
$ echo $?
0
$ docker exec bp-pe-pg psql -U postgres -d mig_base -tc "SELECT count(*) FROM pg_tables WHERE schemaname='public';"
     1

The single table left behind is prisma's own _prisma_migrations bookkeeping table

Fixed behavior, on images built locally from this branch from each of the three Dockerfiles, each run against a fresh database:

$ docker build -t litellm-190x-fix:main -f Dockerfile .
$ docker run --rm -e DATABASE_URL="postgresql://postgres:...@host.docker.internal:55433/mig_main" \
    --entrypoint sh litellm-190x-fix:main -c '
      test -f /app/litellm-proxy-extras/litellm_proxy_extras/schema.prisma && echo "schema: present" &&
      test -d /app/litellm-proxy-extras/litellm_proxy_extras/migrations && echo "migrations dir: present" &&
      diff /app/schema.prisma /app/litellm-proxy-extras/litellm_proxy_extras/schema.prisma && echo "schema matches /app/schema.prisma" &&
      prisma migrate deploy --schema /app/litellm-proxy-extras/litellm_proxy_extras/schema.prisma'
schema: present
migrations dir: present
schema matches /app/schema.prisma
127 migrations found in prisma/migrations

All migrations have been successfully applied.
$ echo $?
0
$ docker exec bp-pe-pg psql -U postgres -d mig_main -tc "SELECT count(*) FROM pg_tables WHERE schemaname='public';"
    66

The same flow passes on the docker/Dockerfile.database build (schema present and matching, 127 migrations applied to a fresh database, 66 tables, exit 0) and on the docker/Dockerfile.non_root build running as its default uid 65534 (schema present and matching, migrations dir readable, 127 migrations applied, 66 tables, exit 0). 127 is the correct count here: it is this line's own migrations catalog (staging ships 135), which is exactly what a v1.90.5 image should carry

An adversarial verification pass over the pick survived on all three sub-claims: each builder stage provably produces the directory before the new COPY references it (so it cannot land empty), the runtime contract ships it in all three images, and nothing on this line depends on the directory's absence (the non_root recursive chown covers the new folder before the privilege drop to uid 65534, and .dockerignore strips nothing from it). The pass also confirmed the restored folder is read only by external pre-deploy migration jobs: every in-repo migration path resolves schema and migrations from the installed litellm_proxy_extras package in site-packages, and the helm migration job uses the separate litellm-migrations image that always carried the folder. That matches the upstream PR's framing and means the change is inert for in-repo code paths; the risk is presence-only

Type

🐛 Bug Fix

Changes

Cherry-pick of #33592 onto stable/1.90.x, plus the 1.90.5 version bump and lock refresh. One COPY --from=builder /app/litellm-proxy-extras /app/litellm-proxy-extras line in the runtime stage of each of Dockerfile, docker/Dockerfile.database, and docker/Dockerfile.non_root. No schema, dependency, or configuration changes

QA runbook

1. git fetch origin && git checkout litellm_backport_1_90_x_bp_proxy_extras_0716
2. docker build -t qa-190x:main -f Dockerfile .
3. docker run --rm --entrypoint sh qa-190x:main -c 'ls /app/litellm-proxy-extras/litellm_proxy_extras/migrations | head' and confirm the migrations directory is present and non-empty
4. Point a fresh Postgres at it: docker run --rm -e DATABASE_URL="postgresql://<user>:<pass>@host.docker.internal:<port>/<fresh-db>" --entrypoint sh qa-190x:main -c 'prisma migrate deploy --schema /app/litellm-proxy-extras/litellm_proxy_extras/schema.prisma' and confirm 127 migrations apply with exit 0

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

This backport restores /app/litellm-proxy-extras to the runtime stage of all three Dockerfiles (Dockerfile, docker/Dockerfile.database, docker/Dockerfile.non_root), fixing a regression introduced in v1.90.0 that caused pre-deploy Prisma migration jobs to silently succeed without applying any migrations. The version is bumped to 1.90.5 and the lock file is refreshed.

• Each Dockerfile gains one COPY --from=builder /app/litellm-proxy-extras /app/litellm-proxy-extras line in its runtime stage; the builder already produces this path via its full-source COPY . ., so the source is guaranteed to exist.
• In Dockerfile.non_root the new COPY lands before the chown -R nobody:nogroup /app sweep, so the directory inherits correct ownership before the privilege drop to uid 65534 — no separate permission fixup is needed.
• The version bump is consistent across both sections of pyproject.toml and the lock file.

Confidence Score: 5/5

Safe to merge — a single-line addition per Dockerfile that restores a directory dropped by a prior allowlist narrowing; the builder stage provably produces the path, permissions are covered by the existing recursive chown, and the fix is verified end-to-end against all three images.

The change is minimal and surgical: one COPY instruction added to each of three Dockerfiles, a version bump in two places in pyproject.toml, and a lock refresh. Every claim in the PR description is backed by concrete docker-run output. The builder stage already copies the full source tree, guaranteeing the source path exists. The non_root image's existing /app chown sweep covers the new directory before the uid drop. No Python, schema, or configuration changes are included.

No files require special attention.

Important Files Changed

Filename	Overview
Dockerfile	Adds COPY --from=builder /app/litellm-proxy-extras /app/litellm-proxy-extras to the runtime stage; builder already produces this path via COPY . ., so the source is always present.
docker/Dockerfile.database	Identical single-line addition of the litellm-proxy-extras COPY to its runtime stage, mirroring the main Dockerfile fix.
docker/Dockerfile.non_root	Adds the litellm-proxy-extras COPY before the /app recursive chown, so the new directory is correctly owned by nobody:nogroup before the privilege drop to uid 65534.
pyproject.toml	Version bumped from 1.90.4 to 1.90.5 in both the [project] section and [tool.commitizen] section — consistent.
uv.lock	Lock file refreshed: litellm version updated to 1.90.5 and exclude-newer timestamp advanced to 2026-07-13.

_{Reviews (1): Last reviewed commit: "chore: refresh uv.lock for 1.90.5" | Re-trigger Greptile}