Networking, DNS & TLS

Self-hosted Dynamiq serves three public entry points — the API, the web app, and everything you deploy onto the platform — under one root domain. This page covers how to route traffic to them with classic Ingress or Gateway API, how to cover the hosts with TLS, and how the services talk to each other inside the cluster. It builds on Install on Kubernetes (Helm), which enables Ingress with TLS for all seven hosts in one values file; here you'll find the per-option detail. Every values snippet renders against chart 0.39.0; the domain throughout is dynamiq.example.com.

Hostname map

Dynamiq needs two exact hostnames and five wildcard zones under your dynamiq.domain. The chart generates these hosts automatically for the nexus, synapse, and ui ingresses/routes — you supply the matching DNS records and certificates.

The five wildcard zones all route to synapse, which dispatches each deployed resource by subdomain. catalyst and runtime have no host — they are internal-only (see Internal traffic).

Ingress

Each of the three public services exposes an ingress block: enabled, className, annotations, and tls. The chart injects the correct rules hosts for you (nexus gets api., ui gets app., synapse gets all five wildcards), so your job is to turn ingress on, set the class, and list the hosts your TLS Secret covers. This one snippet configures all three with a single shared certificate:

nexus:
  ingress:
    enabled: true
    className: nginx
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-dns
    tls:
      - secretName: dynamiq-tls
        hosts:
          - api.dynamiq.example.com

synapse:
  ingress:
    enabled: true
    className: nginx
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-dns
    tls:
      - secretName: dynamiq-tls
        hosts:
          - "*.apps.dynamiq.example.com"
          - "*.inferences.dynamiq.example.com"
          - "*.knowledgebases.dynamiq.example.com"
          - "*.databases.dynamiq.example.com"
          - "*.services.dynamiq.example.com"

ui:
  ingress:
    enabled: true
    className: nginx
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-dns
    tls:
      - secretName: dynamiq-tls
        hosts:
          - app.dynamiq.example.com

Rendered, this produces three Ingress objects covering exactly seven hosts — api., app., and the five *. synapse zones. The tls.hosts list only tells the ingress controller which cert to serve for which host; the rules are added by the chart regardless.

Gateway API

If you run a Gateway API controller instead of an ingress controller, each public service exposes an httpRoute block — enabled, parentRefs, hosts, and annotations — that renders an HTTPRoute with the same generated hostnames. Point each route at your Gateway via parentRefs:

nexus:
  httpRoute:
    enabled: true
    parentRefs:
      - name: dynamiq-gateway
        namespace: gateway-system

synapse:
  httpRoute:
    enabled: true
    parentRefs:
      - name: dynamiq-gateway
        namespace: gateway-system

ui:
  httpRoute:
    enabled: true
    parentRefs:
      - name: dynamiq-gateway
        namespace: gateway-system

This renders three HTTPRoute objects: nexus with hostname api.dynamiq.example.com, ui with app.dynamiq.example.com, and synapse with all five wildcard hostnames. Each parentRefs entry takes a name (required) plus optional namespace, sectionName, and port to target a specific Gateway listener. TLS is terminated by the Gateway listener here, not the route, so certificates are configured on the Gateway rather than in a tls block. The chart ships a fuller example at examples/gateway-api-values.yaml.

Wildcard certificates

Every synapse host is a wildcard (*.apps, *.inferences, and so on), and wildcard certificates can only be issued via a DNS-01 ACME challenge — HTTP-01 cannot validate a wildcard. Plan for DNS-01 from the start.

Two common strategies:

• One certificate, seven SANs — a single cert (the dynamiq-tls Secret above) listing api., app., and the five wildcard zones. Simplest to reference; every ingress points at the same Secret.
• Per-zone certificates — separate certs (for example one for api./app. and one spanning the five synapse wildcards). More Secrets to manage, but blast radius and rotation are scoped per zone. Whichever you pick, synapse's cert must still cover all five wildcard zones.

With cert-manager, issue these from a ClusterIssuer configured for your DNS provider's DNS-01 solver and reference it from the ingress annotations (as cert-manager.io/cluster-issuer above). cert-manager then requests and renews the wildcard certificate into the dynamiq-tls Secret automatically.

Managed alternatives — an ACM certificate on an AWS load balancer, an OpenShift Route with its own TLS, or an IBM Cloud certificate manager — are covered in the provider guides: AWS (EKS), IBM Cloud (IKS), and Red Hat OpenShift.

Internal traffic

catalyst and runtime are never exposed publicly — they run as ClusterIP Services and are reached only from inside the cluster. nexus, synapse, catalyst, and runtime also expose ClusterIP Services for service-to-service calls.

nexus is the hub: its ConfigMap is populated with the in-cluster addresses of the other backends, derived automatically from the release namespace. Rendered into the release namespace dynamiq, they are:

SYNAPSE_BASE_URL:  http://synapse.dynamiq.svc.cluster.local:80
CATALYST_BASE_URL: http://catalyst.dynamiq.svc.cluster.local:80
RUNTIME_BASE_URL:  http://runtime.dynamiq.svc.cluster.local:80

You don't set these — the chart builds them from the service names and .Release.Namespace. Beyond that, every backend service needs to reach two shared dependencies:

• NATS on port 4222 — nexus, synapse, catalyst, and runtime all connect to NATS_URL (for the default in-namespace install, nats://nats.dynamiq.svc.cluster.local:4222).
• PostgreSQL — nexus, synapse, and catalyst reach the database host from their -db Secret; runtime has no database.

If you enforce network policies, allow the backend pods to reach NATS and Postgres, and allow nexus to reach synapse, catalyst, and runtime on port 80. Egress-wise, the pods also need to pull images from your registry and — for catalyst — reach the external LLM and tool provider APIs listed in the Configuration Reference.

Next steps