rasa

A Rasa Pro Helm chart for Kubernetes

Prerequisites

• Kubernetes 1.30+
• Helm 3.8.0+
• A valid Rasa Pro license key

Creating Secrets

The chart reads credentials exclusively from Kubernetes Secrets. Only the license secret is required to install — all other secrets are optional and only referenced when you enable the corresponding feature.

License Secret (required)

Create a secret containing your Rasa Pro license key before installing:

kubectl create secret generic rasa-secrets \
  --from-literal=rasaProLicense="<YOUR_LICENSE_KEY>"

The chart defaults to secretName: rasa-secrets and secretKey: rasaProLicense. Override both in your values if you use a different name or key:

rasaProLicense:
  secretName: my-custom-secret
  secretKey: myLicenseKey

Optional Secrets

Add optional keys to the same secret (or separate secrets) as you enable features. You can extend the secret you created above:

kubectl patch secret rasa-secrets -p \
  '{"stringData":{"authToken":"<YOUR_TOKEN>","jwtSecret":"<YOUR_JWT_SECRET>"}}'

The table below lists all secret-backed fields:

Alternatively, create all credentials upfront from a manifest. The chart ships a secrets.yaml example that you can use as a starting point — use stringData so Kubernetes base64-encodes the values automatically:

apiVersion: v1
kind: Secret
metadata:
  name: rasa-secrets
type: Opaque
stringData:
  rasaProLicense: "<YOUR_LICENSE_KEY>"    # required for all deployments
  authToken: "<YOUR_AUTH_TOKEN>"          # optional: token-based API auth
  jwtSecret: "<YOUR_JWT_SECRET>"          # optional: JWT auth
  kafkaSslPassword: "<KAFKA_PASSWORD>"    # optional: Kafka SASL (non-IAM)

Installing the Chart

Before installing, make sure you have created the license secret as described in Creating Secrets above.

You can install the chart from either the OCI registry or the GitHub Helm repository.

Option 1: Install from OCI Registry

To install the chart with the release name my-release:

helm install my-release oci://europe-west3-docker.pkg.dev/rasa-releases/helm-charts/rasa --version 2.5.0

Option 2: Install from GitHub Helm Repository

First, add the Rasa Helm repository:

helm repo add rasa https://helm.rasa.com/charts
helm repo update

Then install the chart:

helm install my-release rasa/rasa --version 2.5.0

Upgrading the Chart

To upgrade to a new chart version, update the repository index and run:

helm repo update
helm upgrade my-release rasa/rasa --version <new-version> -f values.yaml

Or from OCI:

helm upgrade my-release oci://europe-west3-docker.pkg.dev/rasa-releases/helm-charts/rasa --version <new-version> -f values.yaml

Note: Always check the release notes for breaking changes before upgrading across major versions.

Uninstalling the Chart

To uninstall/delete the my-release deployment:

helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

General Configuration

• imagePullSecrets: If you’re pulling from a private registry, provide your pull secret name(s) here. This applies to all components unless overridden at the component level.
• rasaProLicense: All Rasa Pro deployments require a valid license. Provide secretName and secretKey pointing to the Kubernetes Secret that holds your license value.

Note: For application-specific settings, refer to the Rasa documentation. The full list of configurable values is at the bottom of this page.

Deployment Modes

Rasa Pro with Analytics (full stack)

Deploys the Rasa Pro server together with the Rasa Pro Services analytics pipeline. Requires a PostgreSQL-compatible analytics database.

rasa:
  enabled: true
rasaProServices:
  enabled: true
  database:
    url: "postgresql://user:password@host:5432/dbname"

Rasa Pro only (no analytics)

Deploys only the Rasa Pro server. Use this when you do not need the analytics pipeline.

rasa:
  enabled: true
rasaProServices:
  enabled: false

Minimal Working Configuration

The following is the smallest values.yaml needed to get Rasa Pro running. It assumes the license secret was created as shown in Creating Secrets:

rasaProLicense:
  secretName: rasa-secrets
  secretKey: rasaProLicense

rasa:
  enabled: true
  image:
    tag: "3.x.x"  # pin to a specific Rasa Pro version

