Install on AWS (EKS)

This page covers only the AWS 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 provision the EKS cluster and its AWS backing services, then layer a small values-aws.yaml onto the canonical values file.

Before you begin

In addition to the canonical prerequisites, have ready:

• An AWS account with permission to manage EKS, EC2, IAM, RDS, S3, and (optionally) Secrets Manager.
• A Route 53 hosted zone for your domain, or equivalent control over its DNS.
• The aws CLI and eksctl (or Terraform), configured against the account.
• IAM permission to create OIDC providers, roles, and policies — IRSA needs them.

Everything below uses dynamiq.example.com as the domain and 123456789012 as the account id; replace both throughout.

Provision the cluster

Create an EKS cluster on a supported Kubernetes version (1.32 or newer). The one flag that matters for Dynamiq is --with-oidc: it enables the IAM OIDC provider that IRSA (below) depends on.

eksctl create cluster \
  --name dynamiq \
  --region us-east-1 \
  --version 1.32 \
  --nodes 3 \
  --node-type m6i.xlarge \
  --managed \
  --with-oidc

Size the node group for the sizing baseline plus your real workload. For GPU inference workloads, add a GPU-backed managed node group (or an autoscaler such as Karpenter) later — see the AWS EKS documentation for cluster and node-group detail. Then install NATS with JetStream and your ingress controller as usual.

PostgreSQL on RDS

Create an RDS for PostgreSQL 16+ instance and, on it, the three logical databases Dynamiq needs — nexus, synapse, and catalyst. One instance with three databases is fine; they only need to be logically separate.

Put the instance in the same VPC as the cluster (or a peered one) and allow inbound 5432 from the node/pod security group so the pods can reach it. RDS enforces TLS, which matches the canonical DATABASE_SSLMODE: require.

Map the endpoint, per-database user, and password into the three *-db Secrets — nexus-db, synapse-db, and catalyst-db — exactly as shown in install Step 4. Set DATABASE_HOST to the RDS endpoint and DATABASE_NAME to each logical database name. Nothing here changes the canonical manifest except those values.

S3 with IRSA

Create one bucket for platform artifacts and grant the four backend services access through IRSA — no static keys.

Bucket and policy. Create the bucket, then an IAM policy scoped to it. The services need object read/write/delete on the objects plus list on the bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::dynamiq-prod/*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::dynamiq-prod"
    }
  ]
}

IRSA roles. The chart creates each service's ServiceAccount, so create the IAM role only (with the OIDC trust policy) and let the chart annotate the account. eksctl does this with --role-only:

eksctl create iamserviceaccount \
  --cluster dynamiq \
  --namespace dynamiq \
  --name nexus \
  --role-name dynamiq-nexus \
  --attach-policy-arn arn:aws:iam::123456789012:policy/dynamiq-s3 \
  --role-only \
  --approve

Repeat for synapse, catalyst, and runtime (role names dynamiq-synapse, dynamiq-catalyst, dynamiq-runtime). Then attach each role to its ServiceAccount with the chart knob — <svc>.serviceAccount.annotations — in Provider values below. This is the storage pattern the Configuration Reference calls Pattern A.

Secrets with AWS Secrets Manager (optional)

Instead of pre-creating the per-service Secrets, you can source them from AWS Secrets Manager through the External Secrets Operator (ESO). Install ESO from its Helm chart (pin whatever version you standardize on), then create a ClusterSecretStore named dynamiq backed by Secrets Manager — the chart's ExternalSecret resources reference that exact name.

Store two secrets in Secrets Manager: DYNAMIQ (the signing and provider keys) and DYNAMIQ-DB (the database connection properties). Then enable External Secrets per service:

nexus:
  externalSecrets:
    enabled: true
synapse:
  externalSecrets:
    enabled: true
catalyst:
  externalSecrets:
    enabled: true
runtime:
  externalSecrets:
    enabled: true

The chart renders the ExternalSecret objects and their key mapping for you. The full contract — which properties DYNAMIQ-DB must expose and how the DYNAMIQ payload is extracted — is in the Configuration Reference; don't duplicate the mapping, just point the store at Secrets Manager.

Ingress and certificates

Use ingress-nginx with the canonical className: nginx — the canonical values already enable Ingress with TLS for all seven hosts, so nothing changes here. Issue the wildcard certificate with cert-manager using a Route 53 DNS-01 solver, because wildcard certs require DNS-01. One certificate must cover all seven SANs: api., app., and the five *. synapse zones.

Create Route 53 records pointing api., app., and the five wildcard zones at the ingress controller's NLB. See Networking, DNS & TLS for the full host map and the cert-manager ClusterIssuer wiring.

AWS Marketplace (optional)

If you subscribe through the AWS Marketplace listing, the chart is also published to a Marketplace ECR registry. Authenticate to it and install from there instead of Docker Hub:

aws ecr get-login-password --region us-east-1 \
  | helm registry login --username AWS --password-stdin 709825985650.dkr.ecr.us-east-1.amazonaws.com

The chart reference is then oci://709825985650.dkr.ecr.us-east-1.amazonaws.com/dynamiq/dynamiq (swap it into the install command below).

Provider values

Save this as values-aws.yaml. It is the entire AWS delta: it attaches the IRSA role to each backend ServiceAccount. Everything else — domain, ingress, storage bucket, NATS — comes from the canonical values.yaml in install Step 5.

nexus:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dynamiq-nexus

synapse:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dynamiq-synapse

catalyst:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dynamiq-catalyst

runtime:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dynamiq-runtime

If you chose Secrets Manager (above), add the four externalSecrets.enabled: true blocks to this file too.

Install and verify

Install with both files — the canonical values plus the AWS delta. Later files win on any key collision, so the ServiceAccount 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-aws.yaml

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

Next steps