Single vs Multiple Orchestrators

Help
1

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

:slight_smile:

2

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:

Thanks
JC

2 Likes
3

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

4

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 Managing roles

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.

5

I would agree that there is no reason that you could not only have 1 single instance of Orchestrator as you have proposed, but it may come down to Licensing.
Orchestrator, based on whether Production or non-Production, would have different License Types allocated to them…again PROD vs Non-Prod, so that may be one reason to allocate or have 2 Orchestrator instances versus only one.