rasaProServices:
  enabled: false

Install with:

helm install my-release rasa/rasa -f values.yaml

From there, add sections from the rest of this guide as your deployment grows.

Rasa Pro Services Database Configuration

The rasaProServices.database section configures the analytics data lake connection. There are two ways to provide the database URL.

Plain value:

rasaProServices:
  database:
    url: "postgresql://user:password@host:5432/dbname"

From an existing secret (recommended for production):

Create a Kubernetes secret containing the database URL:

kubectl create secret generic my-db-secret \
  --from-literal=analyticsDbUrl="postgresql://user:password@host:5432/dbname"

Then reference it in your values:

rasaProServices:
  database:
    urlExistingSecretName: my-db-secret
    urlExistingSecretKey: analyticsDbUrl

When urlExistingSecretName is set it takes precedence over url.

AWS RDS IAM authentication:

For IAM-based authentication (passwordless, using an IAM role bound to the pod’s service account), use database.enableAwsRdsIam: true and provide individual connection fields instead of a URL:

rasaProServices:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: "arn:aws:iam::123456789012:role/rasa-pro-services-role"
  database:
    enableAwsRdsIam: true
    hostname: "my-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com"
    port: "5432"
    username: "rasa_user"
    databaseName: "rasa_analytics"
    sslMode: "verify-full"
    sslCaLocation: "/path/to/rds-ca.pem"

Use MinIO instead of S3

Warning: MinIO is end-of-life and no longer receives updates. The chart still supports connecting to a MinIO instance, but we recommend migrating to S3 or another actively maintained object storage provider.

To use MinIO instead of S3, set AWS_ENDPOINT_URL to the URL of the MinIO server and provide AWS_REGION and BUCKET_NAME. Store your MinIO credentials in a Kubernetes Secret:

kubectl create secret generic minio-credentials \
  --from-literal=accessKey="<YOUR_MINIO_ACCESS_KEY>" \
  --from-literal=secretKey="<YOUR_MINIO_SECRET_KEY>"

rasa:
  additionalEnv:
    - name: AWS_ENDPOINT_URL
      value: "http://minio.example.com"
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: minio-credentials
          key: accessKey
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: minio-credentials
          key: secretKey
    - name: AWS_REGION
      value: "us-east-1"
    - name: BUCKET_NAME
      value: "rasa-models"

Mount Configuration Options

mountDefaultConfigmap:

By default, the chart mounts credentials.yml and endpoints.yml files from a ConfigMap to the Rasa deployment. If you prefer to mount these files from a different source (e.g., from the /.config directory or baked into the image), you can disable this behavior:

rasa:
  settings:
    mountDefaultConfigmap: false

When disabled, it is expected that the credentials and endpoints are mounted to the /.config directory or baked into the image.

mountModelsVolume:

By default, the chart mounts a models volume to the Rasa deployment at /app/models. If you prefer to mount models from a different source or bake them into the image, you can disable this behavior:

rasa:
  settings:
    mountModelsVolume: false

When disabled, it is expected that the models are mounted to the /app/models directory or baked into the image.

Configuring API Authentication

The Rasa HTTP API supports two authentication methods. Configure one or both via Kubernetes Secrets.

Token-based authentication:

kubectl create secret generic rasa-secrets \
  --from-literal=authToken="<YOUR_STATIC_TOKEN>"

rasa:
  settings:
    authToken:
      secretName: rasa-secrets
      secretKey: authToken

JWT authentication:

kubectl create secret generic rasa-secrets \
  --from-literal=jwtSecret="<YOUR_JWT_SECRET>"

rasa:
  settings:
    jwtSecret:
      secretName: rasa-secrets
      secretKey: jwtSecret
    jwtMethod: HS256

See the Rasa documentation for details on API authentication.

Configuring the Readiness Probe

The default readiness probe hits the / endpoint, which returns a success code as soon as the HTTP server is up — before any model has been loaded. For production, use the /status endpoint instead, which only returns a success code once Rasa has loaded a model and is ready to process conversations.

Without authentication:

rasa:
  readinessProbe:
    httpGet:
      path: /status
      port: 5005
      scheme: HTTP

