Skip to main content
LiteLLM Agent Platform is intentionally small:
  • One Docker image runs the lite service.
  • One Postgres database stores persistent state.
  • Everything else is either an upstream API call or an optional runtime profile.
The lite service serves the dashboard, REST API, LiteLLM-compatible gateway routes, MCP proxy routes, Slack callbacks, and runtime event streams from the same process.

​
What Runs

The LiteLLM gateway is not a separate deployment. It is part of the same lite service.

​
Docker Shape

The repository has one main Dockerfile. It builds the static UI, builds the Rust lite binary, and packages both into one runtime image:
For local development, compose.yaml starts:
  • lap, built from the root Dockerfile
  • postgres
Optional Compose profiles add local runtime services:
Those profiles are conveniences. They are not required to run LAP.

​
Request Flow

  1. A user opens the dashboard, calls the REST API, or talks to a connected Slack app.
  2. The request reaches the lite service.
  3. LAP reads or writes state in Postgres.
  4. If the request needs a model, MCP server, or agent runtime, LAP calls that upstream service.
  5. Runtime events stream back through the same lite service to the UI or API client.

​
Local stack

The smallest local stack is:
That starts LAP and Postgres. Add a runtime profile only when you want a local template runtime registered automatically.

​
Implementation details

For the normalized runtime SDK contract, see Internal SDK contract.