Terminology
To find out more about the core concepts used in an Automation Suite deployment, see Glossary.
Deployment modes and use cases
Automation Suite supports the following two deployment modes:
Deployment mode | Description |
---|---|
Single-node — evaluation | Supported for evaluation and demo scenarios. Single-node evaluation profile requirements and installation |
Multi-node — production, HA-enabled | Supported for production use. You can perform additional configuration post-deployment to have full HA capabilities. Multi-node HA-ready production profile requirements and installation |
See Supported use cases for single-node and multi-node installations for more details on how to choose the deployment mode that you best suit your needs.
Deployment architecture
Node types

A server node hosts cluster management services (control plane) that perform important cluster operations such as workload orchestration, cluster state management, load balance incoming requests, etc. Kubernetes may also run a few of the UiPath products and shared components based on underlying resource availability.
An agent node is responsible for running the UiPath products and shared components only.
A specialized agent node runs special workloads like Task Mining analysis and Document Understanding pipelines that require GPU capability. However, the core Task Mining and Document Understanding services still run on the server or agent nodes. Specialized agent nodes do not host any of the UiPath product or shared components.
Note:
Automation Suite cannot guarantee which UiPath product runs on each node. This is solely managed by Kubernetes.
Single-node evaluation deployment
A single-node evaluation deployment here means a single-server node. This does not imply the deployment of the entire Automation Suite on a single machine. You may have to add additional agent or specialized agent nodes if the entire product suite cannot fit in a single server node, or if you want to run special tasks like Task Mining analysis and Document understanding pipelines, which require GPU capabilities.

Multi-node HA-ready production deployment
A multi-node HA-ready production deployment involves 3 or more server nodes behind a load balancer. This is to ensure that, in the event of disaster, when any of the server nodes goes down, Automation suite is still available to perform critical business workflows. The number of agent nodes is optional and is based on actual usage.

High Availability Add-on
In a multi-node setup, High Availability (HA) is enabled by default. However, the Redis-based in-memory cache used by cluster services is running on a single pod and represents a single point of failure. To mitigate the impact of a cache node failure or restart, you can purchase the High Availability Add-on (HAA), which enables redundant, multi-pod deployment of the cache.
For more details on how to enable HAA in a multi-node setup, see Enabling High Availability Add-on for the cluster.
Online deployment
An online deployment means Automation Suite requires access to the internet during both installation and runtime. All the UiPath products and supporting libraries are hosted either in UiPath registry or UiPath-trusted third party store.
You can restrict access to the internet with the help of either a restricted firewall or a proxy server, by blocking all the traffic over the internet other than what is required by Automation Suite. This type of setup is also known as semi-online deployment. For more details, see Configuring the firewall and Configuring the proxy server.
These types of deployments are easier, faster, and require fewer hardware resources to install and manage as compared to offline deployments.

Offline deployment
An offline deployment (air-gapped) is a completely isolated setup without access to the internet. This kind of setup requires the installation of an additional registry to store all the UiPath products' container images and binaries, which are shipped in the form of tarball.

IMPORTANT
Uploading binaries (hydration) to registry introduces additional burden of higher hardware requirements, increased installation complexity regarding additional processes and time to install as compared to online deployment. Offline installation increases not only the complexity during installation, but also the cluster management operations like machine maintenance, disaster recovery, upgrading to newer versions, applying security patches, etc.
You are not allowed to change the deployment method post-installation. This means that you cannot change to offline if the installation is done online and vice versa. It is recommended to choose your deployment strategy after careful consideration.
Automation Suite architecture

The Automation Suite installer bundles both required and optional components.
The following table lists out these components:
Component | Optional/Required | Description |
---|---|---|
RKE2 | Required | Rancher-provided Kubernetes distribution. It is the container orchestration platform that runs all the architectural components and services. |
Rancher Server | Required | Rancher’s Kubernetes management tool. |
Longhorn | Required | Rancher-provided distributed block storage for Kubernetes. It helps expose external storages inside Kubernetes clusters for workloads to claim and use like mounted persistent storage. |
CEPH Object Store | Required | Open-source storage provider that exposes Amazon S3-compliant object/blob storage on top of persistent volumes created by Longhorn. It enables services to use blob storage like functionality for their operations. |
Argo CD | Required | Open-source declarative CD tool for Kubernetes. It follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state. It provides application lifecycle management (ALM) capabilities for Automation Suite components and UiPath services that run in a Kubernetes cluster. |
Docker registry | Required | Open-source docker registry used for pushing and pulling install time and runtime container images in your premises. |
Istio | Required | Open-source service mesh that provides functionality such as ingress, request routing, traffic monitoring etc., for the microservices running inside the Kubernetes cluster. |
Prometheus | Required | Open-source system monitoring toolkit for Kubernetes. It can scrape or accept metrics from Kubernetes components as well as workloads running in the clusters and store those in time series database. |
Grafana | Required | Open-source visualization tool used for querying and visualizing data stored in Prometheus. You can create and ship a variety of dashboards for cluster and service monitoring. |
Alertmanager | Required | Open-source tool that helps handling alerts sent by client applications such as the Prometheus server. It is responsible for deduplicating, grouping, and routing them to the correct receiver integrations, such as email, PagerDuty, or OpsGenie. |
Redis | Required | Redis Enterprise non-HA (single shard) used by some UiPath services to get centralized cache functionality. |
RabbitMQ | Required | Open-source reliable message broker used by some UiPath services to implement asynchronous execution patterns. |
MongoDB | Optional | MongoDB is a source-available cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas. MongoDB is deployed only when UiPath Apps is enabled |
FluentD and Fluentbit | Required | Open-source reliable log scraping solution. The logging operator deploys and configures a background process on every node to collect container and application logs from the node file system. |
Gatekeeper | Required | Open-source tool that allows a Kubernetes administrator to implement policies for ensuring compliance and best practices in their cluster. |
External components
You also need to bring a few external components, such as external load balancers, an SQL server, blob/file storage, key vaults, log sinks, and notification tools. Note that the suite provides some extension points.
Updated 5 months ago