This page introduces Kumoss’s runtime components and how they fit together. The rest of this section goes deeper: the end-to-end request flow, the data and state each component owns, and the deployment topology.
Overview
Pan, zoom, search, trace a relationship, switch themes. Open in a new tab
Dashed edges are wiring that exists but is not exercised by the checked-in
config.yaml: the identity provider is contacted only once
oidc.issuer_url is set.
The diagram condenses some detail. The four sidecars share one node
(authz :8083, mapping :8081, iac :8082, notifications :8080); the
core appears as its API layer plus a single "application and adapters" node
covering the other three layers; and Redis, the workspaces volume,
phoenix-db and the notification and storage backends are carried in the
notes beside it rather than drawn. Phoenix is reachable through the proxy at
/monitoring/, artifacts land in the kumoss-artifacts bucket, and the
shipped configuration routes model calls through LiteLLM.
Component responsibilities
| Component | Responsibility | Main relationships |
|---|---|---|
React SPA ( |
Session wizard, planning and results views, user page and admin panel. An
OIDC public client: it calls |
Built into the Nginx image; reaches the API through Nginx, and the identity provider directly for login |
Nginx ( |
Sole public entry point, on ports 80 and 9000: serves the built SPA and
proxies |
Browser → core, Phoenix, object storage |
Core API layer ( |
Routes every request: IaC operations, the progress stream, session reads, repository and pull-request actions, identity and roles, the admin panel, and passthroughs to the mapping and notifications sidecars. One authentication dependency guards all of them but the public OIDC configuration. |
Delegates to application handlers |
Application layer ( |
The generate, drift and apply handlers, and the services they orchestrate — filtering, reporting, pull requests, session orchestration. A factory builds a fresh object graph per run. |
Composes domain services |
Domain layer ( |
Entities, value objects and ports, and the services holding the behaviour: the agent loop, session and user management, validation, targeting, the compliance audit, artifact storage, persistence and tracing. |
Depends only on interfaces |
Infrastructure layer ( |
Adapters behind those ports: OIDC, the LiteLLM router, git and workspaces,
the iac-sidecar driver, Jinja layouts, object storage, PostgreSQL, Redis
and OpenTelemetry. The generated sidecar clients are not part of this
layer — they live in |
Implements domain ports |
authz service |
Cloud project access checks, disabled by default. Disabled, the core answers "authorized" without calling it; enabled, an unreachable sidecar is an error, never an allow. Its user and role endpoints are unused — Kumoss keeps those in core-db. |
Called from the authorize route with the caller’s identity; container-local JSON role store |
iac service |
Runs one IaC engine command per asynchronous job — |
Shares the |
mapping service |
Resolves a business identifier to a repository URL, plus a best-effort
terraform provider and cloud scope ( |
Called through a core passthrough route |
notifications service |
Channel-agnostic notify contract; the reference implementation posts colour-coded Slack webhook messages. |
Fire-and-forget from the core on compliance, apply and pipeline failures; request/response for the support requests the header’s chat bubble sends |
OpenAPI contracts ( |
Source of truth for the four sidecar APIs, with Schemathesis conformance suites. |
Contracts → generated clients → sidecars |
core-db (PostgreSQL 17) |
System of record: thirteen tables covering users, sessions, workspaces, rounds, plans, pull requests, reports, compliance checks and artifacts. |
Core, over asyncpg |
Redis 8 |
Fail-open cache for session facts, the last status and finished-session aggregates. No pub/sub, no locks. |
Core only |
object-storage (RustFS, Apache-2.0) |
Default, bundled artifact store ( |
Core through the SDK, browser through Nginx :9000, and the iac sidecar for state |
|
Per-run git clones under |
Mounted by core and iac |
Phoenix + phoenix-db |
OpenTelemetry trace collector and UI, and the prompt registry seeded at core boot. |
Core, over OTLP/HTTP and the Prompts API |
OIDC identity provider |
Authenticates users and issues the JWT access tokens the core validates. Any provider with discovery, JWKS and JWT access tokens works; Entra ID, Keycloak, Auth0 and Okta are documented. |
Browser for login, core for discovery and JWKS; configured under |
LLM providers |
Model inference behind the LiteLLM router, in a main and a small role. |
Selected by |
Git hosting |
Clone and push over the git CLI; pull requests through the GitHub, Azure
DevOps or GitLab REST APIs. Public SaaS hosts only — |
Selected by |
How to read the rest of this section
-
End-to-end flow — the ten phases of one generate session, from the request to the applied infrastructure, and the mechanisms behind them.
-
Data and state — what core-db, phoenix-db, Redis, object storage, and the
workspacesvolume each hold. -
Deployment view — the Compose topology, operational notes, and single-instance limits.