Find the correct setup for you

Find the correct setup for you

When running unattended robots, we provide a whole host of different options to set up the execution environments.

So, where should you get started? This article is here to help you out.

The image below shows the big picture to give you the map, but the recommended options are also listed below to guide you.

Execution options map

Remember, you are NOT bound machine or user-specific licenses.
It does not matter how many execution environments 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 containers

For many automations, just running in containers 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 Containers 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 execution environment 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 environments 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 execution environment that comes 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.

Environment Groups, when you are scaling up

Maintaining singular execution environments gets you started nicely. Still, when you start to scale up, need some redundancy for your executors, and start managing multiple execution environments, then Environment Groups are your friend.

๐Ÿš€ Using Environment Groups

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 execution environment 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 setups

The 'ultimate' step in the self-hosted path, this option enables you to configure an on-demand setup 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 execution environments, in this option, you set up a way to spin up the environments when they are needed. This is again similar to how Robocorp Hosted Cloud Containers work, but you are in control and can decide what the target machines have and what they can do.

๐Ÿš€ Self-hosted On-demand Runtime Environments

November 22, 2022