Skip to main content
The same neuraltrust-platform chart installs on OpenShift as on any other Kubernetes distribution. Three things differ: the chart renders native Routes instead of Ingress, wildcard Routes need cluster-level admission, and one workload needs an SCC decision. Everything else — Secrets, values, helm upgrade --install — is identical. Every topology is supported. Install by following Hybrid or External as written — namespace, Secrets, values file, helm upgrade --install, verification — and apply the OpenShift specifics on this page as you go.

​
Requirements

Start from the chart’s tracked values-openshift.yaml, which you get by unpacking the chart or from the chart repository. A companion OpenShift guide is maintained next to the chart.

​
Prepare a project

Create and link the registry pull Secret:

​
Select the platform

Two values switch the chart to OpenShift behaviour:
values-openshift.yaml is a platform overlay, not a complete install — it selects the topology only. Layer it over a values file that selects products, with the OpenShift file last so its platform wins:
Render before you install, declaring the Route API so the OpenShift objects appear:

​
Routes

With global.platform: openshift, the chart renders native Routes for the gateway, MCP, and — in External mode — the console and APIs. To standardise on Kubernetes Ingress instead, set agentgateway.ingress.resourceType: ingress. Dynamic gateway subdomains (*.llm.<domain>, *.mcp.<domain>) render as Routes with wildcardPolicy: Subdomain. The chart cannot configure the IngressController, so a cluster administrator has to admit wildcards first:
The router certificate must also cover those wildcard hosts. If you would rather not enable wildcards at all, set agentgateway.config.autoWildcardHosts: false and use exact hosts, where callers pass the gateway slug as a header instead.

​
Route certificates

A Route is readable by anyone holding route/get, so the chart never copies private keys into one. Setting an ingress tls.secretName renders spec.tls.externalCertificate pointing at your Secret, which requires OpenShift 4.17+ and read access for the router service account. On older clusters, rely on the router’s default wildcard certificate.

​
SecurityContextConstraints

Most workloads run non-root with all capabilities dropped and are compatible with restricted-v2 as-is. The chart also drops its fixed runAsUser/fsGroup from in-cluster PostgreSQL when global.platform: openshift, so the platform-assigned UID applies. Two workloads need a decision: Granting anyuid to the one ServiceAccount, rather than relaxing the namespace default, is the narrower change:
Keep restricted-v2 for everything else. If your policy forbids anyuid outright, raise it before install — Firewall deploys with TrustGuard and has no separate switch.

​
Expose the entry points

Cluster wildcard DNS and certificates may already cover the Route hosts; for custom hosts, follow cluster ingress policy. In Hybrid you expose two:
  • The LLM/proxy Route, targeting the proxy Service’s named http port (Service port 80, TrustGate container port 8081)
  • The MCP Route, targeting the MCP Service’s named http port (Service port 80, TrustGate container port 8082)
Then set both URLs in the console, as in Hybrid → Expose both entry points. External additionally renders Routes for the console, its API, and the gateway admin surface.

​
Also plan for

  • Worker capacity for your topology — Capacity (Hybrid ~3–4 × 8 vCPU / 16–32 GiB; External ~4–5; right-size later)
  • Hybrid only: the network rules for config-sync, telemetry, and DataBridge egress, plus the NeuralTrust inbound source IP
  • Disconnected clusters: mirror every image and set global.imageRegistry — see Container images. Hybrid cannot be air-gapped, because product telemetry egress is mandatory; a fully disconnected install must use External