litellm/docker/build_from_pip
Yuneng Jiang 44f2fdfb06
chore(deps): follow staging's resolved ddtrace and mlflow versions
The 1.91.5 lock resolved ddtrace 4.12.2 and mlflow 3.15.1, one patch ahead of
what litellm_internal_staging carries (4.11.0 and 3.15.0). The [project] ranges
on this line already match staging exactly; the drift comes from `exclude-newer`
being a relative window, so a lock resolved later picks up newer patches than one
resolved earlier. Nothing about the ranges was asking for the newer versions.

Pinned at the lock layer (`uv lock -P ddtrace==4.11.0 -P mlflow==3.15.0`) rather
than by adding constraint entries, because staging reaches these versions with no
pins of its own; adding pins here would itself be a divergence from staging.

pyproject.toml is unchanged by this commit. uv.lock moves ddtrace 4.12.2->4.11.0
and mlflow / mlflow-skinny / mlflow-tracing 3.15.1->3.15.0, and nothing else: the
17 packages this release moves now sit exactly where staging has them.

docker/build_from_pip pins ddtrace independently of the lock, so it moves to
4.11.0 alongside. That pin tracking the lock is the invariant the earlier ddtrace
commit established; without this the image would have installed 4.12.2 while the
lock resolved 4.11.0.

Supersedes the version reference in "build(deps): move ddtrace to the 4.x line",
which verified against 4.12.2. Re-verified against 4.11.0: ddtrace.trace.Tracer,
ddtrace.patch_all and ddtrace.profiling.Profiler all resolve, so the retargeted
TYPE_CHECKING import and both proxy_server call sites are unaffected. mlflow
3.15.0 declares cryptography<50,>=43.0.0, the same cap as 3.15.1, so the
override-dependencies rationale is unchanged.
2026-08-08 16:32:50 -07:00
..
Dockerfile.build_from_pip chore(deps): follow staging's resolved ddtrace and mlflow versions 2026-08-08 16:32:50 -07:00
litellm_config.yaml ci: run a local fake OpenAI endpoint instead of the shared Railway mock (#30695) 2026-06-17 17:01:13 -07:00
Readme.md (feat) - allow building litellm proxy from pip package (#7633) 2025-01-08 16:36:57 -08:00

Docker to build LiteLLM Proxy from litellm pip package

When to use this ?

If you need to build LiteLLM Proxy from litellm pip package, you can use this Dockerfile as a reference.

Why build from pip package ?

  • If your company has a strict requirement around security / building images you can follow steps outlined here