chore(release): backport #33853 to stable/1.90.x and cut 1.90.6

[yuneng-berri]

Relevant issues

Backports the Docker prisma bake onto stable/1.90.x and cuts 1.90.6. The runtime image previously shipped the prisma CLI and engines under /root/.cache, the default HOME-derived prisma-python cache location, so any deployment whose runtime HOME is not /root (kubernetes runAsUser, docker --user, HOME overrides) missed that cache on a fresh database, fell back to a nodeenv Node download that crashes on Wolfi, and started the proxy with zero tables while every DB-backed endpoint returned 500. The bake now lives at /opt/prisma, a path no HOME resolution or cache volume mount can shadow. Relates to #33650 and #24554, both already fixed on the development line by #33853

This PR also carries routine dependency maintenance on the line's lock file, and the version bump to 1.90.6

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 unit tests on make test-unit
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

The picked commit carries no new tests because it changes only Dockerfiles; its correctness is proven by the live container run below, which is the meaningful test for this class of change. The unit-test box reflects a zero-regression delta against this line's pre-change baseline, measured as described below rather than as an absolute pass

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

The prisma bake, proven against a live container

Both images were built locally from a clean git archive of this branch, so the build context matches what CI would send. The pick's own build-time assertions are &&-chained into a RUN, so a drifted layout fails the build rather than silently degrading at container start; both builds passed them.

The claim is that a fresh-database migration now works for any runtime uid with no network. That was exercised directly: a brand new Postgres with zero tables, on a Docker network created with --internal, with the container running as uid 12345 and HOME pointed at a path that does not exist.

Confirming the network really has no egress, from inside that network:

$ docker run --rm --network bp190x-net --entrypoint python3 litellm-bp190x:post-database -c "...socket.create_connection(('registry.npmjs.org', 443))"
no internet, as intended: gaierror

Then the migration itself:

$ docker run --rm --network bp190x-net --user 12345 -e HOME=/nonexistent \
    -e DATABASE_URL="postgresql://postgres:***@bp190x-pg:5432/litellm" \
    --entrypoint sh litellm-bp190x:post-database \
    -c 'cd /app/litellm-proxy-extras/litellm_proxy_extras && "$PRISMA_CLI_PATH" migrate deploy --schema ./schema.prisma'
...
All migrations have been successfully applied.

Verified against the database rather than trusting the exit message:

$ docker exec bp190x-pg psql -U postgres -d litellm -tAc \
    "SELECT count(*) FROM information_schema.tables WHERE table_schema='public';"
66
$ docker exec bp190x-pg psql -U postgres -d litellm -tAc \
    "SELECT count(*) FROM _prisma_migrations WHERE finished_at IS NOT NULL;"
127

The baked CLI also resolves and runs under the same conditions, which is the specific thing that used to fall through to an npm download:

$ docker run --rm --network none --user 12345 --entrypoint sh litellm-bp190x:post-default \
    -c 'test -x "$PRISMA_CLI_PATH" && echo "CLI executable: yes"; HOME=/nonexistent "$PRISMA_CLI_PATH" --version'
CLI executable: yes
prisma                : 5.4.2

Both runtime images expose the pinned paths (PRISMA_CLI_PATH=/opt/prisma/binaries/node_modules/.bin/prisma, PRISMA_BINARY_CACHE_DIR=/opt/prisma/binaries, PRISMA_CLI_QUERY_ENGINE_TYPE=binary, PRISMA_OFFLINE_MODE=true), and the database image ships the proxy-extras schema with 128 migration entries at the source path the migration job targets.

The dependency bumps, measured as a delta

Each bumped package resolves to its target in a synced environment: starlette 1.3.1, python-multipart 0.0.30, mcp 1.28.1, pydantic-settings 2.14.2, pypdf 6.13.3.

The mirrored suite on this line is order-dependent under parallel execution, so a single run's failure set is not a reliable signal. The suite was therefore run once before the bumps and twice after, with byte-identical commands:

before bumps: 69 failed, 24080 passed, 94 skipped, 2 errors
after  (1):   66 failed, 24083 passed, 94 skipped, 2 errors
after  (2):   65 failed, 24083 passed, 95 skipped, 2 errors

Comparing a single post-bump run against the baseline suggests 6 new failures in run 1 and 1 in run 2, but the two post-bump sets disagree with each other despite identical inputs, and every one of those tests passes when run on its own. Intersecting the two post-bump runs and subtracting the baseline, which is the set of failures that actually reproduce and are genuinely new, gives zero

Known noise on this line

The pre-change baseline already fails 71 distinct tests, so absolute red on this branch is not meaningful and only the delta above is. Collecting the whole tests/test_litellm tree in one run also needs --import-mode=importlib, because tests/test_litellm/models/test_models.py and tests/test_litellm/proxy/client/test_models.py share a basename with no __init__.py. Both conditions predate this PR and also exist on the development line

