* feat(ui): adopt the new LiteLLM logo and monogram Swap the bundled admin UI logos for the new brand assets: the primary logo in blue for light mode and white for dark mode, and the monogram for the collapsed sidebar, favicons, and the built-in guardrail cards. /get_image gains a variant=monogram query parameter so the collapsed sidebar can request the monogram while admin-configured UI_LOGO_PATH / UI_LOGO_PATH_DARK logos still take precedence. The bundled light logo moves from JPEG to a transparent PNG. * test(ui): query collapsed sidebar logos by role to stay within the lint budget * fix: point remaining logo consumers at the new bundled assets The Rust gateway UI served /get_image from the removed litellm_logo.jpg, the non-root get_image tests pinned logo.jpg, and a cookbook script read litellm/proxy/logo.jpg. Point them at the monogram and logo.png. * fix(mcp): serve the BYOK OAuth page logo from /get_image The page pointed at /ui/assets/logos/litellm_logo.jpg, which the rebrand removes from the dashboard sources, so the next UI build would drop it. /get_image?variant=monogram is always served by the proxy and follows any admin-configured logo. * fix(ui): invert the LiteLLM monogram on dark guardrail cards The blue monogram has a transparent train cut-out, so on a dark card it read as a muddy blue block. Inverting it yields the brand's white mark, which the logo guidelines prescribe for dark backgrounds. * fix(gateway-ui): serve theme and variant aware logos from the dashboard export The Rust gateway served one monogram for every /get_image request, and the committed export lacked it, so /get_image returned 404 until the next UI release build. Pick the full or monogram logo in light or dark from the query, ship those assets in the dashboard's public dir and the committed export, and drop two comments that restated asserted paths. |
||
|---|---|---|
| .. | ||
| build_from_pip | ||
| tests | ||
| .env.example | ||
| build_admin_ui.sh | ||
| component_entrypoint.sh | ||
| docker-compose.quickstart.yml | ||
| Dockerfile.database | ||
| Dockerfile.non_root | ||
| entrypoint.sh | ||
| install_auto_router.sh | ||
| prod_entrypoint.sh | ||
| README.md | ||
Docker Development Guide
This guide provides instructions for building and running the LiteLLM application using Docker and Docker Compose.
Just want to run LiteLLM? This guide builds from source. To run the published image instead, use
docker-compose.quickstart.ymlin this directory — the two-service stack (gateway + Postgres) that the Docker quickstart documents:curl -sSLO https://github.com/BerriAI/litellm/raw/main/docker/docker-compose.quickstart.yml printf 'LITELLM_MASTER_KEY=sk-%s\nLITELLM_SALT_KEY=sk-%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env docker compose -f docker-compose.quickstart.yml up -d
Prerequisites
- Docker
- Docker Compose
Building and Running the Application
To build and run the application, you will use the docker-compose.yml file located in the root of the project. This file is configured to use the Dockerfile.non_root for a secure, non-root container environment.
1. Set the Master Key
The application requires a LITELLM_MASTER_KEY for signing and validating tokens. You must set this key as an environment variable before running the application.
Create a .env file in the root of the project and add the following line:
LITELLM_MASTER_KEY=your-secret-key
Replace your-secret-key with a strong, randomly generated secret.
2. Build and Run the Containers
Once you have set the LITELLM_MASTER_KEY, you can build and run the containers using the following command:
docker compose up -d --build
This command will:
- Build the Docker image using
Dockerfile.non_root. - Start the
litellm,litellm_db, andprometheusservices in detached mode (-d). - The
--buildflag ensures that the image is rebuilt if there are any changes to the Dockerfile or the application code.
3. Verifying the Application is Running
You can check the status of the running containers with the following command:
docker compose ps
To view the logs of the litellm container, run:
docker compose logs -f litellm
4. Stopping the Application
To stop the running containers, use the following command:
docker compose down
Hardened / Offline Testing
To ensure changes are safe for non-root, read-only root filesystems and restricted egress, always validate with the hardened compose file:
docker compose -f docker-compose.yml -f docker-compose.hardened.yml build --no-cache
docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d
This setup:
- Builds from
docker/Dockerfile.non_rootwith Prisma engines and Node toolchain baked into the image. - Runs the proxy as a non-root user with a read-only rootfs and only writable tmpfs mounts:
/app/cache(Prisma/NPM cache; backingPRISMA_BINARY_CACHE_DIR,NPM_CONFIG_CACHE,XDG_CACHE_HOME)/app/migrations(Prisma migration workspace; backingLITELLM_MIGRATION_DIR)
- Pre-builds and serves the admin UI from read-only paths:
/var/lib/litellm/ui(pre-restructured Next.js UI with.litellm_ui_readymarker)/var/lib/litellm/assets(UI logos and assets)
- Routes all outbound traffic through a local Squid proxy that denies egress, so Prisma migrations must use the cached CLI and engines.
You should also verify offline Prisma behaviour with:
docker run --rm --network none --entrypoint prisma ghcr.io/berriai/litellm:main-stable --version
This command should succeed (showing engine versions) even with --network none, confirming that Prisma binaries are available without network access.
Troubleshooting
build_admin_ui.sh: not found: This error can occur if the Docker build context is not set correctly. Ensure that you are running thedocker-composecommand from the root of the project.Master key is not initialized: This error means theLITELLM_MASTER_KEYenvironment variable is not set. Make sure you have created a.envfile in the project root with theLITELLM_MASTER_KEYdefined.