litellm - 💡(How to fix) Fix Docs: Clear guide for testing local code changes in Docker (UI + backend) [1 participants]

Feature Request

What is the motivation / use case for this feature?

When developing and testing local code fixes (e.g. a one-line bug fix in litellm/main.py or a UI change), it's very unclear how to get those changes running inside the official Docker image without a full rebuild.

The current documentation doesn't cover:

1. How to mount local Python source files into a running container so changes take effect without rebuilding the image
2. Whether to mount into /app/litellm/ or /usr/lib/python3.13/site-packages/litellm/ (they differ depending on how the image was built)
3. How .pyc bytecode caching interacts with volume mounts (stale bytecode can silently mask file changes)
4. How to rebuild and mount the Next.js UI build into the container
5. The correct PYTHONDONTWRITEBYTECODE=1 flag and when it's needed
6. How to run prisma migrate inside the container for schema changes

What is your proposed solution?

Add a "Local Development with Docker" section to the docs that covers:

• Dockerfile structure: where litellm is installed (/app/litellm/ vs site-packages)
• Volume-mounting individual .py files for quick iteration (with caveats about __pycache__)
• Building a full local image with docker build for deeper testing
• UI development: how to build the Next.js dashboard and serve it from the container
• Common pitfalls (bytecode caching, migration drift, import path resolution)

Additional context

The official image installs litellm from a wheel (/app/litellm-*.whl) into site-packages, but the package root resolves to /app/litellm/ because Python uses the working directory (/app) as the first entry in sys.path. This makes it non-obvious which path to target with volume mounts, and the behavior differs from a standard pip install layout.

This causes significant friction when trying to test a simple bug fix locally before opening a PR.