Skip to main content
NeuralTrust ships as a single umbrella Helm chart, neuraltrust-platform, with one value selecting the topology:
Pick the model first. It changes what you install, what you have to create beforehand, and whether you need the NeuralTrust console at all. Each model then has one page that takes you from architecture to a verified, highly available install.

Comparison

SaaS

NeuralTrust operates both planes. There is nothing to install in your cluster and nothing on these pages to follow.

Hybrid

You run the data plane; NeuralTrust runs the control plane. Raw prompts and responses stay in your PostgreSQL (TELEMETRY_EXPORTERS_RAW=postgres), and metadata leaves as OTLP (TELEMETRY_EXPORTERS_METADATA=otlp). Your cluster opens every connection to NeuralTrust — configuration is pulled, never pushed. Each product you run is a separate console object with its own tokens, so an install with both TrustGate and TrustGuard collects two token sets.

Hybrid

Architecture, network rules, install, verification, and high availability.

External

You run everything — control planes, data planes, the product console, and a self-hosted analytics stack (ClickStack collector, ClickHouse, DataCore, and AlertEngine). There is no runtime dependency on NeuralTrust SaaS, so no console tokens are issued and DataAgent does not run. Choose it for air-gapped or strict data-residency environments.

External (self-hosted)

The full inventory, datastores, install, and high availability.

Central control plane

You run one control plane and enrol data planes into it from other clusters. Choose it when a single External install cannot work because data has to stay where it was produced — separate business units, jurisdictions, or environments — but the console, alerting, and cross-cluster reporting have to be in one place.
The chart value is saas because this control plane behaves like NeuralTrust’s hosted one — but it is yours, and it runs in your environment. It is the opposite of the hosted SaaS model above, where there is nothing to install.

Central control plane

The central cluster, cross-cluster endpoints, remote data planes, and high availability.

Shared reference

The model guides link into these where they need them. You do not have to read them first.

Requirements and dependencies

Every dependency you provide, the ports between components, and capacity.

Configuration

Managed stores, ingress, TLS, GPU workers, and every values switch.

Container images

The registry key, mirroring for air-gapped clusters, chart sources.

Secrets

What the chart generates and what you must supply.

Cloud notes

EKS, AKS, GKE, and vanilla Kubernetes particularities.

Validation checklist

The hand-off gate: what to prove before an install counts as done.

Troubleshooting

Install, pod, config-sync, login, and telemetry failures.

The chart repository

The Helm chart is developed in the open at NeuralTrust/neuraltrust-platform. These pages are the task-oriented guide; the repository is the reference, and it is worth a look if you are the person actually running the platform. All of it also ships inside the chart artifact, so helm pull <chart-ref> --version <VERSION> --untar gives you the copy that matches the version you run — see Get the chart sources.