With authToken configured:

When AUTH_TOKEN is set, the /status endpoint requires authentication. Use an exec probe that reads the token from the environment variable:

rasa:
  readinessProbe:
    httpGet: null
    exec:
      command:
        - /bin/sh
        - -c
        - "curl -f http://localhost:5005/status?token=${AUTH_TOKEN}"
    initialDelaySeconds: 15
    periodSeconds: 15
    successThreshold: 1
    timeoutSeconds: 5
    failureThreshold: 6

Note: The AUTH_TOKEN environment variable is automatically injected by the chart from the secret referenced in rasa.settings.authToken. Setting httpGet: null removes the default value set by the chart — this is required when switching from an httpGet probe to an exec probe, otherwise both will be rendered and Kubernetes will reject the manifest. Update the URL scheme and port in the curl command if you have changed rasa.settings.scheme or rasa.settings.port from their defaults.

Graceful Shutdown and Lifecycle Hooks

Every component (rasa, rasaProServices, actionServer, duckling) accepts a pod-level terminationGracePeriodSeconds and a container-level lifecycle block. Both are unset by default, so the rendered manifests are unchanged unless you opt in.

When Kubernetes deletes a pod it removes the pod from Service endpoints and sends SIGTERM at the same time, so in-flight requests can still arrive for a short window. A preStop sleep holds the container open long enough for the endpoint removal to propagate:

rasa:
  lifecycle:
    preStop:
      sleep:
        seconds: 10
  terminationGracePeriodSeconds: 60

The native sleep handler needs no shell or sleep binary in the image, which matters for images you do not build yourself. It has been enabled by default since Kubernetes 1.30, the minimum this chart supports, so no feature gate is required. The equivalent exec form remains available if you would rather run a real drain command than simply wait:

rasa:
  lifecycle:
    preStop:
      exec:
        command: ["/bin/sh", "-c", "sleep 10"]

Two rules of thumb when picking values:

• Make the preStop sleep at least as long as readinessProbe.periodSeconds so load balancers have a full probe cycle to notice the pod is going away.
• Keep terminationGracePeriodSeconds larger than the preStop duration plus the time your application needs to finish in-flight work. The preStop hook runs inside the grace period, so a hook longer than the grace period gets cut short by SIGKILL.

Leaving terminationGracePeriodSeconds unset falls back to the Kubernetes default of 30 seconds.

The lifecycle block is passed through verbatim, so any hook handler Kubernetes supports (exec, httpGet, sleep) works. postStart is available as well:

actionServer:
  lifecycle:
    postStart:
      exec:
        command: ["/bin/sh", "-c", "echo action server starting"]

Note: The hook applies to the component’s main container only. Containers you supply through initContainers or additionalContainers can carry their own lifecycle block directly.

Configuring Credentials and Endpoints via ConfigMap

The chart can automatically create a ConfigMap containing credentials.yml and endpoints.yml files that are mounted to the Rasa deployment. This is enabled by default via rasa.settings.mountDefaultConfigmap: true.

Configuring Credentials

The rasa.settings.credentials section allows you to configure channel connectors for messaging and voice channels. These credentials are written to the credentials.yml file in the ConfigMap.

For example, to configure Facebook Messenger:

rasa:
  settings:
    credentials:
      facebook:
        verify: "rasa"
        secret: "<SECRET>"
        page-access-token: "<PAGE-ACCESS-TOKEN>"

For REST channel:

rasa:
  settings:
    credentials:
      rest:

See the Rasa channel documentation for all available channel configurations.

Sourcing Endpoints and Credentials from Raw YAML Files

In addition to the structured rasa.settings.endpoints and rasa.settings.credentials maps, the chart accepts the raw contents of an endpoints.yml or credentials.yml file via rasa.settings.endpointsRaw and rasa.settings.credentialsRaw. This lets the same file the developer uses locally for rasa train / rasa run flow directly into the rendered ConfigMap with no wrapper file or pre-commit step.

When both the structured and raw values are provided, they are deep-merged. The structured value wins on key conflicts — this is intentional so infrastructure-owned blocks (e.g. tracker_store, event_broker) defined in rasa.settings.endpoints override the same keys in the raw file.

