fix(docker): restore litellm-proxy-extras source dir in runtime images

[yuneng-berri]

Relevant issues

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)

Screenshots / Proof of Fix

Broken behavior, captured on the published ghcr.io/berriai/litellm:v1.90.4 image (tag commit ae0cfc0). The folder is gone:

$ 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

What makes the breakage silent: 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 -e DATABASE_URL="postgresql://postgres:...@host.docker.internal:55432/mig_before" \
    --entrypoint sh ghcr.io/berriai/litellm:v1.90.4 -c 'prisma migrate deploy --schema /app/schema.prisma'
Datasource "client": PostgreSQL database "mig_before", schema "public" at "host.docker.internal:55432"

No migration found in prisma/migrations

No pending migrations to apply.
$ echo $?
0
$ docker exec pg psql -U postgres -d mig_before -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, captured at d2a79d8 on images built locally from each of the three Dockerfiles, each run against a fresh database:

$ docker build -t litellm-pe-fix:main -f Dockerfile .
$ docker run --rm -e DATABASE_URL="postgresql://postgres:...@host.docker.internal:55432/mig_after" \
    --entrypoint sh litellm-pe-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
135 migrations found in prisma/migrations

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

The same flow passes on the database variant and on the non_root variant running as its default uid 65534: migrations dir present and readable, 135 migrations applied to a fresh database, exit 0

Beyond the migration path, the image built at d2a79d8 was run through a 41-check contract suite covering DB-less and Postgres-backed boots, the migration entrypoint, admin UI serving, key generation, and real completion and streaming calls against the Anthropic API; everything passes except the one hygiene check this change deliberately inverts (it asserted the folder's absence)

Type

🐛 Bug Fix

Changes

#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 litellm-proxy-extras folder in the runtime stage of all three Dockerfiles, matching what images up to v1.89.x contained (about 6 MB per image)

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 PR restores the /app/litellm-proxy-extras directory in the runtime stage of all three Dockerfiles, reversing a regression introduced in v1.90.0 where an allowlist-style COPY accidentally dropped the directory from published images. Without it, prisma migrate deploy exits 0 while applying nothing, silently leaving databases unmigrated.

• Adds one identical COPY --from=builder /app/litellm-proxy-extras /app/litellm-proxy-extras line to Dockerfile, docker/Dockerfile.database, and docker/Dockerfile.non_root.
• In Dockerfile.non_root the new COPY is placed before the chown -R nobody:nogroup /app block, so the restored directory picks up correct ownership and the existing LITELLM_PROXY_EXTRAS_PATH permission fixups still apply.
• The fix is minimal and surgical; the PR description includes before/after migration run evidence and a 41-check contract test suite confirming correctness across all three image variants.

Confidence Score: 5/5

Safe to merge — the change adds a single, well-placed COPY line to each of the three Dockerfiles, restoring a directory that was accidentally dropped and causing silent migration failures.

The fix is a one-line COPY restoration in each Dockerfile, correctly positioned before the chown/permission blocks in the non-root variant so ownership is handled automatically. The PR description includes concrete before/after evidence of the silent migration failure being resolved, and a 41-check integration suite confirms all three image variants behave correctly. No logic changes, no new code paths, and no custom rules are implicated.

No files require special attention.

Important Files Changed

Filename	Overview
Dockerfile	Adds one COPY line to restore /app/litellm-proxy-extras in the runtime stage; positioned before existing chown/permission blocks, no ownership gap.
docker/Dockerfile.database	Identical one-line COPY restoration as the main Dockerfile; consistent placement relative to Prisma cache copy blocks.
docker/Dockerfile.non_root	Same COPY line added before the chown -R nobody:nogroup /app block, so the new directory inherits correct nobody:nogroup ownership and the existing LITELLM_PROXY_EXTRAS_PATH permission fixups still apply.

_{Reviews (2): Last reviewed commit: "chore(ci): drop image-scan migration-ass..." | Re-trigger Greptile}

[greptile-apps]

CI assertion covers only one of three patched Dockerfiles

The new assertion validates migration assets only in the Dockerfile.non_root image. The main Dockerfile and docker/Dockerfile.database each received the same COPY line, but neither is built nor tested here. The paths: trigger for this workflow also omits Dockerfile and docker/Dockerfile.database, so a future regression in those files would never run this check. If the COPY line is accidentally dropped from the main Dockerfile again, the silent migration failure that motivated this fix could recur undetected.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[yuneng-berri]

@greptile

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_/docker-allowlist-denylist-pr-4b26e6 (b55fcd9) with litellm_internal_staging (2162da5)}