Install on Red Hat OpenShift

This page covers only the OpenShift specifics. The canonical flow — namespaces, the license and application Secrets, the values file, the Helm release, and the migrations — lives in Install on Kubernetes (Helm), and every step reference below points back to it. Work through System Requirements first; here you handle the OpenShift-specific concerns — security context constraints and Routes — then layer a small values-openshift.yaml onto the canonical values file.

Before you begin

In addition to the canonical prerequisites, have ready:

• An OpenShift Container Platform 4.x cluster and cluster-admin on it.
• The oc CLI (logged in) and Helm 3.8+.

The chart's tested baseline is Kubernetes 1.32+. OpenShift versions map to specific Kubernetes levels — OCP 4.19 ships Kubernetes 1.32, and earlier 4.x releases ship older Kubernetes — so check your cluster's Kubernetes version (oc version) against that baseline before installing. Everything below uses dynamiq.example.com as the domain.

Security context considerations

The chart ships empty podSecurityContext: {} and securityContext: {} for every service, and the images are not declared runAsNonRoot with a fixed UID. Under OpenShift's default restricted-v2 SCC, the platform assigns each pod an arbitrary UID from the namespace's allocated range at admission, which is compatible with images that don't hard-code a user — so the default (empty) contexts usually admit without changes.

PostgreSQL

Provide PostgreSQL 16+ with the three logical databases nexus, synapse, and catalyst (one server, three databases). Either point at an external managed Postgres, or run it in-cluster with an operator — the Crunchy Postgres Operator (PGO) and CloudNativePG both run well on OpenShift; pin whatever version you standardize on.

However you provide it, map the host, per-database name, user, and password into the three *-db Secrets — nexus-db, synapse-db, catalyst-db — exactly as in install Step 4. Keep DATABASE_SSLMODE: require when the server enforces TLS.

Object storage

Dynamiq's storage service is fixed to s3, so use any S3-compatible backend: OpenShift Data Foundation (ODF) object storage, an in-cluster MinIO, or an external S3 service. This is the "S3-compatible endpoint" (Pattern B) case from the Configuration Reference.

Point each backend at your endpoint. For MinIO that looks like https://minio.example.com; for ODF use the S3 route its object store exposes. The endpoint and region are non-secret and go in each service's configMapData; the access key and secret key go in each service's Secret (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY), never the ConfigMap. Keep STORAGE_S3_BUCKET pointed at your bucket name.

Exposing the services

OpenShift's router consumes standard Kubernetes Ingress resources and turns each into a Route. The chart already renders the Ingress objects; the only OpenShift-specific change is the ingress class. Set className: openshift-default (the IngressClass backed by the openshift.io/ingress-to-route controller) so the Ingress binds to the router instead of the canonical nginx class — this is in Provider values below.

Wildcard hosts. The five synapse zones (*.apps, *.inferences, *.knowledgebases, *.databases, *.services) are wildcard hosts. OpenShift's router admits wildcard Routes only when configured to allow them. Enable wildcard admission on the default IngressController:

oc -n openshift-ingress-operator patch ingresscontroller/default \
  --type=merge \
  -p '{"spec":{"routeAdmission":{"wildcardPolicy":"WildcardsAllowed"}}}'

Per Red Hat's documentation, the Ingress Operator uses spec.routeAdmission.wildcardPolicy to set the router's ROUTER_ALLOW_WILDCARD_ROUTES environment variable; the default is WildcardsDisallowed, and setting WildcardsAllowed lets the router serve wildcard Routes (Ingress Operator — wildcard routes, OpenShift Container Platform networking).

GPU workloads (optional)

Model-inference deployments schedule GPU pods into the dynamiq-inferences namespace. To run them, add GPU-backed MachineSets (or nodes) and install the NVIDIA GPU Operator per Red Hat's documentation so the scheduler sees nvidia.com/gpu resources; the platform then places inference pods on them. See Model Inference Deployments for how inference endpoints are created and served.

Provider values

Save this as values-openshift.yaml. It switches the three public ingresses to the OpenShift router class and terminates TLS at the edge. The commented securityContext block is the fallback for SCC admission failures — uncomment and repeat it per service only if needed. Everything else comes from the canonical values.yaml in install Step 5.

nexus:
  ingress:
    className: openshift-default
    annotations:
      route.openshift.io/termination: edge

synapse:
  ingress:
    className: openshift-default
    annotations:
      route.openshift.io/termination: edge

ui:
  ingress:
    className: openshift-default
    annotations:
      route.openshift.io/termination: edge

# Uncomment (and repeat for synapse, catalyst, runtime, ui) only if pods fail
# SCC admission under restricted-v2:
# nexus:
#   podSecurityContext:
#     runAsNonRoot: true
#     seccompProfile:
#       type: RuntimeDefault
#   securityContext:
#     allowPrivilegeEscalation: false
#     capabilities:
#       drop:
#         - ALL

The className here overrides the canonical nginx; the annotation is added to each rendered Ingress so the router terminates TLS with the dynamiq-tls certificate.

Install and verify

Install with both files — the canonical values plus the OpenShift delta. Later files win on any key collision, so the ingress class and annotations layer cleanly onto the canonical release:

helm upgrade --install dynamiq \
  oci://registry-1.docker.io/dynamiqai/dynamiq \
  --version 0.39.0 \
  --namespace dynamiq \
  -f values.yaml \
  -f values-openshift.yaml

(Authenticate to the registry first, exactly as in install Step 6.) The post-install migration hook then runs automatically; watch it and verify the platform per install Step 7 and Step 8.

Next steps