Installation and operations
NomOS runs on Kubernetes and is installed with a Helm chart. The reference installation runs on AWS EKS in the Zurich region. Other Kubernetes environments are intended but not yet proven as an installation. A SaaS offering operated by Ainomos is planned.
Components
Section titled “Components”| Part | Job |
|---|---|
brain-core |
Backend with rooms, knowledge, rules, evidence, and the MCP server |
web-ui |
Interface for chat, rooms, rules, inbox, and administration |
| Worker | Scheduled jobs such as Dreaming, log shipping, and maintenance |
| Keycloak | Sign-in, or the connection to your own OIDC or SAML identity provider |
| OPA | Access decisions for rooms |
| Presidio | Personal data detection |
| LiteLLM | Gateway for every model call, with cost per room |
| Valkey | Cache |
You provide a PostgreSQL 16 database with the pgvector extension.
Models
Section titled “Models”Every model call goes through the gateway. The default is Amazon Bedrock with EU inference profiles.
- Your own models for answers: platform admins register additional models with an OpenAI-compatible interface in the model catalogue, for example locally hosted ones. Each model carries a location (in the cluster, in your cloud, or external) and the data classes it may process.
- Background jobs and search: Dreaming and some checks use fixed Claude models today, and search uses the Titan embedding model. Letting an installation choose its own models for these is planned.
Sign-in and emergency access
Section titled “Sign-in and emergency access”NomOS uses the installation’s identity provider. If sign-in through the identity provider fails, a separate emergency access keeps admins from being locked out.
Signing key
Section titled “Signing key”Signed evidence needs an Ed25519 key. Create it as a secret and manage it separately from the database. The public half is used to verify the records.