> ## Documentation Index
> Fetch the complete documentation index at: https://docs.litellm-agent-platform.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> LiteLLM Agent Platform is one service plus Postgres.

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

| Process           | Required | What it does                                                                             |
| ----------------- | -------: | ---------------------------------------------------------------------------------------- |
| `lite`            |      Yes | Serves the UI, API, gateway, MCP proxy, Slack callbacks, and session streams             |
| Postgres          |      Yes | Stores agents, sessions, credentials, runtime harnesses, schedules, memory, and settings |
| Template runtimes | Optional | Local OpenCode, OpenClaw, Deep Agents, 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:

```text theme={null}
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:

```bash theme={null}
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:

```bash theme={null}
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](/engineering/sdk-api-contract).