When to Deploy Your Assistant
The best time to deploy your assistant and make it available to test users is once it can handle the most important happy paths or is what we call a minimum viable assistant.
The recommended deployment methods described below make it easy to share your assistant with test users via the share your assistant feature in Rasa X. Then, when you're ready to make your assistant available via one or more Messaging and Voice Channels, you can easily add them to your existing deployment set up.
Recommended Deployment Methods
The recommended way to deploy an assistant is using either the Server Quick-Install or Helm Chart options we support. Both deploy Rasa X and your assistant. They are the easiest ways to deploy your assistant, allow you to use Rasa X to view conversations and turn them into training data, and are production-ready. For more details on deployment methods see the Rasa X Installation Guide.
The Server Quick-Install script is the easiest way to deploy Rasa X and your assistant. It installs a Kubernetes cluster on your machine with sensible defaults, getting you up and running in one command.
Default: Make sure you meet the OS Requirements, then run:curl -s get-rasa-x.rasa.com | sudo bash
For assistants that will receive a lot of user traffic, setting up a Kubernetes or Openshift deployment via our Helm charts is the best option. This provides a scalable architecture that is also straightforward to deploy. However, you can also customize the Helm charts if you have specific requirements.
Default: Read the Helm Chart Installation docs.
Alternative Deployment Methods
You can also run Rasa X in a Docker Compose setup, without the cluster environment. We have an install script for doing so, as well as manual instructions for any custom setups.
Custom: Read the Docker Compose Manual Install documentation for full customization options.
Rasa Open Source Only Deployment
It is also possible to deploy a Rasa assistant without Rasa X using Docker Compose. To do so, you can build your Rasa Assistant locally or in Docker. Then you can deploy your model in Docker Compose.
Deploying Your Action Server
Building an Action Server Image
If you build an image that includes your action code and store it in a container registry, you can run it
as part of your deployment, without having to move code between servers.
In addition, you can add any additional dependencies of systems or Python libraries
that are part of your action code but not included in the base
Automating your Action Server Image Builds
In addition to a manually creating a new Action Server image, you can use the Rasa Action Server GitHub Action to automate image builds. If GitHub Actions are new to you, it might be helpful to get familiar with GitHub Actions Documentation.
The following steps assume that you already created a GitHub repository and you have a DockerHub account.
To create a workflow for building and pushing a Docker image into a DockerHub registry:
Add GitHub Secrets with your DockerHub login name and password. You can find details on how to create encrypted secrets for a repository in the Github docs
The example uses the following secrets:
DOCKER_HUB_LOGIN- a login name for DockerHub
DOCKER_HUB_PASSWORD- a password for DockerHub
In your GitHub repository create a file
The GitHub Action workflow below builds a new docker image every time files inside the
actions/ directory have changed and the changes are pushed into the
Push your changes to the
masterbranch. After changes are pushed, the workflow will build and push a new image into the DockerHub registry.
Now, you can use your new brand docker image.
You can also extend your workflow, so that you do not have to manually update your Rasa X deployment. The example below shows how to extend your workflow with an additional step that updates a Rasa X Helm Chart deployment.
As you can see it's possible to use output variables from the
action_server step. The
steps.action_server.outputs.docker_image_name variable returns
a docker image name and the
steps.action_server.outputs.docker_image_tag variable returns a docker image tag.
Manually Building an Action Server
To create your image:
Make sure your actions are defined in
rasa/rasa-sdkimage will automatically look for the actions in this file.
If your actions have any extra dependencies, create a list of them in a file,
Create a file named
Dockerfilein your project directory, in which you'll extend the official SDK image, copy over your code, and add any custom dependencies (if necessary). For example:# Extend the official Rasa SDK imageFROM rasa/rasa-sdk:2.0.0# Use subdirectory as working directoryWORKDIR /app# Copy any additional custom requirements, if necessary (uncomment next line)# COPY actions/requirements-actions.txt ./# Change back to root user to install dependenciesUSER root# Install extra requirements for actions code, if necessary (uncomment next line)# RUN pip install -r requirements-actions.txt# Copy actions folder to working directoryCOPY ./actions /app/actions# By best practices, don't run the code with root userUSER 1001
You can then build the image via the following command:
<custom_image_tag> should reference how this image will be different from others. For
example, you could version or date your tags, as well as create different tags that have different code for production
and development servers. You should create a new tag any time you update your code and want to re-deploy it.
Using your Custom Action Server Image
If you're building this image to make it available from another server, for example a Rasa X or Rasa Enterprise deployment, you should push the image to a cloud repository.
This documentation assumes you are pushing your images to DockerHub. DockerHub will let you host multiple public repositories and one private repository for free. Be sure to first create an account and create a repository to store your images. You could also push images to a different Docker registry, such as Google Container Registry, Amazon Elastic Container Registry, or Azure Container Registry.
You can push the image to DockerHub via:
To authenticate and push images to a different container registry, please refer to the documentation of your chosen container registry.
How you reference the custom action image will depend on your deployment. Pick the relevant documentation for your deployment: