litellm/docker
ryan-crabbe-berri 27069bd74f
feat(ui): shadcn migration foundation: Tailwind v4, shadcn init, antd cascade fix (#31995)
* feat(ui): shadcn migration foundation: Tailwind v4, shadcn init, antd cascade fix

Upgrade the dashboard from Tailwind v3 to v4 with CSS-first config: the
official upgrade codemod renamed utilities across 151 files, and
tailwind.config.js (plus the dead tailwind.config.ts) is replaced by
@theme tokens, @source globs, and @plugin directives in globals.css. The
Tremor safelist becomes @source inline patterns and the legacy tremor
theme tokens carry over verbatim. ui_colors.json was build-time only and
fed the dying Tremor palette, so its brand values are inlined and the
file removed; runtime theming replaces that path next.

shadcn is initialized with a hand-authored components.json (rsc,
cssVariables, baseColor gray) pointing utils at the existing
lib/cva.config.ts, which now exports cn (cva beta cx + twMerge) instead
of adding class-variance-authority as a second variant library. The two
ad-hoc cn helpers fold into it. Button lands as the canary primitive,
adapted to cva beta and React 18 forwardRef, with tests covering the
variant, twMerge, asChild, and ref seams. --radius is 0.5rem so the
shadcn radius scale reproduces Tailwind defaults and legacy rounded-*
classes render unchanged.

antd v5 emits unlayered CSS-in-JS that would beat every layered v4
utility, so AntdGlobalProvider now wraps the app in StyleProvider layer
and ConfigProvider cssVar, and globals.css declares
@layer theme, base, antd, components, utilities. antd wins over
preflight but yields to utilities, which is what lets migrated shadcn
pages coexist with legacy antd pages. Preflight stays global with the
three v3 behaviors pinned (default border color, button cursor,
placeholder color).

* fix(ui): restore tremor opacity tints removed by tailwind v4

Tailwind v4 removed the *-opacity-* utilities, but the precompiled
@tremor/react dist still composes them with shade-500 palette classes
(bg-opacity-10 over bg-<color>-500 etc.), so Badge, BadgeDelta, Callout,
light Icon and Button, BarList, and ProgressBar lost their tints and
rendered solid 500-shade fills. Adversarial review caught it; the
original smoke pages only exercised antd Tags.

tremor-v3-compat.css restores exactly the pairs tremor emits: for each
of the 22 safelisted colors, bg-opacity-{10,20,40}, hover/group-hover
bg-opacity-{20,30}, and ring-opacity-{20,40} against the -500 shade,
via color-mix into the utilities layer. Tremor's colorPalette maps both
background and iconRing to 500, so the -500 pairing covers every
composition in the dist; dark: variants are inert until dark mode ships.
The shim dies with @tremor/react at the end of the migration.

The upgrade codemod also missed two hand-rolled modal scrims using
bg-black bg-opacity-{30,50} (solid black under v4); now bg-black/30 and
bg-black/50. Removed the docker/build_admin_ui.sh copy of
enterprise_colors.json into the deleted ui_colors.json; that build-time
rebrand path is retired and its runtime replacement lands with the
theming phase.

* fix(ui): pair ring-opacity-40 with shade 300 in tremor compat shim

Tremor's colorPalette maps ring to shade 300, and the only consumer of
ring-opacity-40 (Icon variant outlined) composes it with that shade,
so the shade-500 rows were dead and outlined icon rings would render
at full opacity. Latent today (no dashboard usage of the outlined
variant); caught by adversarial review. ring-opacity-20 stays at 500
(iconRing), matching Badge and BadgeDelta.
2026-07-02 19:02:27 -07:00
..
build_from_pip ci: run a local fake OpenAI endpoint instead of the shared Railway mock (#30695) 2026-06-17 17:01:13 -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 feat(ui): shadcn migration foundation: Tailwind v4, shadcn init, antd cascade fix (#31995) 2026-07-02 19:02:27 -07:00
Dockerfile.database build(docker): build the Admin UI from source in a build-platform-pinned stage (#31130) 2026-06-25 23:41:08 -07:00
Dockerfile.non_root build(docker): build the Admin UI from source in a build-platform-pinned stage (#31130) 2026-06-25 23:41:08 -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.