# The orchestrator

> For the complete documentation index, see [llms.txt](https://docs.lertha.com/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> One binary, one Postgres. What it embeds, how it boots, and what is deliberately ours.

The Lertha Flow is one Go binary: a durable-execution core and the web UI,
running on one Postgres, with Lertha's configuration, persistence, health, deployment and
branding. No vendor account is involved and there is no per-action bill.

The core is a dependency we bump, not code we patch, so an upgrade is a version bump and a CI
run.

```mermaid
flowchart TB
  subgraph bin["lertha-flow (one process)"]
    FE[frontend :7233]
    HI[history]
    MA[matching]
    WO[worker]
    UI[web UI :8233]
    HZ["/healthz /readyz :8234"]
  end
  PG[(Postgres<br/>main + visibility)]
  SDK[Kotlin workers and clients] --> FE
  CLI[lertha CLI] --> FE
  UI --> FE
  HI --> PG
  MA --> PG
```

## What happens on boot

1. Creates the two databases if missing and migrates each to the embedded schema version, the
   same change sets the core's schema tool applies. Idempotent.
2. Starts all four services in-process on loopback, the frontend on the bind address.
3. Starts the web UI, the Lertha build, pointed at the local frontend.
4. Serves `/healthz` and `/readyz`; `/readyz` asks the frontend's gRPC health service.
5. Registers the configured namespaces with the configured retention, if they do not exist.

Ready in about three seconds on a fresh database.

## Clients

The core's client SDKs for Java, Kotlin, Python, Go and TypeScript work unchanged. The
[`lertha` CLI](/cli) and the Kotlin port point at it with one environment variable,
`LERTHA_ADDRESS`.

## Pages

- [Configuration](/orchestrator/configuration)
- [Deploy](/orchestrator/deploy)
- [Operations](/orchestrator/operations)
- [The UI](/orchestrator/ui)