Self-hosted On-demand Workers

Overview

On-demand Workers are a way of executing robots on self-hosted infrastructure. On-demand Workers allow for spinning up an unattended worker only when there is a need to run a robot. Compared to having Robocorp Workforce Agent-2s running on VM's or dedicated servers, the on-demand way of running can bring significant cost savings.

The unattended workers can be containers running on Kubernetes, virtual machines running on Cloud infrastructure, or anything else that can connect to Control Room as an unattended worker.

On-demand Workers -feature is available on Pro and Enterprise plans. To ensure a smooth and secure implementation, we encourage getting in touch with your customer success representative to plan the deployment together with us.

On-demand Worker Provisioner

To use On-demand Workers, an On-demand Worker Provisioner is needed. The provisioner is a service that runs on local infrastructure, listens for requests for new Workers from Control Room, authenticates those requests, and starts and stops Workers as requested.

The provisioner provides a webhook endpoint that allows Control Room to communicate with the provisioner. This means the webhook endpoint needs to be accessible over the internet.

The request is authenticated using a Hash-based Message Authentication Code (HMAC) and a shared secret configured to Control Room and the Provisioner.

The request to start a new unattended worker contains a one-time link token, unattended worker ID and workspace ID. The provisioner is responsible for starting a new unattended worker that links itself to Control Room using the link token provided.

Control Room will recognize when the unattended worker with the correct unattended worker ID and workspace ID is linked and will immediately start the execution of the needed robot on it.

The following is an example sequence diagram of executing a simple process that contains only one step that uses On-demand Workers.

On-demand Workers - example

On-demand Worker Provisioner API

Documentation for the API can be found under the Control Room APIs and webhooks documentation.

Example implementations of the API done in Typescript can be found in the examples described in the following chapters.

Provisioner implementations

Robocorp provides two example implementations of On-demand Worker Provisioners. The examples are designed to be production quality, but modifications may be required to adapt them to fit specific use cases.

Kubernetes Provisioner

The Kubernetes example executes robots on containers in the Kubernetes cluster are started when robot execution is requested and immediately shut down once robot execution is finished.

The example contains an example Terraform project for provisioning the required infrastructure, a scaffold project for the provisioner and a helm chart for deploying it. The actual provisioner is written in Typescript and uses an Express server for the webhook.

You can find a Kubernetes example on Robocorp GitHub

Azure Windows VM Provisioner

The Azure example executes robots in a virtual machine where every robot gets its own virtual machine provisioned that are torn down after the robot completes. The robot is booted into a Windows VM, which you can also configure to install custom windows software on the machine image itself. The VM itself is booted against an actual user session, allowing windows UI automation in a repeatable fashion against machines that scale with each robot.

The example contains Azure functions - application that does the provisioning and teardown, terraform infrastructure and a way to build the azure VM image.

You can find Azure example on Robocorp GitHub

When a process step with an On-demand Worker is executed in Control Room following actions happen:

Control Room calls the configured On-demand Worker Provisioner, which triggers the worker start and linking.
Control Room detects when the Worker comes online and the step execution starts on that worker.

Last edit: November 22, 2022