> ## Documentation Index
> Fetch the complete documentation index at: https://neuraltrust-92b43583-develop.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenShift

> OpenShift prerequisites, Routes, and SecurityContextConstraints for the NeuralTrust chart.

The same [`neuraltrust-platform`](https://github.com/NeuralTrust/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](/neuraltrust/deployment/hybrid) or [External](/neuraltrust/deployment/external) as written — namespace, Secrets, values file, `helm upgrade --install`, verification — and apply the OpenShift specifics on this page as you go.

## Requirements

| Requirement | Detail                                                                                                 |
| ----------- | ------------------------------------------------------------------------------------------------------ |
| OpenShift   | **4.10+** · 4.17+ to attach your own Route certificates via `externalCertificate`                      |
| Helm        | 3.8+ (OCI installs)                                                                                    |
| Access      | `oc` access to the target project, cluster-admin for the SCC and IngressController steps               |
| Domain      | A wildcard apps domain such as `apps.example.com`                                                      |
| Datastores  | Reachable PostgreSQL and Redis — [minimum sizes](/neuraltrust/deployment/configuration#managed-stores) |

Start from the chart's tracked [`values-openshift.yaml`](https://github.com/NeuralTrust/neuraltrust-platform/blob/main/values-openshift.yaml), which you get by unpacking the chart or from the [chart repository](https://github.com/NeuralTrust/neuraltrust-platform). A companion [OpenShift guide](https://github.com/NeuralTrust/neuraltrust-platform/blob/main/README-OPENSHIFT.md) is maintained next to the chart.

## Prepare a project

```bash theme={null}
oc login https://api.<cluster>:6443
oc new-project neuraltrust
oc get storageclass
```

Create and link the registry pull Secret:

```bash theme={null}
oc secrets link default gcr-secret --for=pull -n neuraltrust
oc secrets link builder gcr-secret --for=pull -n neuraltrust
```

## Select the platform

Two values switch the chart to OpenShift behaviour:

```yaml theme={null}
global:
  platform: openshift
  domain: apps.example.com   # usually the cluster's apps wildcard suffix
  ingress:
    provider: openshift
```

`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:

```bash theme={null}
helm upgrade --install neuraltrust-platform \
  oci://europe-west1-docker.pkg.dev/neuraltrust-app-prod/helm-charts/neuraltrust-platform \
  --version <VERSION> \
  --namespace neuraltrust \
  -f values-required.yaml \
  -f values-openshift.yaml \
  --set global.domain=apps.example.com
```

Render before you install, declaring the Route API so the OpenShift objects appear:

```bash theme={null}
helm template neuraltrust-platform <chart> \
  -f values-required.yaml -f values-openshift.yaml \
  --api-versions route.openshift.io/v1
```

## 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:

```yaml theme={null}
# IngressController spec.routeAdmission
routeAdmission:
  wildcardPolicy: WildcardsAllowed
```

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:

| Workload                         | Why                                                                                                          | Options                                                                                                                                                         |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Firewall** gateway and workers | Default `firewall.securityContext` is `runAsUser: 0`, and the model cache path is `/root/.cache/huggingface` | Grant `anyuid` to the `firewall` ServiceAccount, or override `firewall.securityContext` **and** `firewall.config.hfHome` to a path writable by an arbitrary UID |
| **GPU Firewall** workers         | Use `hostIPC` for CUDA MPS plus GPU device resources                                                         | Requires a dedicated SCC; only relevant if you opt into GPU workers                                                                                             |

Granting `anyuid` to the one ServiceAccount, rather than relaxing the namespace default, is the narrower change:

```bash theme={null}
oc adm policy add-scc-to-user anyuid -z firewall -n neuraltrust
```

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

```bash theme={null}
oc get route -n neuraltrust
```

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](/neuraltrust/deployment/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](/neuraltrust/deployment/architecture#capacity) (Hybrid \~**3–4** × 8 vCPU / 16–32 GiB; External \~**4–5**; right-size later)
* Hybrid only: the [network rules](/neuraltrust/deployment/hybrid#network) 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](/neuraltrust/deployment/images). Hybrid cannot be air-gapped, because product telemetry egress is mandatory; a fully disconnected install must use [External](/neuraltrust/deployment/external)