Self-Hosted Overview
Run the full Dynamiq platform in your own Kubernetes cluster with the official Helm chart, backed by your own Postgres, NATS, and object storage.
Self-hosting runs the entire Dynamiq platform inside your own Kubernetes cluster from the official Helm chart, so your data and workloads never leave your infrastructure. You bring the cluster and a few backing services; the chart deploys the five Dynamiq services, wires them together, and runs database migrations. Two things are gated behind Dynamiq: an enterprise license JWT and registry credentials for the private container images — contact Dynamiq for both before you start.
These guides are written against chart 0.39.0, whose images share the same app version. Pin that version on every install and upgrade rather than tracking latest.
This section is about installing and operating the platform itself. It is not about the product feature also called "Deployments" — deploying a Workflow as an App onto a running Dynamiq. For that, see Deploy & Integrate.
Architecture
The chart deploys five services. Only three are exposed publicly; the other two are reached cluster-internally over their ClusterIP Services.
| Service | Image | Public hostname | Role |
|---|---|---|---|
| nexus | dynamiqai/nexus | api.{domain} | Public REST/management API, authentication, projects; schedules user workloads into the feature namespaces. |
| ui | dynamiqai/ui | app.{domain} | Web application. |
| synapse | dynamiqai/synapse | *.apps, *.inferences, *.knowledgebases, *.databases, *.services (each .{domain}) | Serves deployed Apps, model inferences, Knowledge Bases, managed databases, and services under wildcard subdomains. |
| catalyst | dynamiqai/catalyst | internal-only | Internal platform service (requires provider API keys — see below). |
| runtime | dynamiqai/runtime | internal-only | Internal execution runtime. |
Browsers reach the ui at app.{domain} and the nexus API at api.{domain}. Anything you deploy — Apps, inference endpoints, Knowledge Bases — is served by synapse under the wildcard zones. Internally the services address each other by ClusterIP DNS (nexus, synapse, catalyst, runtime in the release namespace) and coordinate asynchronous work over NATS with JetStream. Persistent state lives in PostgreSQL (nexus, synapse, and catalyst each own a logical database; runtime has none) and in S3-compatible object storage.
All four backend services — nexus, synapse, catalyst, and runtime — mount the license Secret at /etc/dynamiq/license.jwt and require a reachable NATS server. The ui needs neither.
What you provide
The chart deploys only the Dynamiq services. You bring everything else:
- PostgreSQL 16+ — reachable from the cluster, with three logical databases (nexus, synapse, catalyst).
- NATS with JetStream enabled — shared by the four backend services; not deployed by the chart.
- S3-compatible object storage — a bucket for platform artifacts.
- An ingress controller or Gateway API controller — the chart renders classic Ingress or Gateway API
HTTPRoute. - DNS and wildcard TLS — records for
api.andapp., plus the five synapse wildcard zones, and certificates that cover them. - A license JWT and registry credentials — both obtained from Dynamiq.
System Requirements covers each of these in detail, including the exact host list and sizing baseline.
Distribution
The chart and images are published on two channels:
- Docker Hub (OCI) —
oci://registry-1.docker.io/dynamiqai/dynamiq, with images underdynamiqai/{nexus,synapse,catalyst,runtime,ui}. This registry is private: authenticate with the Docker Hub credentials Dynamiq issues you before pulling the chart or images. - AWS Marketplace (ECR) —
oci://709825985650.dkr.ecr.us-east-1.amazonaws.com/dynamiq/dynamiqfor customers who subscribe through the AWS Marketplace listing.
Image tags default to the chart's app version, so the chart version selects the matching images. Always pin an explicit --version on install and upgrade.
Choose your platform
Start with the Kubernetes guide — it is the canonical, cloud-agnostic install. The provider guides layer only the platform-specific deltas (storage classes, load balancers, ingress, IAM) on top of it.
Install on Kubernetes (Helm)
The canonical, cloud-agnostic install every provider guide builds on.
Install on AWS (EKS)
EKS deltas: S3 with IRSA, RDS, ingress-nginx with cert-manager, and the Marketplace chart.
Install on IBM Cloud (IKS)
IKS deltas: IBM Cloud Object Storage and Databases for PostgreSQL.
Install on Red Hat OpenShift
OpenShift deltas: Routes, wildcard route policy, and SCC guidance.
How these guides are structured
Every install path shares the same shape, so read them in order:
- System Requirements — the cluster, external services, hosts, and credentials to have ready first.
- Install on Kubernetes (Helm) — the canonical install, written as numbered steps you run top to bottom. The provider guides reference these steps and change only what differs.
- Configuration Reference and Networking, DNS & TLS — the values and exposure options in depth.
- Upgrades & Rollback and Operations & Troubleshooting — running the platform after install.