Introducing Automation Cloud Robot - Serverless! Limitless robot power with zero infrastructure

Companies are moving to much larger scale deployments of automation products, and we encounter more and more cross-platform environments. We’ve also heard your requests to add support for automations triggered by certain events, such as an email arriving in the inbox, or a file added to SharePoint.

UiPath is now previewing a new type of robot that’s ideally suited to such scenarios: Automation Cloud Robot - Serverless!

Serverless Cloud Robots enable organizations to run large numbers of simple, cross-platform, triggered workflows, on behalf of individual automation users - all in the UiPath Automation Cloud. It’s a Linux-based SaaS robot that instantly runs multiple API or web-based jobs concurrently, with no configuration required.

The perfect companion to Studio Web

As part of our larger move to allow for more cross-platform automation, UiPath recently announced the release of Studio Web, a browser-based automation development tool, for users who wish to start automating processes across online applications and tools such as GSuite, Office 365, IT infrastructure platforms, and more.

Serverless Cloud Robots are a valuable companion to Studio Web, allowing you to take the automations built in the browser and run them instantly, with no additional installation or configurations.

To find out more about Studio Web and the types of automations you can build in the browser, check out the Studio Web release announcement.

What is on our near term roadmap

  • Web Browser UI Automation Support: Ability to use UI Automation activities with a Chromium based browser
  • Multiple robot sizes: The current preview only offers a single size of robot. We will be introducing multiple size robots which will be automatically selected by default based on the needs of your process with the ability to explicitly set if needed
  • Unit Based Licensing: We plan to introduce unit based licensing for Serverless Cloud Robots, which are consumed by the minute based on the size of the Robot used. For example, a 4GB Robot will consume twice as many units per minute as a 2GB Robot
  • Enterprise support: We will be opening up the Preview and then GA to Enterprises, including support, in all Enterprise regions. We are also previewing another type of Automation Cloud Robot - VM with enterprise customers. VM Cloud Robots are designed to take almost any existing unattended workload to the Automation Cloud and are configurable for enterprise needs.

Want to learn more?

If you have any questions about how Serverless Cloud Robots work, or want to find out more details, you can always refer to our documentation. You can see how to enable unattended robots on your account, and how to add a Serverless Cloud Robot to your tenant.

We value your feedback

Please share with us your first experience with Serverless Cloud Robots and what they have empowered you to run. Our product team appreciates your feedback and will consider it in future product releases.


This is amazing !!!


This sounds cool !



I’ve downloaded this but can’t find an unattended robot to run processes?


Is there something I’m missing?

Did you follow the steps in the documentation? You need to create the Machine template in Orchestrator, then add the template to the Folders from which you want to run the process.

That error message looks like there is no machine template in the folder.

1 Like


Based on my 10 minute read, I’m wondering why they are called Serverless Robots? :thinking:

Almost all configuration of these Robots happen in the Orchestrator (Server) based on the steps in the documentation. And most of these steps are similar to configuring Robot accounts. But I am to understand that the capabilities of Serverless Robots is different from Robot Accounts?
Regardless, there is server dependency for these Robots to run.

If customers do not have to worry about necessary infrastructure, then does it mean that when the they purchase licenses, Serverless Robot machine templates will be auto-provisioned for them in their Tenants when their folders are created? In which case customers really don’t have to worry about necessary infrastructure.

I’m thinking SaaS robots would be a more fitting terminology then?

Sorry, if I’m off track here.



Hi Andy,

The configuration for Serverless Robots happens in Orchestrator as you mentioned - you will still need to create a machine template and assign it the folder, similar to the setup that’s required for Unattended robots & robot accounts. They won’t be auto-provisioned when you when your folders are created, as you may not want certain jobs/folders to use Serverless robots and it provides flexibility for where/how you want them to be used.

To differentiate between Serverless Robots and Robot Accounts:

Robot accounts are helpful for when you need to run back-office unattended processes that should not be the responsibility of any particular user, but they don’t deliver a infrastructure to run your jobs on. This is something that you would be responsible for, such as provisioning & bringing a virtual machine for the Robot account to run on.

The Serverless robots require no configuration from the user in terms of setting up the infrastructure, like provisioning machines or servers to actually run the jobs on. This is what we mean by “serverless.” Serverless robots bring you always available compute, high scale, and concurrency without actually having to do the machine setup/provisioning yourself. UiPath handles all the work behind the scenes so you don’t have to deal with containers, virtual machines, or physical servers.

Hope this helps!




Valuable feature :star_struck:
Great job UiPath :clap:

1 Like


These are exciting news. Love the focus on the aaS approach!

I’m especially interested in workflow triggers. You write:

However you don’t specify anything about this functionality and I can’t see it on the near term roadmap. Do I understand correctly that you would still need continuous monitoring of an inbox to timely react to new mails?

What is the advantage of running a Robot 24/7 to monitor my inbox compared to your competitors products which can actually trigger actions based on events without extra runtime costs?


No. Check out the Integration Service :slight_smile:. You can already set a bunch of triggers that will trigger your published processes.

In the meantine, our teams are working on bringing more integrations as well as streamlining the trigger experience (so that you can configure them directly as part of design rather than after publishing).


Thank you for the answer and my apologies :wink:

With Integration Service we can trigger jobs on events like a new incoming mail. With a lot of mails that would mean a lot of jobs (and runtime). Is there a way for an integration to create a QueueItem instead of triggering a new job?

Otherwise we would trigger one job for each incoming mail and that doesn’t seem very efficient.


For the moment the triggering capabilities are 1 event → 1 job. We are considering triggers that queue items instead of starting jobs in the future.


How are you folks handling authentication to on-premises or ‘protected’ resources (SharePoint Online, for example)? I notice you cannot configure any domain-joined accounts as the unattended runner for serverless execution…should these use cases be excluded from consideration of this deployment method?

1 Like

Hi @Greg1,

We are currently looking into supporting access to on-premise resources for Serverless Cloud Robots.

If you wanted to safely authenticate to resources like SharePoint Online, Microsoft Outlook 365, Google Drive, Box, etc., you can leverage our Integration Service Connectors in your cross-platform automations which can be run on Serverless Robots. We specifically have one for Microsoft OneDrive & SharePoint Authentication. Let me know if you have any further questions!



1 Like

Hi @Magdalena_Neagu , Thanks for this really cool feature. It was much awaited. I tried this and I am able to use it.

However, as this is serverless with the dynamic VM allocation, how do we handle processes wherein we used to keep our configurations in the config file or say my process needs to read data from an excel file. Traditionally, such files have been on the VM that was set up as the machine template. How do we deal with this in the new scenario as my cloud VM isn’t fixed anymore?

Thanks Lisa for the summary. We are conducting a small PoC. Will appreciate if you could share pointers on licenses for the same.


1 Like

Need to also know what all features of orchestrator we are going to get with the existing license for SAAS on cloud. Adding to what you have mentioned @preeti.thukaram1 .

Theres any hope that integration service will start to work with unnatended bots?