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 thathelm 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:
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 adocker-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:
_json_key, and the
password is the entire contents of the key file, not a path to it:
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: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
imageRegistry moves every image onto your registry. imageRegistryScope: all
includes the OTel collector images as well: the DataAgent egress sidecar and,
with global.observability.enabled, the self-hosted collector. Without it they
keep pulling from the NeuralTrust registry and fail in an air-gapped cluster. A
collector image.repository you set yourself is left as it is.
Re-run the helm template | grep image: command above 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:
Renaming the pull Secret
Every component defaults to a Secret namedgcr-secret. To use your own name,
set it once for every workload:
imagePullSecrets still overrides it. 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 agcr-secret that does not exist, and the kubelet falls back to the node
credentials.
To remove the references, set global.imagePullSecrets: ["none"].