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

ProcessRequiredWhat it does
liteYesServes the UI, API, gateway, MCP proxy, Slack callbacks, and session streams
PostgresYesStores agents, sessions, credentials, runtime harnesses, schedules, memory, and settings
Template runtimesOptionalLocal OpenCode, OpenClaw, DeepAgents, or Hermes services for development and demos
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:
browser/API/Slack -> lite container -> Postgres
                         |
                         +-> model providers, MCP servers, or agent runtimes
For local development, compose.yaml starts:
  • lap, built from the root Dockerfile
  • postgres
Optional Compose profiles add local runtime services:
docker compose --profile opencode up
docker compose --profile deepagents up
docker compose --profile hermes up
docker compose --profile openclaw up
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:
docker compose up
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.