System Requirements

Have all of the following ready before you start Install on Kubernetes (Helm). The chart deploys only the Dynamiq services — Postgres, NATS, object storage, ingress, DNS, and TLS are yours to provide, and the install assumes they already exist and are reachable from the cluster.

Kubernetes and tooling

• Kubernetes 1.32+ — the chart's tested baseline. Older clusters are unsupported.
• Helm 3.8+ — required for pulling the chart as an OCI artifact; there is no helm repo add step.
• kubectl — configured against the target cluster, with permission to create namespaces, Secrets, and the chart's workloads. helm upgrade --install also creates a namespace-scoped Role and RoleBinding per feature namespace, so your installing identity needs RBAC to create those.
• openssl — used to generate the authentication signing keys in the install.

External services

The chart connects to these; it does not deploy them.

PostgreSQL 16+

One reachable PostgreSQL 16+ server with three logical databases, one per stateful service. Runtime has no database.

Each service reads its credentials from a Kubernetes Secret (host, database, username, password); you wire those up in the install. TLS to the database is recommended (DATABASE_SSLMODE: require).

NATS with JetStream

A NATS server with JetStream enabled, shared by nexus, synapse, catalyst, and runtime. It is not part of the chart. If you don't already run one, the simplest path is the upstream NATS chart, installed into the same namespace:

helm repo add nats https://nats-io.github.io/k8s/helm/charts/
helm upgrade --install nats nats/nats \
  --namespace dynamiq --create-namespace \
  --set config.jetstream.enabled=true

Every backend service then points NATS_URL at it — for the command above that is nats://nats.dynamiq.svc.cluster.local:4222. NATS_URL is schema-required for all four services; an install with it blank is rejected.

S3-compatible object storage

One bucket on an S3-compatible backend for platform artifacts. The chart's storage service is fixed to s3 (STORAGE_SERVICE only accepts s3); supply the bucket name via STORAGE_S3_BUCKET and provide the backend's credentials to the cluster.

Networking and DNS

Dynamiq needs two exact hostnames and five wildcard zones, all under your chosen dynamiq.domain. Create DNS records for each and TLS certificates that cover them.

catalyst and runtime are internal-only — they are reached over their in-cluster ClusterIP Services and need no DNS or ingress. See Networking, DNS & TLS for Ingress vs. Gateway API and certificate options.

Credentials and license

Both come from Dynamiq — contact Dynamiq if you don't have them yet.

• Registry credentials — a Docker Hub username and access token with pull access to the private dynamiqai/* images and chart. You either hand them to the chart (dynamiq.imageCredentials) or pre-create a docker-registry pull Secret.
• License JWT — an enterprise license file. You store it in a Kubernetes Secret that the chart mounts at /etc/dynamiq/license.jwt into the four backend services. The platform re-reads the file on rotation without a restart.

Sizing baseline

The chart ships conservative default requests and limits per service (single replica each):

Cluster sizing starting points

The sizing baseline above is what the chart's pods request and are capped at — a node needs more than that to actually run them. On top of the chart's totals (1425m/1600Mi requested, 4850m/5248Mi at the limit), every node also reserves roughly 0.5 vCPU and 1-2 GiB for the kubelet and OS before any pod lands on it, and the cluster carries its own add-ons alongside the chart — a CNI, an ingress controller, cert-manager, and, if you run it in-cluster, NATS JetStream. Sizing to the chart's limit total rather than its request total leaves headroom for a single replica to burst to its cap, and provisioning one node more than that arithmetic requires means the cluster survives a node draining for maintenance without losing that headroom. The two profiles below turn that arithmetic into a starting point — they get you to a working install, not a sized production cluster.

Node guidance

On OpenShift, both rows describe worker capacity only — the control plane and platform pods (monitoring, logging, the router) need capacity of their own on top, per Red Hat's minimum requirements for the platform. Past evaluation, prefer adding replicas (≥2 per public-facing service, for zero-downtime rollouts) over adding nodes as load grows — see Sizing, scheduling, autoscaling for the replica and HPA settings behind that.

Storage baselines

GPU capacity

The platform itself is CPU-only — no service the chart deploys requests a GPU. GPU node pools are only needed once you run model-inference deployments; see Model Inference Deployments for how those pods are scheduled, and GPU workloads for the OpenShift GPU Operator setup.

Optional components

Not required, but commonly paired with a self-hosted install:

• External Secrets Operator (ESO) — the chart can source per-service Secrets from a ClusterSecretStore named dynamiq instead of pre-created Secrets. See Configuration Reference.
• cert-manager — automates issuance and renewal of the wildcard TLS certificates the hosts above need. See Networking, DNS & TLS.
• Horizontal Pod Autoscaler — each service exposes an autoscaling block (off by default) that renders an HPA when enabled.

Next steps