Skip to main content
The Helm chart and the container images are distributed differently. The chart is published to a public OCI registry — helm install and helm template pull it anonymously, with no helm registry login. The images are private. When your account is provisioned, NeuralTrust sends you a registry key — a JSON service-account key — plus the registry server to use it against. Keep it with your other production credentials; it is the only thing standing between your cluster and the images. Everything on this page is about the images. From there you have two supported paths: Both paths pull the same images. Hybrid pulls the data path; External additionally pulls the console and analytics stack; a Central control plane pulls everything External does plus two more — databridge and opentelemetry-collector-contrib for the ingest gateway.

​
Get the chart sources

Every install path starts from tracked files that helm install does not create: create-image-pull-secret.sh, values-required.yaml, and the values-*.yaml.example presets. They live in the chart’s public repository, NeuralTrust/neuraltrust-platform, and they are packaged inside the chart artifact, so you can get them without cloning and without credentials:
That directory matches the exact chart version you are about to install, which is why it is preferable to git clone for an install. Clone the repository instead when you want history, issues, or the in-repo operator references: SECRETS.md for the full per-component key contract, VALUES_SCENARIOS.md for scenario walkthroughs, and docs/ for the architecture, sizing, and network notes.

​
Pull directly from NeuralTrust

Create a docker-registry Secret from the key. The chart ships create-image-pull-secret.sh, which fills in the registry server and username for you. Get it by unpacking the chart — helm pull <chart-ref> --version <VERSION> --untar — or from the public repository, NeuralTrust/neuraltrust-platform:
The equivalent by hand — the username is the literal string _json_key, and the password is the entire contents of the key file, not a path to it:
Name the Secret gcr-secret. Every component defaults to that name, so no values changes are needed. If you must use a different name, see Renaming the pull Secret.
That is the whole setup. Continue with your model’s install — Hybrid or External.

​
Mirror to your own registry

Copy every image your deployment uses into your registry, preserving the repository names and tags — change only the registry host.

​
Which images to copy

Render your own values file to get the exact list, including the tags pinned by your chart version:
A Hybrid install with all products enabled pulls agentgateway, trustguard, firewall-cpu, data-plane-api, dataagent, opentelemetry-collector-contrib, and — unless you use managed stores — postgres and redis-stack-server. External adds control-plane-api, app, datacore, alertengine, clickstack-otel-collector, and clickhouse-server. A central cluster adds databridge and a second opentelemetry-collector-contrib for the ingest gateway on top of the External set; its data-plane clusters need only the Hybrid set. GPU Firewall uses a separate image — see GPU Firewall workers.

​
Point the chart at your registry

global.imageRegistry does not rewrite the OTel collector images. Their repositories are pinned in full, so they keep pointing at the NeuralTrust registry and their pods fail to pull in an air-gapped cluster. Override them explicitly:
Set only the ones you render. The first is the DataAgent egress sidecar, which every Hybrid install runs and External never deploys. The second applies to either mode, but only when global.observability.enabled is true. An External install with observability off needs neither, and global.imageRegistry covers it completely.The ingest gateway a central cluster runs is the same upstream collector, but it is rewritten by global.imageRegistry and needs no entry here. Override it per component only to pull it from somewhere else than your other images:
Either way, re-run the helm template | grep image: command above afterwards and confirm no image still points at the NeuralTrust registry.
Then create a pull Secret for your registry, named gcr-secret, in the release namespace:
Re-mirror when you upgrade the chart — tags are pinned per chart version, so a new version pulls images your registry does not have yet.

​
Renaming the pull Secret

Every component defaults to a Secret named gcr-secret, and global.imagePullSecrets does not override that default — it only applies to the chart’s own in-cluster PostgreSQL and Redis. Setting it alone leaves the product workloads still asking for gcr-secret. Reusing the name gcr-secret for your own registry credential is by far the simplest option. If your policy forbids it, set the pull secret on each component instead, and verify with:

​
Clusters that pull without a Secret

Where node or workload identity already authorizes registry pulls — GKE Workload Identity, an EKS instance profile, ACR attached to AKS — you do not need to create anything. Leave the defaults alone: pods keep a reference to a gcr-secret that does not exist, and the kubelet falls back to the node credentials.
Do not try to suppress the references with global.imagePullSecrets: ["none"]. It does not clear them from the product workloads, and it makes the Redis Deployment reference a Secret literally named none.