Skip to content

Architecture overview

AMS on Azure is a set of Helm charts that share one Kubernetes cluster, one AMS hostname, and a small number of platform services.

flowchart TB
  users[Users browsers] --> agw[Application Gateway / Ingress]
  agw --> rootIngress[Infrastructure ingress /]
  rootIngress --> primary[Primary module UI]
  agw --> modulePaths[Module path Ingresses]
  modulePaths --> cc[Command Center]
  modulePaths --> are[ARE]
  modulePaths --> eobs[EOBS]
  modulePaths --> fortify[FortifyOps]
  users --> keycloak[Keycloak SSO]
  cc --> keycloak
  are --> keycloak
  eobs --> keycloak
  fortify --> keycloak
  adapters[Optional adapters] --> otel[OTEL / Observability]
  platforms[Optional Dify LibreChat Langfuse] --> adapters
  cc --> otel
  are --> otel

Dependency order

Install (or confirm) layers in this order. Later layers assume earlier ones exist.

  1. Azure / Kubernetes foundation — AKS, networking, ingress controller (often Application Gateway Ingress Controller), DNS, TLS secret, container registry pull, Key Vault CSI if you use it, PostgreSQL and object storage where charts require them
  2. Observability stack — chart ams-helm-observability-stack
  3. Keycloak — chart ams-helm-keycloak-application
  4. Application modules you selected — Command Center, ARE, EOBS, FortifyOps charts
  5. Infrastructure ingress — chart ams-helm-infrastructure-ingress with root.module set to the primary module
  6. Adapters (optional)
  7. Self-host platforms (optional) — Dify, LibreChat, Langfuse when your use case needs them

Ingress timing

You can draft ingress values early, but apply (or re-apply) them after the primary module Service exists so / has a healthy backend.

One hostname, many paths

All modules share one DNS name (for example ams.example.com).

  • Infrastructure ingress owns only / and forwards to the Service selected by root.module.
  • Each module chart owns its own path-scoped Ingress (APIs and UI prefixes).

Allowed landing values:

root.module Landing behavior (summary)
command-center Frontend Service on /
eobs Rewrite toward EOBS UI path
fortifyops Rewrite toward FortifyOps UI path
are Rewrite toward ARE UI path

Adapters vs modules

Kind User-facing? Role
Application module Yes Product UI / APIs customers use
Adapter No Worker that reads an upstream system and pushes telemetry (often into OTEL)
Platform (Dify / LibreChat / Langfuse) Often yes Authoring or chat / tracing products that adapters and modules interact with

Secrets and configuration

Customer release installs typically use Helm values under each chart’s providers/azure/release/ (or an overlay your team maintains). Secrets should stay in Azure Key Vault or Kubernetes Secrets you manage — never in Git. These guides describe keys and concepts, not live credentials.