litellm/docker
yuneng-jiang 490c9f9f3f
fix(docker): bump wolfi-base digest for busybox 1.38.0-r1 and openssl 3.6.3-r5 (#37950)
The pinned base (built 2026-07-02) ships busybox 1.37.0-r61 and
libcrypto3/libssl3 3.6.3-r3. Grype reports 16 fixable findings against
those revisions, 8 of them High, so the image-scan gate fails once it
gets past the migration step.

The runtime stage's `apk upgrade` cannot clear them. wolfi-base writes an
exact `=version` constraint for every package it ships into
/etc/apk/world, so `apk upgrade` is a no-op even though the fixed
revisions are in the repo. Advancing them means moving the digest.

The new digest carries busybox 1.38.0-r1, libcrypto3/libssl3 3.6.3-r5
and glibc 2.43-r15, which is at or above the fix revision Wolfi's secdb
records for every finding. Verified with cosign against
chainguard-images/images release.yaml, and grype reports no fixable
findings on the rebuilt image.

CVE-2026-14456, CVE-2026-54876, CVE-2026-38752, CVE-2026-38753,
CVE-2026-38754, CVE-2026-38755
2026-08-22 11:45:39 -07:00
..
build_from_pip fix(docker): bake the pip image's prisma engines at a world-readable path (#35976) 2026-08-05 12:51:53 -07:00
tests fix(docker.non_root): use numeric UID 65534 for K8s runAsNonRoot (#26268) 2026-04-22 18:00:04 -07:00
.env.example Revert "build(Dockerfile): move prisma build to dockerfile" 2024-01-06 09:51:44 +05:30
build_admin_ui.sh chore(build): move the Admin UI toolchain to Node 24 (#35801) 2026-08-04 12:36:07 -07:00
component_entrypoint.sh fix(docker): honor USE_DDTRACE in the componentized gateway and backend images (#35490) 2026-08-01 14:12:59 -07:00
Dockerfile.database fix(docker): bump wolfi-base digest for busybox 1.38.0-r1 and openssl 3.6.3-r5 (#37950) 2026-08-22 11:45:39 -07:00
Dockerfile.non_root fix(docker): bump wolfi-base digest for busybox 1.38.0-r1 and openssl 3.6.3-r5 (#37950) 2026-08-22 11:45:39 -07:00
entrypoint.sh build: migrate packaging, CI, and Docker from Poetry to uv (#25007) 2026-04-09 11:46:23 -07:00
install_auto_router.sh build: migrate packaging, CI, and Docker from Poetry to uv (#25007) 2026-04-09 11:46:23 -07:00
prod_entrypoint.sh fix: remove separate health app 2026-05-07 16:04:56 -07:00
README.md fix(mcp): block arbitrary command execution via stdio transport 2026-04-08 19:42:37 +05:30

Docker Development Guide

This guide provides instructions for building and running the LiteLLM application using Docker and Docker Compose.

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, and prometheus services in detached mode (-d).
  • The --build flag 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_root with 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; backing PRISMA_BINARY_CACHE_DIR, NPM_CONFIG_CACHE, XDG_CACHE_HOME)
    • /app/migrations (Prisma migration workspace; backing LITELLM_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_ready marker)
    • /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 the docker-compose command from the root of the project.
  • Master key is not initialized: This error means the LITELLM_MASTER_KEY environment variable is not set. Make sure you have created a .env file in the project root with the LITELLM_MASTER_KEY defined.