Single vs Multiple Orchestrators

Hi, I just started working with UiPath, and I have come with this question because a situation that just presented at the company I work at. We have third party providers doing some development with UiPath, which they will hand over to us (the company I work for, we are the clients) for maintenance and further development.

These providers setup 2 orchestrator instances, of which they use one for dev/test, and the other one for prod. This looks a little unnecessary to me, since, in my opinion, one orchestrator can perfectly handle all 3 environments (dev, test, prod). So my question is, is there any reason (Like a best practice or a technical motive) to have a multiple a orchestrator setup? Hope you can help me out with this. Thanks in advance


Hello @alberto.velasquez Great question, i hope i can provide a satisfactory answer.

As per my understanding, having separate environments is mainly to ensure only certain people have access to the production environment. This avoids the alteration of assets or queues in the production environment which would ultimately affect how the process/robot is running. Therefore you tend to find more experienced dev’s and SA;s have access to the production environment.

Also, lets say the bot is in production but a change is requested to be made, better make sure that change works in the test environment before pushing it to live :slight_smile:



Hi @Jamcol. Thanks for your fast response.

Regarding changes in the right environment. Isn’t that why you can have multiple environments and permissions per user in Orchestrator? To make sure that your users only have access to what they need in order to do their task (Call it development, testing or deployment to prod)? I still don’t see the point of having multiple orchestrator instances (running in separate servers), when you can create all the needed environments in one and restrict the access to them per role and user.

Hope I don’t sound too insisting, it’s just that I see orchestrator just as a scheduler, not as a platform (Like a DB for example, that requires different amount of resources, isolation among environments, etc.).

Hello again,

You raise a good point here. I believe you are correct in your reasoning regarding user roles. This documentation will provide further insight to this

However, these roles are relatively limited in terms of splitting the permissions and access and i imagine it is significantly more secure with the separation between orchestrator.