neuraltrust-platform,
with one value selecting the topology:
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.