Helm CLI (--set-file):

helm install my-release oci://europe-west3-docker.pkg.dev/rasa-releases/helm-charts/rasa \
  --version 2.5.0 \
  --set-file rasa.settings.endpointsRaw=./endpoints.yml \
  --set-file rasa.settings.credentialsRaw=./credentials.yml

ArgoCD multi-source Application (referencing files from a values repo):

spec:
  sources:
    - repoURL: https://github.com/RasaHQ/rasa-helm-charts
      chart: rasa
      targetRevision: 2.5.0
      helm:
        fileParameters:
          - name: rasa.settings.endpointsRaw
            path: $values/endpoints.yml
          - name: rasa.settings.credentialsRaw
            path: $values/credentials.yml
    - repoURL: https://github.com/your-org/your-app-repo
      targetRevision: main
      ref: values

${VAR} placeholders inside the raw file are preserved verbatim through the parse/merge/render pipeline, so Rasa’s runtime environment-variable substitution continues to work.

Configuring Endpoints

The rasa.settings.endpoints section allows you to configure various endpoints and integrations. These endpoints are written to the endpoints.yml file in the ConfigMap.

Action Server Endpoint:

The action endpoint URL must be a full HTTP URL. When using the bundled Action Server component, the service name follows the pattern <fullname>-action-server:

rasa:
  settings:
    endpoints:
      action_endpoint:
        url: "http://my-release-action-server:5055/webhook"

Model Storage:

rasa:
  settings:
    endpoints:
      models:
        url: http://my-server.com/models/default_core@latest
        wait_time_between_pulls: 10

Tracker Store (Redis example):

rasa:
  settings:
    endpoints:
      tracker_store:
        type: redis
        url: <host of the redis instance>
        port: 6379
        db: 0
        password: <password>
        use_ssl: false

Tracker Store (PostgreSQL example):

rasa:
  settings:
    endpoints:
      tracker_store:
        type: sql
        dialect: postgresql
        url: <hostname>
        db: <database>
        username: <username>
        password: <password>
        port: 5432

Event Broker (Kafka example):

rasa:
  settings:
    endpoints:
      event_broker:
        type: kafka
        url: localhost:9095
        sasl_mechanism: SCRAM-SHA-512
        security_protocol: SASL_PLAINTEXT
        sasl_username: testuser
        sasl_password: testpass123
        partition_by_sender: true
        client_id: rasa-broker

Model Groups:

Model groups require an LLM provider API key. Inject it as an environment variable from a Kubernetes Secret:

kubectl create secret generic openai-secret \
  --from-literal=apiKey="<YOUR_OPENAI_API_KEY>"

rasa:
  additionalEnv:
    - name: OPENAI_API_KEY
      valueFrom:
        secretKeyRef:
          name: openai-secret
          key: apiKey
  settings:
    endpoints:
      model_groups:
        - id: openai-gpt-4o
          models:
            - provider: openai
              model: gpt-4o-2024-11-20
              request_timeout: 7
              max_tokens: 256

See the Rasa endpoints documentation for complete endpoint configuration options.

Action Server

The chart can optionally deploy a Rasa SDK Action Server alongside Rasa Pro. You must build and publish your own container image from your actions code — there is no default image provided.

actionServer:
  enabled: true
  image:
    repository: "your-registry/your-actions-image"
    tag: "latest"

When enabled, configure Rasa Pro to use it via rasa.settings.endpoints. The Action Server service name follows the pattern <release-name>-action-server:

rasa:
  settings:
    endpoints:
      action_endpoint:
        url: "http://my-release-action-server:5055/webhook"

Duckling

Duckling is a structured entity extraction service. Enable it when your NLU pipeline requires it:

duckling:
  enabled: true

When duckling.enabled: true, the chart automatically sets RASA_DUCKLING_HTTP_URL to the in-cluster service URL — no additional configuration is required.

To connect to an external Duckling instance instead, leave duckling.enabled: false and set the URL explicitly:

duckling:
  enabled: false
rasa:
  settings:
    ducklingHttpUrl: "http://my-external-duckling:8000"

Environment Variables