One new behavior worth flagging for reviewers: starlette 1.3.x deprecates using httpx with starlette.testclient and emits StarletteDeprecationWarning recommending httpx2. It is a warning only, it does not affect the shipped proxy, and no test fails on it, but it will start appearing in test output on this line

Type

🐛 Bug Fix
🚄 Infrastructure

Changes

In merge order:

• fix(docker): bake prisma CLI and engines at a fixed path so fresh-DB migrations work for any uid offline #33853 fix(docker): bake prisma CLI and engines at a fixed path so fresh-DB migrations work for any uid offline
• chore(deps): bump starlette to 1.3.1
• chore(deps): bump python-multipart to 0.0.30
• chore(deps): bump mcp to 1.28.1
• chore(deps): bump pydantic-settings to 2.14.2
• chore(deps): bump pypdf to 6.13.3
• bump: version 1.90.5 to 1.90.6, and the matching uv.lock refresh

The cherry-pick is byte-identical to its source on the development line: git patch-id --stable returns 730c2276e12028cb46121514058d047d0f27acc3 for both, and git range-diff shows no difference beyond the added (cherry picked from commit ...) footer. No adaptation was needed, and the pick changes no Python source, so the whole branch diff is Dockerfile, docker/Dockerfile.database, pyproject.toml and uv.lock

Every dependency move is lock-only, each one confirmed to move exactly one package in uv.lock by parsing both lock files rather than reading the diff. The lock was regenerated with uv 0.11.7, the version this line's Dockerfile pins, so the lock format revision is unchanged. No pyproject.toml dependency floor changed, so the wheel's install contract is untouched and only the image's resolved versions move

#33592 was requested but is already present on this line; it shipped in 1.90.5 as f0b7d8d

#33721 and #33864 were requested and are deliberately excluded. Together they regress GET /v1/models: a deployment whose model_info carries a non-numeric token limit is registered into the model cost map by the router, which reaches an unguarded int() in the cost-map branch of create_model_info_response and turns the whole listing into a 500, where this line currently returns 200 and omits that deployment's limits. #33864 hardened the router index path but not the cost-map path. The fix belongs on the development line first and can then be backported alongside both PRs, so stable/1.90.x keeps parity with stable/1.91.x and stable/1.92.x, which excluded the same pair

[greptile-apps]

Greptile Summary

This backport cherry-picks the Docker Prisma bake fix (#33853) onto stable/1.90.x and cuts version 1.90.6, accompanied by lock-only dependency bumps (starlette, python-multipart, mcp, pydantic-settings, pypdf) and a uv.lock refresh.

• The core fix redirects the Prisma CLI and query-engine cache from the HOME-derived /root/.cache to the fixed path /opt/prisma at image build time, then pins it via PRISMA_BINARY_CACHE_DIR, PRISMA_CLI_PATH, and PRISMA_OFFLINE_MODE=true env vars in the runtime stage. This ensures fresh-database migrations succeed for any runtime uid, with no network access required.
• Both Dockerfile and docker/Dockerfile.database receive identical changes, and each runtime layer includes &&-chained test assertions (test -x … prisma, test -f … index.js) so a broken layout fails the build rather than silently degrading at container start.

Confidence Score: 5/5

The change is safe to merge: it touches only Dockerfiles, pyproject.toml, and uv.lock, with no Python source changes, and includes build-time assertions that would fail the image build if the binary layout drifted.

The Prisma path migration is mechanically correct in both images: the build-stage override records the fixed path into the generated client, the runtime ENV block ensures all processes see the same paths regardless of uid or HOME, and chmod -R a+rX /opt/prisma makes the tree readable and traversable by non-root uids before the test -x guard fires. The dependency updates are lock-only with no pyproject.toml floor changes. No Python logic was touched.

No files require special attention.

Important Files Changed

Filename	Overview
Dockerfile	Redirects Prisma CLI and engine cache from HOME-derived /root/.cache to the fixed path /opt/prisma at build time; sets runtime env vars (PRISMA_BINARY_CACHE_DIR, PRISMA_CLI_PATH, PRISMA_OFFLINE_MODE) and adds build-time assertions to verify the binary layout before the image is sealed.
docker/Dockerfile.database	Applies identical Prisma bake changes as the main Dockerfile; migrates from /root/.cache/prisma to /opt/prisma with the same runtime env vars and build-time assertions. Uses a different Wolfi base image SHA, which is pre-existing and intentional for this variant.
pyproject.toml	Version bump from 1.90.5 to 1.90.6 in both the [project] table and [tool.commitizen] section; no dependency floor changes.

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