Misleading comment vs actual implementation

The block comment says --userconfig /dev/null bypasses .npmrc but the actual code does not use --userconfig /dev/null — it uses mv .npmrc .npmrc.bak / mv .npmrc.bak .npmrc to temporarily rename the file. The comment describes a hypothetical approach that was not implemented, which will confuse future maintainers.

Consider either:

1. Update the comment to accurately describe the file-renaming approach used, or
2. Replace the mv dance with the simpler --userconfig /dev/null flag directly on npm install -g and npm ci:

npm install -g [email protected] --userconfig /dev/null && npm cache clean --force && \
...
npm ci --userconfig /dev/null && \

This is cleaner, avoids renaming state that could be lost if the build fails partway through, and matches what the comment claims.

Base image remains unpinned by digest

Every other Dockerfile in this PR now pins its base image to a @sha256:... digest for supply-chain safety, but Dockerfile.custom_ui still uses an unqualified mutable tag (litellm_fwd_server_root_path-dev). The added comment acknowledges this but offers no plan. A floating dev tag is exactly the kind of unpinned surface the PR is trying to eliminate.

If the tag intentionally tracks a moving branch build, consider at minimum documenting how to refresh the digest (e.g. docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/berriai/litellm:litellm_fwd_server_root_path-dev) and adding it to a CI step that pins it after each new push to that branch.

HEALTHCHECK tests argument parsing, not actual connectivity

CMD python /app/health_check_client.py --help || exit 1 only verifies that Python can load the script and parse --help. It will pass even if the health-check client cannot reach the LiteLLM server, cannot import a required network library, or is fundamentally misconfigured.

A more meaningful check would execute the script against a known endpoint (e.g., with a --url flag and a short --timeout), or at minimum verify all imports succeed without hitting the network:

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD python -c "import health_check_client" || exit 1

Even that only tests imports, but it's more meaningful than --help. Ideally the check should do a lightweight connectivity probe against the configured target.

Redundant Python-version markers on identical grpcio pins

Both conditions now pin grpcio to exactly 1.80.0, so the python_version markers serve no purpose. This is functionally equivalent to a single unconditional line and creates a maintenance trap where someone could change only one of the two entries in the future, reintroducing version divergence.

The same redundancy exists in pyproject.toml:

grpcio = [
    {version = "1.80.0", python = "<3.14", optional = true},
    {version = "1.80.0", python = ">=3.14", optional = true},
]

which can be collapsed to a single entry.

hf-xet may not be installable on all platforms

hf-xet is a Rust-compiled extension that ships manylinux (glibc) and macOS wheels but typically does not provide musl/Alpine wheels. Pinning it in requirements.txt is fine for the glibc-based Wolfi images, but if this file is ever used on Alpine (musl) or Windows hosts — including developer machines — pip install -r requirements.txt will fail with "No matching distribution found."

Consider adding a platform marker to restrict the pin to supported platforms:

Or, since hf-xet is an optional performance plugin for huggingface_hub, verify that dropping it from requirements.txt and letting it be installed implicitly only where available is acceptable.

--no-deps for aiobotocore in CI installs the package without its pinned botocore range

The CI install command mirrors the Dockerfile workaround, but it uses a plain pip install --no-deps rather than the wheel-based approach. In CI, when aiobotocore==2.25.1 is installed with --no-deps, it is placed alongside botocore==1.42.80 (transitively required by boto3==1.42.80). aiobotocore==2.25.1 has a declared botocore requirement of approximately botocore==1.36.x; using 1.42.x skips a significant number of botocore internal API changes.

Any test that exercises aiobotocore (async S3, async SageMaker) against this environment runs against a botocore version that aiobotocore was never tested with. Failures would appear as AttributeError or incorrect service calls rather than dependency errors, making them hard to diagnose.

This appears at two separate CI job definitions:

• Command step (line ~36)
• mypy job (line ~97)

Consider also pinning a botocore version in the pip install line that is known to be compatible with aiobotocore==2.25.1, or explicitly installing a boto3 version whose bundled botocore is within aiobotocore's tested range.

@yuneng-berri why not have this be the same version 46.0.5?

@yuneng-berri pyproject.toml is not an appropriate place for a library to pin exact dependency versions, because these are enforced on all downstream consumers of the PyPI package. Downstream consumers often use these same transitive dependencies in other ways with different version requirements, and need the ability to upgrade them independently. Such conflicts either prevent those consumers from upgrading litellm, or prevent those consumers from upgrading any of these dependencies, perhaps causing them to miss future security patches.

• [Bug]: python-dotenv pinned to ==1.0.1 since v1.83.1 causes dependency conflicts for library consumers #25210
• [Bug]: Dependency pinning in commit #5f63873 — intentional change? #25280

The appropriate place for these pins is poetry.lock, or now uv.lock.