Use additionalEnv to inject extra environment variables into any component without replacing the chart-managed ones. Both plain values and Secret/ConfigMap references are supported:

rasa:
  additionalEnv:
    - name: MY_VAR
      value: "my-value"
    - name: MY_SECRET_VAR
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: my-key
    - name: MY_CONFIGMAP_VAR
      valueFrom:
        configMapKeyRef:
          name: my-configmap
          key: my-key

Use envFrom to inject all keys from a ConfigMap or Secret as environment variables at once:

rasa:
  envFrom:
    - configMapRef:
        name: my-configmap
    - secretRef:
        name: my-secret

Both additionalEnv and envFrom are available on all components (rasa, rasaProServices, actionServer, duckling).

Loading Initial Models

Use initContainers to download a model before the Rasa server starts. The init container shares the /app/models volume with the main container:

rasa:
  initContainers:
    - name: load-initial-model
      image: alpine
      command: ["/bin/sh", "-c"]
      args:
        - wget https://my-model-server.example.com/models/model.tar.gz -O /app/models/model.tar.gz
      volumeMounts:
        - mountPath: /app/models
          name: models

Ingress

To expose the Rasa API externally, enable the ingress resource. The example below uses nginx with TLS managed by cert-manager:

rasa:
  ingress:
    enabled: true
    className: "nginx"
    annotations:
      cert-manager.io/cluster-issuer: "letsencrypt-prod"
    hosts:
      - host: rasa.example.com
        paths:
          - path: /
            pathType: Prefix
    tls:
      - secretName: rasa-tls
        hosts:
          - rasa.example.com

The Action Server and Duckling components each have their own ingress block with the same structure under actionServer.ingress and duckling.ingress.

Shared ingress settings

The global block carries three ingress settings so an ingress class, a set of annotations and a host can be declared once instead of being repeated:

global:
  ingressClassName: nginx
  ingressAnnotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  ingressHost: rasa.example.com

global.ingressClassName and global.ingressAnnotations are defaults that rasa.ingress overrides. A non-empty rasa.ingress.className wins outright, and rasa.ingress.annotations wins per key while non-conflicting global annotations still merge in.

Note: global.ingressHost behaves differently. It overrides rasa.ingress.hosts[*].host instead of falling back to it, so leave it unset if you need per-host values.

All three apply to the Rasa Pro server ingress only. actionServer.ingress and duckling.ingress are unaffected and must be configured through their own blocks.

global.ingressHost sets the ingress rule host and nothing else. TLS is a separate list that the chart does not derive from it, so a single-host deployment repeats the hostname under rasa.ingress.tls:

global:
  ingressHost: rasa.example.com
rasa:
  ingress:
    tls:
      - secretName: rasa-tls
        hosts:
          - rasa.example.com

Keep the two in sync. If global.ingressHost changes and rasa.ingress.tls[*].hosts is left behind, the chart still renders and applies without complaint: the ingress serves the new host while the TLS section claims the old one, so the controller finds no certificate matching the host it serves and falls back to its default. The symptom is a browser certificate warning rather than a Helm error, which makes it easy to miss.

Because Helm propagates global down the dependency tree after user overrides are merged, a parent chart that bundles this one can set these under its own global block and have them reach this chart. That is how Rasa Studio drives the host of the model-service ingress.

Resources and Autoscaling

No resource requests or limits are set by default. For production, always set these explicitly:

rasa:
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2
      memory: 4Gi

Enable Horizontal Pod Autoscaling (HPA) to scale replicas based on CPU or memory:

rasa:
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 10
    targetCPUUtilizationPercentage: 70
    # targetMemoryUtilizationPercentage: 80

The same resources and autoscaling blocks are available for rasaProServices, actionServer, and duckling.

Pod Topology Spread Constraints

Once a component runs more than one replica, spread its pods across failure domains so a single zone or node outage cannot take all of them down:

rasa:
  replicaCount: 3
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway

A constraint needs a labelSelector to decide which pods to count, and one that selects nothing is silently ignored rather than rejected. The chart therefore fills in the component’s own selector labels whenever an entry omits labelSelector, so the example above means “spread the Rasa Pro server pods across zones” without further configuration. Set labelSelector yourself when you want to count a broader set of pods than the one component.

