How cloud robots work with Orchestrator

Division of responsibility between Orchestrator as the control plane and robots as the execution layer, covering job dispatch, runtime allocation, and what differs by robot type.

Orchestrator and the robot do different jobs. Orchestrator decides what runs, where it runs, and which folder resources the job can use. The robot provides the execution environment and runs the workload. Network connectivity to your own systems is configured outside both, at tenant level.

Every robot type connects to Orchestrator the same way and appears as a machine in the same folder structure, whether the host is self-managed, provided by UiPath, or scaled automatically in your own cloud account.

What each side owns

Orchestrator — the control plane	The robot — the execution layer
The machine object and machine template, including runtime and slot allocation	The operating system, installed software, and local dependencies
Which process types and runtime types a job can use	The execution of the workload itself
Job dispatch, scheduling, and triggers	Reporting status, logs, and traces back to Orchestrator
Folder-scoped resources: assets, queues, storage buckets, connections	Reaching the systems the automation targets
Licensing and consumption accounting	Declaring which process types and runtimes it supports

How a job reaches a robot

1. A job starts from a trigger, a schedule, or a manual start, with a runtime type selected.
2. Orchestrator checks the machine templates assigned to the folder for available runtimes or slots of that type.
3. Connected robots report which process types and runtime types they support.
4. Orchestrator dispatches the job only to a robot that supports both.
5. The robot runs the workload and streams status and logs back to Orchestrator.
6. On completion, the runtime or slot returns to the pool.

Note:

A job stays in the Pending state while it is queued on a robot or while Orchestrator is trying to establish a connection to one. Whether Agent, Function, API, and RPA runtime types behave identically while pending, or whether some runtime types fail to start instead of waiting, is not confirmed in the current documentation set and should be verified with engineering before this distinction is published as fact.

What differs by robot type

Robot type	Host provided by	Robot version managed by
Self-hosted robot	You	You
Automation Cloud Robots — VM	UiPath	UiPath, with an opt-out
Automation Cloud Robots — Serverless	UiPath	UiPath
Elastic Robot Orchestration	You, in your own cloud account	UiPath, with an opt-out
Automation Suite robots	You, in your cluster	Your Automation Suite version

Availability differs by cloud platform. For details, refer to Cloud robots feature availability. Automation Suite robots are documented as their own Automation Suite delivery of this guide — select your Automation Suite version from the guide's version switcher, or refer to About Automation Suite Robots for the current long-term support version.

What is configured outside Orchestrator

Reaching systems inside your own network is a tenant-level setting, not an Orchestrator one. The gateway is created in Admin, under the selected tenant's Gateway tile, together with its address space, connections, and routing. For details, refer to Configuring VPN for cloud robots.

Orchestrator only consumes an existing gateway: a Cloud Robot - VM pool selects Connect VPN Gateway when it is created, and a Serverless machine template enables the same integration through Managing VPN settings.

Important:

An existing Cloud Robot - VM pool cannot be connected to a VPN gateway afterwards — a pool that needs one is created with the option selected. Once a pool is disconnected through the Enable VPN Integration toggle, it cannot be reconnected. Serverless machine templates can toggle VPN integration on or off and edit the address space at any time; robots on that template reconnect automatically according to the new settings.

Where each topic is documented

Setup, requirements, capacity, and workload support for each robot type live in the Robot guides. The control-plane objects a robot depends on remain in the Orchestrator guide:

• Machines and machine templates, including runtime and slot allocation
• Jobs and job states
• Licensing and consumption