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 various options to set up the infrastructure for your task packages.

So, where should you start? This article is here to help you; 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 scalability and parallel runs are out of the box for you.

A good chunk of 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 many things.

Also, almost all browser automation tasks can run on containers; you can even get screenshots from automating web elements.

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 Windows Workers meant for automating tasks in production environments.

OK, you have a automation task for a Windows application, or the automation task can only run on specific machines inside your company network with a specific user account, etc.

The self-hosted Windows Worker setup is the correct choice here. The guide below is the most direct and fully featured way of executing your task packages on-prem and with a full Windows Desktop in your hands.

This setup creates an Unattended Worker that wakes up without extra actions after the server reboots. You control the user accounts used and applications installed on the target machine. And you can also run multiple task packages on a single Windows machine in parallel by setting up more users and corresponding Windows Workers.

🚀 On-prem or where you want with full desktop interactions
🚀 Multiple executors on a single machine -> multiple robot running at the same time
🚀 You can use Robocorp Setup Utility to set up your Windows Workers with a UI guiding you.
🚀 Detailed Set up guide that also has guidance on using CLI tooling for IT & fleet management cases.

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 note 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.

🚀 Using Worker Groups

Demo Worker for testing

👉 "This is only a test."

You can use Robocorp Setup Utility to set up a Demo Worker.

Demo Worker shows up in the Control Room just like Windows Workers, and you assign work to it normally. The big difference is that Demo Worker requires a human user to open the machine's desktop connection and ensure Setup Utility is running the Demo Worker. In short, this means this setup will not come back up if the server gets rebooted, the user signs out, etc.

Demo Worker enables you to test the robot in a setup that matches your production setup and removes the infamous Works on my machine!

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 Demo Worker to execute your production robots is NOT an ideal path.

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 in a Linux VM and be able to manage one or multiple workers on the machine.

The solution allows for better cost control depending on your personal needs without needing strong knowledge of things like Kubernetes, etc...

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' set up 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