Navin Manager overview
The Navin Manager (package navin-manager) is the management console of the Navin Enterprise AI platform. It installs, configures, starts,
stops, restarts, checks, debugs and clusters every service the platform uses (LiteLLM, OPA, OpenFGA,
Keycloak, OpenBao, Redis, OpenSearch, Qdrant, ClickHouse, SeaweedFS, Prometheus, Alertmanager, Jaeger, NATS, Temporal,
LiveKit, Opik, Ragas and the Navin Enterprise components) on bank hosts running Red Hat Enterprise Linux, Rocky
Linux, AlmaLinux, Oracle Linux, CentOS Stream, Ubuntu or Debian, connected to the Internet or fully offline.
It follows the principles of Apache Ambari (a stack catalog, a cluster install wizard, a host agent, versioned configurations, operations split into stages and tasks, alerts) with the Navin design and a security model built for banks.
The interactive architecture diagram is in architecture.html (source: assets/architecture.json).
Building blocks
| Block | Role |
|---|---|
Server (navin-manager serve) | REST API /api/v1, web console, operations engine, alert evaluation, scheduler. Port 8460. |
| Agent API | Endpoint of the host agents /agent/v1 and the local mirror /repo/. Port 8461, TLS with a client certificate in production. |
Agent (nm-agent) | Runs on every managed host as a systemd service. It opens every connection (no listening port on the host), runs the tasks of the server one at a time and reports facts, metrics and component states. |
| Manager database | PostgreSQL provided by the bank (separate cluster). navin-manager only connects to it. |
| Stack catalog | One descriptor per service: parameters, cluster modes, components, files, health checks, commands. |
| Offline mirror | Artifacts, container images and Python wheels with their sha256, built once outside the bank and copied in. |
Concepts
Cluster. A set of hosts managed together, in production, preprod, test, development or sandbox mode.
Development, test and sandbox clusters accept the services reserved for tests (for example a local PostgreSQL);
production and pre-production clusters refuse them.
Host. A machine registered by its agent with a bootstrap token. The server keeps its facts (operating system, CPU, memory, disks, SELinux, firewall, clock, Python, Podman, GPU) and evaluates the preflight checks as soon as the facts arrive.
Service, component, mode, method. A service of the catalog (for example Redis) has components (server, sentinel), cluster modes (standalone, replication, sentinel, cluster) with placement rules (minimum, maximum, odd number for a quorum, multiple of a replication factor) and installation methods:
| Method | How the component runs |
|---|---|
binary | Official release archive verified by sha256, run by a hardened systemd unit. |
podman | Official image pinned by digest, run by systemd on the isolated cluster network (declared ports published, --network host only when justified), no-new-privileges and SELinux labels; Quadlet rendering available (hardened installation). |
python | Virtual environment installed from the offline wheelhouse. |
package | Packages of the operating system or of the vendor repository mirrored by the bank. |
Binding. A service that needs another one (LiteLLM needs PostgreSQL and Redis) gets a binding: either a service managed in the cluster, or an external connection to a cluster the bank already runs. Templates see the same shape in both cases, so the choice never changes the configuration files. Multi-tenant providers (PostgreSQL, MySQL, ClickHouse, SeaweedFS) give each consumer its own database, user or bucket, with a secret derived from the master key and never stored.
Foundation service. SeaweedFS is the object store of the platform: documents, media, exports, backups and the
WORM audit archive go there, and it is the store meant for skills and MCP servers. Navin Enterprise and Opik bind
to it. It is installed by default: the
install wizard selects it in a cluster that does not have it yet, and adds it as soon as a selected service needs it.
Clear it only to bind an existing S3 store of the bank instead (a connection of type s3).
Configuration. Every change creates a version (who, when, note). Versions can be compared and restored. A config group overrides parameters for some hosts. The advisor recommends values from the host facts (for example a JVM heap of half the memory, capped at 31 GB). Hosts whose running configuration is older than the current version are marked: a restart applies it.
Operation. Every action (install, start, rolling restart, configuration apply, custom command, decommission) is an operation made of ordered stages; a stage runs one task per host in parallel. Logs are streamed live, failed operations can be retried from the failed stage, running operations can be aborted.
Alert. Built in definitions watch hosts (heartbeat, disk, memory, load, prerequisites), components (down, health checks failing, restart required), certificates, failed operations and the manager itself. Alerts resolve by themselves when the condition clears and notify email, webhook or syslog targets.
PostgreSQL
PostgreSQL is always installed by the bank, in a separate cluster: the manager database and the databases of the platform services are external connections. navin-manager installs a PostgreSQL only in a sandbox cluster, for quick tests.