Build your first agent in just a few minutes with [Rasa Copilot](https://hello.rasa.com/?utm_source=docs&utm_medium=referral&utm_campaign=docs_cta).

## Warning
Before you begin, ensure you've completed all the previous sections to deploy required infrastructure and to set environment variables that this section requires.

We have now deployed all the required infrastructure and configured everything required on our cluster. We will now proceed to actually install Rasa Pro using the Rasa Helm Chart. In this section, we will:

- Install Kafka, which is used by components of Rasa and Studio to communicate.
- Install Rasa itself using its Helm chart.
- Deploy a TLS certificate and Kubernetes Ingress to make your assistant available outside the cluster via HTTPS.

## Kafka Installation  
We will begin by setting up Kafka, which is used by Rasa Pro and Rasa Studio to communicate with each other, as well as for internal purposes.

You can run the following script to deploy Kafka with an autogenerated random password for authentication. When we setup the assistant in the next step, it will automatically fetch this password and save it in a Kubernetes secret so that other Rasa components can connect to Kafka. You will see some warnings about authentication failures until everything is up and running and it should eventually succeed.

```bash
./aws/rasa/kafka/install-kafka.sh
```

At the end, you should see here that topics called `rasa` and `rasa-events-dlq` have been created. This means that you have now successfully deployed Kafka into the cluster.

## Assistant Setup  
Now that we've set up Kafka, we can set up the Rasa assistant using the Rasa Helm Chart.

You can run our script to perform the initial setup for the Assistant, and then we'll walk you through the setup that it's most important to understand.

```bash
./aws/rasa/assistant/setup-assistant.sh
```

### Values File  
The `values.yaml` file will contain all the configuration that gets applied to your assistant by Helm. You can read about all the available configuration options [here](https://github.com/RasaHQ/rasa-helm-charts/tree/main/charts/rasa), and you can fully customise your setup to meet your organisation's needs and security policies. For simplicity, we've provided a file in the playbook repo `aws/rasa/assistant/values.template.yaml` that sets all the key values we need to integrate Rasa with the AWS infrastructure we've already deployed, leaving placeholder values for things we want to inject as environment variables. You can set these values manually and add any others you require, but we recommend you begin by automatically creating a version with all the environment variables set from the previous sections:

```bash
envsubst "$(printf '$%s ' $(env | cut -d= -f1))" < aws/rasa/assistant/values.template.yaml > aws/rasa/assistant/values.yaml
```

If you open this newly created file, you should see that all of your values have been automatically populated from the environment variables we've been setting as we go along.

#### Pin the Rasa Pro Image to Match Your Local CLI  
Rasa Pro models are version-locked to the CLI that produced them — running a model trained with one Rasa Pro version against an image with a different version may cause the assistant to fail to load.

Check your local CLI version:

```bash
rasa --version
```

Then in `aws/rasa/assistant/values.yaml`, set `rasa.image.tag` to match. For example, if `rasa --version` prints `Rasa Pro Version : 3.16.5`:

```yaml
rasa:
  image:
    repository: "rasa/rasa-pro"
    tag: "3.16.5"
```

#### Align `modelGroups` with Your Trained Bot  
The `endpoints.modelGroups` block in `values.template.yaml` declares which LLM model groups the assistant can reference. The bot you trained must reference only model groups that are declared here, otherwise it will fail to load with an error like:

```text
Failed to load agent: Your <component>'s 'llm' configuration of the trained model
references the model group '<your-id>', but this model group DOES NOT EXIST in
the endpoints.yml file.
```

Open your bot's `endpoints.yml` and copy the `model_groups` block into `aws/rasa/assistant/values.yaml` under `endpoints.modelGroups` (note the camelCase). For example, if your bot's `endpoints.yml` contains:

```yaml
model_groups:
  - id: openai-gpt-5-1
    models:
      - provider: openai
        model: gpt-5.1-2025-11-13
        reasoning_effort: "none"
        timeout: 15
```

Then `values.yaml` should include the same group under `endpoints.modelGroups`:

```yaml
rasa:
  settings:
    endpoints:
      modelGroups:
      - id: openai-gpt-5-1
        models:
        - provider: openai
          model: gpt-5.1-2025-11-13
          reasoning_effort: "none"
          timeout: 15
```

## Upload Your Trained Model  
The Rasa Helm chart is configured to load your trained model from the S3 model bucket on startup. Before deploying, upload your model to that bucket.

The chart uses `--remote-storage aws` with the default `--model models`, which means it downloads the model from `s3://${MODEL_BUCKET}/models.tar.gz` — **at the bucket root, with the file named `models.tar.gz`**:

```bash
aws s3 cp <your-bot>/models/<your-trained-model>.tar.gz s3://${MODEL_BUCKET}/models.tar.gz
aws s3 ls s3://${MODEL_BUCKET}/   # confirm models.tar.gz is at the root
```

Do **not** upload to `s3://${MODEL_BUCKET}/models/model.tar.gz` (with a folder prefix). The Rasa pod looks for `models.tar.gz` at the bucket root and will fail to start with a `ModelNotFound` error if the path is wrong.

## Deploy Rasa  
Now that all the configuration is done, you can deploy Rasa using all the configuration that you've set:

```bash
helm upgrade --install -n $NAMESPACE rasa aws/rasa/assistant/repos/rasa-helm/rasa -f aws/rasa/assistant/values.yaml
```

You can ignore the instructions that will be printed by the above command to use port forwarding to access the deployment.

Check yourself if the Rasa pod has a status of `RUNNING` by running:

```bash
kubectl get pods --namespace $NAMESPACE -l "app.kubernetes.io/name=rasa,app.kubernetes.io/instance=rasa"
```

## Configure Ingress & TLS Certificate  
Finally, we can deploy a Kubernetes Ingress and a TLS certificate for the Rasa Pro deployment. This will allow us to interact with the bot from outside the cluster.

We'll create a certificate and deploy an ingress with another script:

```bash
./aws/rasa/ingress/setup-ingress.sh
```

You will need to wait a few minutes while your certificate is issued and the DNS records propagate. Finally, you will be able to visit your assistant's URL: `https://assistant.$DOMAIN`. For example, if the value you used for `$DOMAIN` was `example.com`, you could visit your assistant on `https://assistant.example.com` If you receive "Hello from Rasa" response, you have successfully deployed Rasa Pro. If you receive an error, there may just be a delay in issuing the certificate or having the DNS records propagate - wait a few minutes and try again!

A2A server with multiple replicas

If you enable `a2a_server` under Rasa endpoints Helm values and run more than one Rasa replica, configure sticky load balancing separately — the playbook ingress script does not include this by default. Apply an Istio EnvoyFilter and DestinationRule as described in [Multi-replica load balancing](/content/docs/reference/integrations/a2a-server/#istio-on-kubernetes/index.html).
