Find the Worker setup for you
Workers are what execute the robot tasks on remote machines and are assigned to steps in unattended processes. They can be managed in the Control Room from the Workers view. What kind of a Worker setup you should use will depend highly on your use case. Optimally, if your use case supports it, by using Robocorp hosted Cloud Workers you won't need to worry about setting up or hosting any infrastrucure by yourself.
Find the correct setup for you
When running unattended robots, we provide a whole host of different options to set up the infrastructure for your automations.
So, where should you get started? This article is here to help you out, and the the picture image below shows the big picture.
Remember, you are NOT bound machine or user-specific licenses.
It does not matter how many Workers you have set up, as with consumption-based pricing, you only pay for actual execution time.
👉 Find the infrastructure setup that works best for your cases.
Zero setup: Run in Robocorp Hosted Cloud Workers
For many automations, just running in Robocorp Hosted Cloud Workers is by far the simplest, fastest, and cheapest option.
No setting up servers, nothing running all the time, and the only thing you need to maintain is your robot code and the Control Room process.
Robocorp Hosted Cloud Workers run in secure containers that are called up for the duration of the robot run and then deleted. Using the containers also means that scalability and parallel runs are there for you out of the box.
A good chunk of RPA automation is just background work like communicating with APIs, reading data from Excel files, etc., all of which can be done on simple Linux containers that are just faster than a Windows machine in a lot of things.
Also, just about all browser automations can run on these containers and you can even get screenshots from browser automations.
Even if your automation requires some dedicated machine or application, that does not mean that the whole process needs to run on that one machine.
Dedicated machines are much more costly to set up and maintain, so you should use those only for the parts they are absolutely needed for and let the containers handle the rest.
👉 Break down your process into steps and leverage the best worker setup for each step
👉 Use Work Data Management to pass the data along from step to step.
🚀 Scaling and parallel executions out-of-the-box, zero infra setup.
🚀 More details on Robocorp Containers
🚀 Certificate Course I gives you the best possible kick-off.
Windows desktop automation on the machines you decide
👉 This is the way to setup your production Workers for Windows automations.
OK, so you have an automation that requires the use of a Windows application, or the robot can only run on specific machines inside your company network with a specific user account, etc.
The self-hosted Windows Desktop setup is the correct choice here. The guide below is the most direct and fully featured way of executing your robot on-prem and with a full Windows Desktop in your hands.
This set up creates an Unattended Worker that wakess back up after server reboots without extra actions. You control the user accounts used and applications installed on the target machine. And you can also run multiple executors on a single Windows machine, by setting up more users.
Depending on the hardware and your robots this also enables running robot in parallel.
🚀 On-prem or where you want with full desktop interactions
🚀 Multiple executors on a single machine -> multiple robot running at the same time
🚀 Set up guide
Other options
We separate the other options like this mainly because the options above are by far the most common ones. Also, the options on this list are more directed to specific use cases, IT organizations, and developers testing things out.
The chapters below take you directly to the installation instructions and guides, but take notice of the descriptions to figure out if a specific option is for you.
Worker Groups, when you are scaling up
Maintaining singular Unattended Workers gets you started nicely. Still, when you start to scale up, need some redundancy for your executors, want to run in parallel and start managing multiple Workers, then Worker Groups are your friend.
Workforce Agent UI for testing
👉 "This is only a test."
Setting up the Robocorp Workforce Agent UI application on your machine enables you to test your robot runs from Control Room quickly and easily.
Run the installer and link the Agent to the correct organization and workspace in Control Room, and you can trigger robot execution from Control Room.
This enables you to test the robot in a setup that matches your production setup and removes the infamous: Works on my machine! to a high degree.
Q: Why for testing only?
A: Any application you start will shutdown when you log out of the machine or shut it down.
👉 Using the UI application to execute your production robots is NOT an ideal path to take.
🚀 Robocorp Workforce Agent application is available for Windows, macOS and Linux.
Running as background service
When your robots do not need to interact with the Windows desktop or you can run your robots on a Linux machine, running as a background service is the choice for you.
Again, you control where the machine (real or virtual) resides and what it has installed. So the use cases can require something specific to your needs from the target machine.
There are separate guides for Windows and Linux, and the Linux one is adaptable for macOS users as the Workforce Agent Core is available for all three platforms.
🚀 Setup Workforce Agent Core as a Service
Docker containers
You are taking a step deeper into Linux country via Docker containers. The link below guides the creation of a docker container to run Workforce Agent Core that provides an Unattended Worker to your Control Room.
The Robocorp Hosted Cloud Containers are built almost exactly like this, but Robocorp handles the orchestration, resourcing, security, updates, etc.
🚀 Setup container running Robocorp Workforce Agent
Self-hosted On-demand Workers
The 'ultimate' step in the self-hosted path, this option enables you to configure on-demand Workers of your own by leveraging Kubernetes or Azure Windows VM. This option is by far the most complex one to set up, but it can also yield significant benefits in infra costs and scaling.
Instead of setting up individual Self-Hosted Unattended Workers, in this option, you set up a way to spin up the Workers when they are needed. This is again similar to how Robocorp Hosted Cloud Workers work, but you are in control and can decide what the target machines have and what they can do.
🚀 Self-hosted On-demand Workers