Helm Charts
Official Helm charts for deploying DecisionRules to Kubernetes: Amazon EKS, Azure AKS, generic Kubernetes with NGINX Ingress, Red Hat OpenShift and Google Kubernetes Engine.
DecisionRules provides Helm charts for deploying the application to Kubernetes. Each chart is tailored to one platform and uses that platform's way of exposing applications to users. Pick the chart for your platform below. Each chart has its own page describing what it deploys, what you need to provision separately, and all configuration options.
Choose a chart
Amazon EKS with EKS Auto Mode
A public Network Load Balancer per component
Not configured by the chart
Kubernetes Secret (recommended) or values.yaml
Azure Kubernetes Service
A public Azure Load Balancer IP per component
Not configured by the chart
values.yaml
Any Kubernetes with the NGINX Ingress Controller and cert-manager
One Ingress, a hostname per component
Let's Encrypt certificate from cert-manager
values.yaml
Red Hat OpenShift (OCP, ARO, ROSA)
An OpenShift Route for the client and the server
Edge TLS on the Routes
Kubernetes Secret (required)
Google Kubernetes Engine (Standard or Autopilot)
One GKE Ingress (Google Cloud load balancer) for the client and the server
Google-managed certificate
Kubernetes Secret (required)
What all charts have in common
The charts deploy only DecisionRules: the client, the server and, optionally, Business Intelligence and the AI Engine. MongoDB and Redis are never deployed by the charts. Provision them separately and make sure they are reachable from the cluster. For a private connection to MongoDB Atlas, see MongoDB Atlas Network Peering.
Outbound access: the server must reach the DecisionRules license and distribution servers, see Prerequisites, or use an Offline License.
Images: all charts use the official images from Docker Hub and default to the
latesttag. Pin a specific version in production.Server sizing: every chart sizes the server for the rule solver you use, see Server sizing. Make sure your cluster has room for at least two server Pods.
Application URLs: the server needs its own public URL (
API_URL) and the client's URL (CLIENT_URL, ending with/#). The OpenShift and GKE charts derive them from the hostnames. With the other charts you set them invalues.yaml.
See Environment Variables for the meaning of every variable the charts set.
Server sizing
All charts size the server according to the rule solver you use. AERO is the default.
AERO (v2) or mixed v1/v2 traffic
aero (default)
4000m / 4Gi (requests = limits)
2–5 Pods
GAIA (v1) only
gaia
1000m / 1Gi requests, 2000m / 2Gi limits
2–10 Pods
AERO uses several CPUs within one process, so it runs best on fewer, larger replicas. Select the profile with solver in the EKS, AKS and Ingress charts and with server.solver in the OpenShift and GKE charts. Both profiles are defined in each chart's values.yaml (solverProfiles, or server.solverProfiles in the OpenShift and GKE charts), so you can adjust them. To size the server yourself regardless of the profile, set the server resources and the autoscaling range explicitly; they take precedence over the profile. See server sizing for scaling and resource reserve.
Quick start
The commands below only add the repository and install the chart. Read the chart's page first to prepare the values file and the resources the chart expects.
If you prefer to write the Kubernetes manifests yourself, see Kubernetes Setup.
Last updated
Was this helpful?

