Introduction
The Navique AI Core Operator is a Kubernetes operator that deploys and manages a complete, governed, self-hosted AI platform end-to-end. Applying its custom resources stands up the LiteLLM gateway, the LibreChat chat UI, Langfuse LLM observability, their datastores, and the secrets plumbing — and installs any upstream capability operators it needs along the way.
It is built with the Operator SDK (Go / Kubebuilder). Upstream operators are installed by driving their official Helm charts, bundled inside the operator binary and applied with the Helm v4 Go SDK from inside the reconcilers.
The problem it solves
The platform was previously delivered as a tree of Helm charts orchestrated by ArgoCD. That works, but it couples concerns that should be separate:
- Capability operators (CloudNativePG, External Secrets, cert-manager…) and the workloads that depend on them get tangled into the same chart graph.
- A singleton operator pulled in as a subchart of two different releases ends up with two releases fighting over the same CRDs (Helm refuses shared CRD ownership).
- Provisioning order is expressed as global sync waves rather than as the actual readiness of each dependency.
- Credentials end up committed to git in chart values.
The operator untangles all of this. You declare the platform as Kubernetes objects; the operator converges the cluster to match — lazily installing capability operators, provisioning datastores, wiring credentials between components, and surfacing precise status conditions at every step.
What it does, in two layers
The operator deliberately separates the two layers that the Helm charts mixed:
It installs upstream capability operators — LiteLLM, Langfuse, External Secrets, Sealed Secrets, CloudNativePG, cert-manager, the Redis operator, the ClickHouse operator, and the MongoDB controllers — by driving their official Helm charts. Each chart is a standalone Helm release (never a subchart dependency), installed provenance-aware: it is skipped and adopted if you already installed it, and uninstalled only when the operator owns it and nothing needs it anymore.
It manages the platform workloads through its own CRDs, by emitting the upstream custom resources (
LiteLLMInstance,LangfuseInstance, CNPGCluster/Database, ESOSecretStore/ExternalSecret, …) and installing the LibreChat workload chart.
See How It Works for the architecture, and Core Concepts for the vocabulary.
What you get
| Custom resource | Brings up |
|---|---|
License | Cluster-wide license; gates enterprise features and instance caps |
SecretsManagement | External Secrets or Sealed Secrets credential backend |
PostgresCluster | PostgreSQL via CloudNativePG (managed), or adopt/external |
ClickHouseCluster | ClickHouse (managed), or adopt/external |
RedisInstance | Redis via the OT-Container-Kit operator, or adopt/external |
MongoCluster | MongoDB via the MCK operator, or adopt/external |
MeilisearchInstance | Meilisearch search backend (operator-native) |
Gateway | LiteLLM AI gateway + models / teams / orgs |
Observability | LLM observability (Langfuse v3) |
ChatUI | LibreChat web UI, wired to a Gateway |
ManagementPlane | Configures the admin console (deployed by default) |
Design principles
- Per-component CRDs, no umbrella. Each capability is its own resource. An optional
Stacksits on top for one-shot bundles, but the granular resources remain a first-class way to compose by hand. - Standalone bundled charts. Every capability operator is its own Helm release, installed once and shared — never a subchart dependency.
- Provenance-aware. The operator never re-installs or deletes an operator you installed yourself; it cleans up only what it owns. See Provenance & Lifecycle.
- External-first datastores. Any datastore can be operator-managed, adopted from an existing in-cluster resource, or pointed at an external host.
- Secrets are never inline. Credentials come from Key Vault (via External Secrets) or Sealed Secrets. See Secrets Management.
- Idempotent and readiness-driven. Reconcilers requeue while waiting on readiness rather than erroring; every apply is a safe install-or-upgrade.
Who it is for
- Platform teams standing up a governed, multi-tenant AI gateway and chat UI on Kubernetes — on AKS, EKS, GKE, OpenShift, or on-prem (including air-gapped).
- Regulated organizations that need self-hosting, observability, SSO, and a data-path guardrail for PII.
- Anyone evaluating the open-source core: the free edition deploys a complete single-instance platform with no license at all.
Licensing in one paragraph
The operator core is open source under AGPL-3.0 and runs fully without a license (the Community edition). Enterprise increments — extra instances, multi-tenancy, cross-component auto-wiring, SSO/SCIM, the PII guardrail — unlock with a signed, offline license verified against a public key compiled into the binary. There is no license server and no phone-home, so it works air-gapped. On expiry the platform gracefully downgrades to Community rather than going dark. See Editions & Licensing.
Next steps
- How It Works — the architecture and reconcile model.
- Core Concepts — provenance, modes, auto-wiring, and the terms used throughout these docs.
- Quick Start — bring up a full platform on a cluster.