Deployment architecture

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.
Multi-node — production, HA-enabled	Supported for production use. You can perform additional configuration post-deployment to have full HA capabilities.

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

This page offers insight into the Automation Suite architecture and describes the components bundled into the installer.

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, Document Understanding pipelines that require GPU capability, or Automation Suite Robots. However, the core Task Mining, Document Understanding, or Automation Suite Robots services still run on the server or agent nodes. Specialized agent nodes do not host any of the UiPath product or shared components.

Important: 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.

Note:

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 following diagram depicts the Automation Suite architecture. Note that the Docker registry and the S3-compatible objectstore can also be hosted externally.

The following table lists out the third-party components shipped with Automation Suite:

Component	Optional/Required	Description
RKE2	Required	Rancher-provided Kubernetes distribution. It is the container orchestration platform that runs all the architectural components and services.
CEPH Object Store	Optional if you have an external objectstore	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	Optional if you have an external registry	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.
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.
Velero	Required1	Open-source tool that allows you to take a snapshot backup and restore.
Thanos	Required	Open-source tool to push the Prometheus matrix to an objectstore for persistence.

^{1 Only installed during backup and restore.}

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.