- Overview
- Requirements
- Prerequisites at a glance
- Kubernetes cluster and nodes
- Proxy
- SQL database
- Caching
- Storage
- Networking
- Certificate requirements
- Pre-installation
- Preparing the installation
- Downloading the installation packages
- Configuring the OCI-compliant registry
- Granting installation permissions with cluster roles
- Granting installation permissions without cluster roles
- Installing and configuring the service mesh
- Installing and configuring the GitOps tool
- Installing the External Secrets Operator
- Deploying Redis through OperatorHub
- Applying miscellaneous configurations
- Running uipathctl
- Installation
- Post-installation
- Migration and upgrade
- Monitoring and alerting
- Cluster administration
- Product-specific configuration
- Orchestrator advanced configuration
- Configuring Orchestrator parameters
- Configuring appSettings
- Configuring the maximum request size
- Overriding cluster-level storage configuration
- Configuring NLog
- Saving robot logs to Elasticsearch
- Configuring credential stores
- Configuring encryption key per tenant
- Cleaning up the Orchestrator database
- Skipping host library installation
- AI Trust Layer
- Troubleshooting
- 500 errors and rate limiting on S3 requests in ODF
- External Secrets troubleshooting
- Configuring CSI driver tolerations for ODF 4.20
- Temporal as a Service troubleshooting
- AI Center and Document Understanding pods fail to start with TLS certificate verification enabled
- Studio Desktop cannot load Integration Service connectors and activities
- TLS certificate validation errors
- Manual ArgoCD NetworkPolicy mitigation (GHSA-47m3-95c7-g2g8)
- Configuring resource requests and limits for uipathctl-created workloads
Kubernetes cluster and nodes
Kubernetes cluster and node requirements for Automation Suite on OpenShift.
Cluster and permissions
You can bring your own Kubernetes cluster and follow your standard practices to provision and manage it.
An admin user must install specific required components separately, before the Automation Suite platform installation. After installing the required components, you can execute the installer. For the list of required permissions, refer to Granting installation permissions.
Node capacity
To estimate node capacity based on your product and scale requirements, use the UiPath Automation Suite Install Sizing Calculator.
The root volume requirement for agent (worker) nodes is 256 GB.
At a minimum, to start with the mandatory platform services (Identity, licensing, and routing) and Orchestrator, you must provision 8 vCPU and 16 GB RAM per node.
We do not recommend using spot instances in Automation Suite in production scenarios, due to stability and performance issues.
Autoscaling
We recommend enabling autoscaling on your cluster to ensure high reliability and to avoid business interruptions.
Additional Automation Suite Robots requirements
Automation Suite Robots require additional worker node(s).
The hardware requirements for the Automation Suite Robots node depend on the way you plan to use your resources. In addition to the additional agent node requirements, you also need a minimum of 10 GB of file storage to enable package caching.
For details, refer to Storage documentation.
The following sections describe the factors that impact the amount of hardware the Automation Suite Robots node requires.
Robot size
The following table describes the required CPU, RAM, and storage for all robot sizes.
| Size | CPU | RAM | Storage |
|---|---|---|---|
| Small | 0.5 | 1 GB | 1 GB |
| Standard | 1 | 2 GB | 2 GB |
| Medium | 2 | 4 GB | 4 GB |
| Large | 6 | 10 GB | 10 GB |
Agent node size
The resources of the Automation Suite Robots agent node have an impact on the number of jobs that can be run concurrently. The reason is that the number of CPU cores and the amount of RAM capacity are divided by the CPU/RAM requirements of the job.
For example, a node with 16 CPUs and 32 GB of RAM would be able to run any of the following:
- 32 Small jobs
- 16 Standard jobs
- 8 Medium jobs
- 2 Large jobs
Job sizes can be mixed, so at any given moment, the same node could run a combination of jobs, such as the following:
- 10 Small jobs (consuming 5 CPUs and 10 GB of RAM)
- 4 Standard jobs (consuming 4 CPUs and 8 GB of RAM)
- 3 Medium jobs (consuming 6 CPUs and 12 GB of RAM)
Kubernetes resource consumption
Given that the node is part of a Kubernetes cluster, the Kubernetes agent present on the server (kubelet) consumes a small amount of resources. Based on our measurements, the kubelet consumes the following resources:
- 0.6 CPU
- 0.4 GB RAM
A node similar to the one previously described would actually have approximately 15.4 CPUs and 31.6 GB of RAM.
Automatic machine size selection
All your cross-platform processes have the Automation Suite Robots option set to Automatic by default. This setting selects the appropriate machine size for running the process using serverless robots.
When automatically choosing the size, the criteria listed in the following table are evaluated in order. As soon as one criterion is satisfied, the corresponding machine size is chosen and the remaining criteria are not evaluated.
| Order | Criterion | Machine size |
|---|---|---|
| 1 | Remote debugging job | Medium |
| 2 | Process depends on UI Automation OR Process depends on the UiPath Document Understanding activities | Standard |
| 3 | Other unattended process | Small |
Additional Document Understanding recommendations
For increased performance, you can install Document Understanding on an additional agent node with GPU support. Note, however, that AI Center-based projects in Document Understanding are fully functional without the GPU node. Actually, Document Understanding uses CPU VMs for all its extraction and classification tasks, while for OCR we strongly recommend the usage of a GPU VM.
For details about the CPU/GPU usage within the Document Understanding framework, refer to CPU and GPU Usage.
If you want to use an additional node with GPU support, you must meet the following requirements:
| Hardware | Minimum requirement |
|---|---|
| Processor | 8 (v-)CPU/cores |
| RAM | 52 GB |
| OS disk | 256 GB SSD Min IOPS: 1100 |
| Data disk | N/A |
| GPU RAM | 11 GB |
When adding the GPU node pool, taint the nodes with --node-taints nvidia.com/gpu=present:NoSchedule. Automation Suite GPU workloads are configured to tolerate the nvidia.com/gpu taint key only, so you must use this exact key. If you taint the nodes with a different key, the scheduler cannot place the GPU pods on the node and they remain unscheduled.
To ensure proper scheduling of GPU workloads, make sure your DaemonSet (NFD or Nvidia GPU Operator) YAML configuration includes a matching tolerations block.
You can use the following example:
tolerations:
- key: "nvidia.com/gpu"
operator: "Equal"
value: "present"
effect: "NoSchedule"
tolerations:
- key: "nvidia.com/gpu"
operator: "Equal"
value: "present"
effect: "NoSchedule"
Automation Suite supports NVIDIA GPUs. To learn about how to configure NVIDIA GPUs (such as drivers), refer to the OpenShift documentation.
Additional Document Understanding modern projects requirements
With CPU inference activated, a minimum of 2 GPUs is required.
To enable CPU inference, set the enable_cpu_inference property to true, as indicated in the Enabling or disabling Document Understanding section.
Inference may be up to 10 times slower. We recommend using it for documents with a maximum of 125 pages, as inference might fail for larger documents.
Without CPU inference, a minimum of 5 GPUs is required for Document Understanding modern projects. The example scenario in the following table demonstrates how 5 GPUs is enough to process 300 pages.
For Document Understanding modern projects, the minimum recommended GPU is NVIDIA T4.
| Function | Number |
|---|---|
| Custom model pages processed per hour | 300 |
| Out of the box model pages processed per hour | 0 |
| Models training in parallel | 1 |
| Number of pages in all projects - Design time | 200 |
| Number of document types per project version | 3 |
The 5 GPUs are distributed amongst different functions, as detailed in the following table:
| Service | Number of GPUs |
|---|---|
| OCR replicas | 1 |
| Custom model training replicas | 1 |
| Custom model replicas | 2 |
| Out of the box model replicas | 1 |
| Total | 5 |
In addition to the GPU demands, Document Understanding modern projects also require specific CPU resources for optimal performance. For optimal performance, a minimum of 18 vCPUs is required.
With the modern Document Understanding project, an additional 4 TB of the objectstore is required to perform the activities from the provided examples continuously for one year. You can start with a smaller number, but the activity will fail once the storage is complete, unless you explicitly scale it.
If you are provisioning for one year of continuous processing, you will need 4 TB for Document Understanding modern projects and 512 GB for the other products. The total will be 4.5 TB of storage. Similarly, if you start with six months of processing, you will need 2 TB for Document Understanding modern projects and 512 GB for the other products. In this case the total will be 2.5 TB.
For more detailed calculations and the capacity required for your needs, refer to the UiPath Automation Suite Install Sizing Calculator.
Provisioning MIG-enabled GPUs
Automation Suite Document Understanding workloads support running on Virtual GPUs (VGPUs) created with NVIDIA MIG (Multi-Instance GPU) technology.
To run Document Understanding in these conditions, keep in mind the following requirements:
- GPU memory (VRAM): at least 16 GB per VGPU. UiPath only supports the single strategy, meaning that all VGPUs will be exactly the same.
- Storage: at least 80 GB per VGPU
Enabling MIG-enabled GPUs in Kubernetes
After provisioning the MIG enabled GPUs in your cluster with profiles matching or exceeding the above minimum requirements, ensure that the GPUs are schedulable Kubernetes. The node must report a non-zero number of GPUs before workloads can be scheduled on it.
To make the GPUs schedulable, you have two options:
- Option A: Follow the official GPU setup documentation of your cloud provider, or the one on the NVIDIA website:
- NVIDIA Documentation: MIG Support in OpenShift Container Platform
- IBM Developer Documentation: Implementing NVIDIA MIG in Red Hat OpenShift
- Option B (Alternative): Deploy the NVIDIA device plugin directly:
- Create a new namespace:
kubectl create namespace gpu-resourceskubectl create namespace gpu-resources - Apply the following configuration, replacing
migEnabledPoolNamewith the label that matches your GPU node:apiVersion: v1 kind: Pod metadata: name: nvidia-device-plugin-pod namespace: gpu-resources spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: agentpool operator: In values: # To be changed to a selector that matches the GPU nodes - migEnabledPoolName containers: - args: - --fail-on-init-error=false env: - name: MPS_ROOT value: /run/nvidia/mps - name: MIG_STRATEGY # We only support the single strategy for now value: single - name: NVIDIA_MIG_MONITOR_DEVICES value: all - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: compute,utility image: nvcr.io/nvidia/k8s-device-plugin:v0.17.3 imagePullPolicy: IfNotPresent name: nvidia-device-plugin-ctr securityContext: allowPrivilegeEscalation: true capabilities: add: - SYS_ADMIN terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin tolerations: - key: CriticalAddonsOnly operator: Exists - effect: NoSchedule key: nvidia.com/gpu operator: Exists terminationGracePeriodSeconds: 30 volumes: - hostPath: path: /var/lib/kubelet/device-plugins type: "" name: device-pluginapiVersion: v1 kind: Pod metadata: name: nvidia-device-plugin-pod namespace: gpu-resources spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: agentpool operator: In values: # To be changed to a selector that matches the GPU nodes - migEnabledPoolName containers: - args: - --fail-on-init-error=false env: - name: MPS_ROOT value: /run/nvidia/mps - name: MIG_STRATEGY # We only support the single strategy for now value: single - name: NVIDIA_MIG_MONITOR_DEVICES value: all - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: compute,utility image: nvcr.io/nvidia/k8s-device-plugin:v0.17.3 imagePullPolicy: IfNotPresent name: nvidia-device-plugin-ctr securityContext: allowPrivilegeEscalation: true capabilities: add: - SYS_ADMIN terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin tolerations: - key: CriticalAddonsOnly operator: Exists - effect: NoSchedule key: nvidia.com/gpu operator: Exists terminationGracePeriodSeconds: 30 volumes: - hostPath: path: /var/lib/kubelet/device-plugins type: "" name: device-plugin
- Create a new namespace:
After deploying the plugin, the node's Allocatable section should show the correct number of VGPUs under nvidia.com/gpu, based on the MIG profile you configured. The node should now be schedulable and ready to run Document Understanding workloads.
Additional Temporal as a Service (TaaS) requirements
When Maestro is enabled, TaaS runs as a set of Kubernetes deployments within the cluster. In the default profile, TaaS requires a minimum of 5.5 vCores and 5.5 GB RAM of available cluster headroom.
Deployments
TaaS consists of the following Kubernetes deployments, each responsible for a distinct function within the Temporal service:
| Deployment | Description |
|---|---|
taas-temporal-frontend | Entry point for all client connections to the Temporal service |
taas-temporal-internalFrontend | Handles internal inter-service communication within the cluster |
taas-temporal-history | Manages workflow execution history and state transitions |
taas-temporal-matching | Matches scheduled tasks to available workers for execution |
taas-temporal-worker | Processes internal Temporal system workflows |
taas-temporal-web | Web UI for visualizing and monitoring workflows |
taas-temporal-admintools | Utility deployment for issuing Temporal admin commands within the cluster |
Pod resource requirements
The following table lists the CPU and memory requests and limits for each TaaS deployment. Resource settings are the same across all TaaS profiles.
| Deployment | CPU request | CPU limit | Memory request | Memory limit |
|---|---|---|---|---|
taas-temporal-frontend | 250m | 1 | 256Mi | 256Mi |
taas-temporal-internalFrontend | 250m | 1 | 256Mi | 256Mi |
taas-temporal-history | 250m | 1 | 4Gi | 4Gi |
taas-temporal-matching | 250m | 1 | 512Mi | 512Mi |
taas-temporal-worker | 100m | 1 | 256Mi | 256Mi |
taas-temporal-web | 100m | 200m | 128Mi | 128Mi |
taas-temporal-admintools | 100m | 200m | 128Mi | 128Mi |
Autoscaling
TaaS uses Horizontal Pod Autoscaler (HPA) for select deployments. The scaling behavior depends on the TaaS profile, as described in the following table.
| Default | Lite | HA | |
|---|---|---|---|
| Autoscaling enabled | No | Yes | Yes |
| HPAs created | 0 | 4 | 4 |
taas-temporal-frontend replicas | 1 (static) | 1–3 (CPU 80%) | 2–3 (CPU 80%) |
taas-temporal-internalFrontend replicas | 1 (static) | 1–3 (CPU 80%) | 2–3 (CPU 80%) |
taas-temporal-history replicas | 1 (static) | 1–5 (CPU 80% + Mem 70%) | 2–5 (CPU 80% + Mem 70%) |
taas-temporal-matching replicas | 1 (static) | 1–3 (CPU 80%) | 2–3 (CPU 80%) |
taas-temporal-worker replicas | 1 (static) | 1 (static) | 2 (static) |
taas-temporal-web replicas | 1 (static) | 1 (static) | 1 (static) |
taas-temporal-admintools replicas | 1 (static) | 1 (static) | 1 (static) |
| PDBs | disabled | enabled | enabled |
| numHistoryShards | 64 | 128 | 256 |
Node scheduling
Node taints and labels are required for Automation Suite Robots. For Document Understanding, they are recommended.
AI Center and DU example:
-
For CPU:
oc taint node <node_name> aic.ml/cpu=present:NoScheduleoc taint node <node_name> aic.ml/cpu=present:NoSchedule -
For GPU:
oc taint node <node_name> nvidia.com/gpu=present:NoScheduleoc taint node <node_name> nvidia.com/gpu=present:NoSchedule
Automation Suite Robots example:
You must configure a dedicated worker node with the correct taint and labels for Automation Suite Robots. Without these, asrobots pods fail to schedule regardless of available resources on other nodes.
Run both of the following commands - the taint alone is not sufficient:
oc taint node <node_name> serverless.robot=present:NoSchedule
oc label node <node_name> serverless.robot=true serverless.daemon=true
oc taint node <node_name> serverless.robot=present:NoSchedule
oc label node <node_name> serverless.robot=true serverless.daemon=true
If you have custom node taints that are enforced by Gatekeeper Policy, such as specific roles for worker nodes or labels, they will not be passed to Automation Suite and may interrupt the installation process.
To learn about taints and tolerations, refer to Kubernetes documentation.
Additional self-hosted model requirements
Self-hosted models require GPU hardware. Minimum requirements depend on model size:
| Model size | Minimum GPU configuration |
|---|---|
| 7B parameters | 1 × 80 GB GPU |
| 70B parameters | 4 × 80 GB GPU |
| 120B+ parameters | 8 × 80 GB GPU |
For details, refer to Self-hosted models.
- Cluster and permissions
- Node capacity
- Autoscaling
- Additional Automation Suite Robots requirements
- Robot size
- Agent node size
- Kubernetes resource consumption
- Automatic machine size selection
- Additional Document Understanding recommendations
- Additional Document Understanding modern projects requirements
- Provisioning MIG-enabled GPUs
- Additional Temporal as a Service (TaaS) requirements
- Deployments
- Pod resource requirements
- Autoscaling
- Node scheduling
- Additional self-hosted model requirements