What does “Machine” mean in UiPath?

ByTerry Marr

When learning UiPath, the word “machine” comes up often, and is thrown around a lot. It comes up in various scenarios and forms. Here are a few:

  • machine
  • physical machine
  • machine template
  • virtual machine
  • host machine
  • state machine

Phew! All these terms can be quite confusing to a beginner. Let’s break them down and learn how to think about what they mean.

Physical Machine

Let’s start at the most intuitive level, the actual machine.

This is what we naturally picture when we hear the word “machine”. This is a physical workstation, like the one sitting on our desk at home, at work, or on our lap. It has a screen and a keyboard, and a motherboard inside of it which has a bunch of chips stuck onto it and has special chip called a CPU, which we know does the thinking for the machine. OK. That’s easy.

Now, since a computer’s core is the motherboard, that’s all that’s really needed to have a physical machine. It’s the brain, which runs software after all. So, in large companies, there’s usually a room of just motherboards and circuit boards, all wired together. Like so:

Typical server room at a large company

When you hear the word “cloud”, imagine rooms and rooms like these, located all over the world, constantly running software and processing requests. People make a lot of money configuring, managing, and troubleshooting these monsters. But I digress. For our purposes, when you hear “physical machine”, picture something like this:

The motherboard

This is the only actual machine there is. Everything else is just software. Unfortunately programmers have chosen to call software objects “machines” too, just to confuse us, as we’ll see.

Actually, even this motherboard is completely useless until it has an operating system (OS) loaded onto it. Without an OS, it’s just a doorstop. It’s the operating system that actually runs the programs. So:

Motherboard + OS = “Physical Machine”

Host Machine and Virtual Machine

But we’re not there yet. UiPath was designed to run on a Windows operating system. So not just any OS will run UiPath, at least not now in 20241. The physical machine needs to have Windows installed on it, either as the primary operating system or as a virtual machine. A virtual machine (VM) is a way to install one OS on top of a different OS (such as UNIX, IOS, or something else). It essentially creates a separate carve-out that acts in every way as a new machine.

Once a physical machine has Windows on it, either primary or virtual, then the UiPath Robot Service, a software package, can be installed on it. Ok, now we’re getting somewhere. This is the requirement to be considered a host machine in UiPath.

Motherboard + Windows + Robot Service Software = “Host Machine“

But what is it hosting? It will “host”, or run, an automation that is sent to it from Orchestrator. For more on what exactly the UiPath Robot Service does see here.

Machine and Machine Template

Now that we have a host set up, we can set it up to run unattended automations. Unattended automations are what UiPath calls “robots”. These will be triggered not by the individual user of the machine but online. UiPath calls its online command center, where all automations are set up, managed and triggered, Orchestrator. In Orchestrator, first we set up a machine template at the tenant level under the machines tab.

Why not just add one machine? What the heck is a machine template? Imagine you’re a system administrator for a large company. There are perhaps hundreds of physical machines all over the building. You are responsible for setting them all up identically, with the same OS, and connected to the company’s servers. The only thing that will really change is the name of the user who will work on that machine. So they’ve come up with a way to load up a machine with an “image” or “clone” of the setup. This saves an immense amount of time, and ensures they all have the same version of the software for security and compatibility, etc.

So you, as the system administrator, set up a machine template in Orchestrator. This basically instantiates a software object, which UiPath confusingly calls a “machine” or “machine object“, you give it a descriptive name like “WINDOWS MACHINE TEMPLATE” and then, most importantly, a unique ID is generated for the template. This unique ID, (called a machine key or client ID) is the authorization key that the Robot Service (back down on the actual machine) will use to open a channel of communication to Orchestrator. Once a machine template is instantiated, it can begin listening for any Robot Service on any machine that logs in using that ID.

So when you think of “machine” in Orchestrator, think “channel listener”. Orchestrator “listens” on that channel for any communication coming in from the host machines. It can tell when a particular host (or more precisely the Robot Service on that host machine) is alive, non-responsive, or busy. When Orchestrator has an automation to run, it finds an alive, available Robot Service on that channel, and sends down the automation to be run (ie hosted) there. For more on how Robot Service communicates with Orchestrator, see here.

But how do the host machines know that secret key? With the Robot Service installed on each machine, the administrator adds in the secret key through either the UiPath Assistant, or the command-line interface (CLI). Once the Robot Service learns that key, it remembers it to communicate up to Orchestrator. If the key changes or is regenerated, it must re-learn the new one.

So what is a State Machine?

Switching gears completely, UiPath confusingly calls something else a machine — a “state machine”. A state machine in UiPath refers to a type of control flow that developers use to organize their code. For example, say you have an automation that listens for incoming emails, then sends a reply email based on the content. There could be a state called “waiting for Email”, and another called “reading email”, then “sending reply”, after which it would return to the “waiting for Email’ state. Often used for transactional processing, the REFramework template is built on this concept of “state machines”.

So many machines, so little time

So we’ve learned the differences between various uses of the word “machine” in UiPath. We know that a physical machine needs Windows and the UiPath Robot Service installed on it to become a host machine. Along the way we learned the difference between having Windows installed directly, or through a virtual machine. We’ve learned that the words machine and machine template in Orchestrator actually aren’t machines at all, but rather refer to a piece of software up in Orchestrator that listens on a specific channel to all the Robot Services on Host Machines that are broadcasting a particular secret key, and can therefore be used to host unattended automations. We’ve also touched upon the coding term state machine, which is simply a way to organize code into different states, and to easily repeat states when necessary.

Next: User Mode vs. Service Mode

  1. Other operating systems can run cross-platform automations, which are a limited set of activities that don’t interact with the operating system itself, but mostly do background processing. These can be seen as special “cross-platform, background” hosts in Orchestrator. Perhaps one day UiPath will expand what can be performed on other operating systems. But that is a topic for another post. ↩︎