Each component has its own topologySpreadConstraints block, and they are deliberately independent rather than shared. whenUnsatisfiable in particular should not be applied uniformly: DoNotSchedule gives the Rasa Pro server a hard spread guarantee, but the same setting on a component you run at one or two replicas leaves pods Pending when a zone has no room. Prefer ScheduleAnyway there, or leave the list empty, since a spread constraint over a single replica does nothing.

Setting labelSelector explicitly

A labelSelector selects pods, so it can only match labels the pod template actually carries. Every component labels its pods with app.kubernetes.io/name, which is unique per component, and app.kubernetes.io/instance, which is the release name and therefore identical across all of them, plus anything added through the chart-level podLabels. The selector injected by default is exactly that first pair, which is also what the Deployment uses in spec.selector.matchLabels to own its pods.

Labels set through deploymentLabels or global.additionalDeploymentLabels are attached to the Deployment object rather than to the pods, as are helm.sh/chart and app.kubernetes.io/managed-by. A selector referring to any of those matches no pods, and the constraint is then quietly ignored.

Writing the selector out explicitly is the same as the default, and is worth doing when one component needs several constraints with different scopes:

rasa:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app.kubernetes.io/name: my-release-rasa
          app.kubernetes.io/instance: my-release

To balance several components as a single pool, so that the Rasa Pro server and the Action Server spread together rather than each on its own, give their pods a shared label and select on it. podLabels applies to the pods of every component in this chart:

podLabels:
  rasa.com/spread-group: rasa-stack

rasa:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          rasa.com/spread-group: rasa-stack

actionServer:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          rasa.com/spread-group: rasa-stack

A shared podLabels key is preferable to selecting on app.kubernetes.io/instance for this. The selector cannot be templated, so the release name would have to be spelled out, and when this chart is deployed as a Rasa Studio subchart the Studio components share the same app.kubernetes.io/instance value and would be drawn into the same spread group.

matchExpressions is also available, which is the shorter route to pooling a named subset without introducing a new label:

      labelSelector:
        matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
              - my-release-rasa
              - my-release-rasa-action-server

Rasa Pro Services Kafka Configuration

Rasa Pro Services consumes conversation events from Kafka for the analytics pipeline. Configure the Kafka connection under rasaProServices.kafka:

SASL_SSL (recommended for production):

rasaProServices:
  kafka:
    brokerAddress: "kafka-bootstrap.example.com:9092"
    topic: "rasa-core-events"
    dlqTopic: "rasa-analytics-dlq"
    consumerId: "rasa-analytics-group"
    securityProtocol: "SASL_SSL"
    saslMechanism: "SCRAM-SHA-512"
    saslUsername: "rasa-analytics"
    saslPassword:
      secretName: kafka-credentials
      secretKey: password
    sslCaLocation: "/path/to/ca.pem"

AWS MSK with IAM authentication:

rasaProServices:
  kafka:
    enableAwsMskIam: true
    brokerAddress: "b-1.my-cluster.xxxxx.c1.kafka.us-east-1.amazonaws.com:9098"
    topic: "rasa-core-events"
    dlqTopic: "rasa-analytics-dlq"
  useCloudProviderIam:
    enabled: true
    provider: "aws"
    region: "us-east-1"

Network Policies

Network policies are disabled by default. Enable them to restrict traffic between components:

networkPolicy:
  enabled: true
  denyAll: true
  nodeCIDR:
    - ipBlock:
        cidr: 10.0.0.0/8  # adjust to your node CIDR

Note: When networkPolicy.denyAll is true, you must supply nodeCIDR so that the kubelet can reach pods for liveness and readiness probes.

Warning: The built-in kubelet allowlist only covers the rasa and rasa-pro-services pods. If you enable duckling or actionServer alongside denyAll: true, their liveness and readiness probes will silently fail — the pods will start but Kubernetes will never mark them as ready. You must add NetworkPolicy rules manually to allow kubelet access to those pods before enabling denyAll.

Configuration Reference

The following table lists all configurable parameters for this chart and their default values.

Values