Find the Worker setup for you
Workers execute the robot tasks on remote machines and are assigned steps in unattended processes. They can be managed in the Control Room from the Worker -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 Worker, you won't need to worry about setting up or hosting any infrastructure by yourself.
Find the correct setup for you
When running unattended robots, we provide a host of different options to set up the infrastructure for your automations.
So, where should you start? This article is here to help you out, and the image below will give you the big picture.
Remember, you are NOT bound machine or user-specific licenses.
It does not matter how many Workers you have set up; 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, running in Robocorp-Hosted Cloud Workers is 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 the whole process must run on that 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-Hosted Cloud Worker
🚀 Certificate Course I gives you the best possible kick-off.
Windows desktop automation on the machines you decide
👉 This is how to set up your production Workers for Windows automations.
OK, so you have an automation that requires 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 setup creates an Unattended Worker that wakes up after the 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 robots 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 ones above are the most common. 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 shut down 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. The use cases can require something specific to your needs from the target machine.
This guide for Linux is adaptable for macOS users as the Workforce Agent Core is available for both platforms.
🚀 Setup Workforce Agent Core as a Service
Workers inside Docker containers
You are taking a step deeper into Linux country via Docker containers.
This is the ideal solution when you want to host locally and be able to manage one or multiple workers on your machine, but not deal with the whole technical part of setting up everything.
This allows for a better cost control depending on your personal needs, without the need of strong knowledge around Kubernetes.
The link below guides the creation of a docker container that provides one or more Unattended Workers to your Control Room.
🚀 Robocorp Workers inside Docker containers
Self-hosted On-demand Workers
The 'ultimate' setup 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 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