Suggest Recommended Approach for Dev,Test and Prod environment within same orchestrator instance

I have an orchestrator enterprise license for our Production environment. Now I can separate my Dev, Test environment within the same Orchestrator instance. I have three approaches to achieve this. Please suggest me a right and recommended approach @Lahiru.Fernando @Palaniyappan.

Approach 1: I will create different tenants for the Development and Test environment. So I can separate my robots, queue, and assets value with the different tenants.

Approach 2: I can simply do this within the same orchestrator instance by creating separate environments. So what I can do, first create separate environments for development, test, and prod. I can connect my development machines with the development environment robots so that I can only work on the development environment.

Approach 3 : Can I deploy separate Orchestrator instance for Development, Test, and Production environment.

Suggest me the best approach from the above mentioned approaches to achieve this task @Lahiru.Fernando @Palaniyappan

1 Like

Either first or last approach would be fine buddy
Why not with second one is though you have created different environment for different instance it would tough to manage each instance at a time

It is always easy to manage the data of different instances been isolated.

Cheers @Umang_Mehta

Hello @Umang_Mehta

Sorry for my late reply on this. I was stuck with a bunch of meetings today.
So for this, I would agree with my friend @Palaniyappan on the first or the third option.

Approach 1: This is good. Having different tenants can manage the development, test and production instances separately so that things don’t get confused etc.
However, the ideal approach I would suggest is to have a separate orchestrator instance for the three environments prod, test and Dev.

Why I say that is, having tenants created in the same instance will actually refer to the same SQL Database of the Orchestrator. Usually, development environment is where we try out all kind of stuff, and it is quite messy with unwanted and wanted things. So having such stuff in the same database, that I would not recommend even though they are in different tenants.

1st option is good, considering the budget and other external factors… However, ideal approach to have would be the third one. In this, every orchestrator instance is installed separately and does not depend on one another. Here, we can try out all crazy things in dev and leave the production and test untouched unless when are doing a actual deployment…


It would be important for you to tell which version you will be using…

My company has done Approach 3, and there’s good reason behind it.

Approach 1, would allow you to do what you’re stating, but, if you are going to update your Orchestrator version, you have to do that in production without first checking to see whether that adversely affects any of your processes, which may or may not be okay depending on your situation.

Approach 2, This is probably the worst of the three, especially considering you want separate assets to all have the same name since the ReFramework has the developer state specifically what they will be in all cases.

Approach 3, This allows for the testing of different environments in a self contained way. Any updates to the Orchestrator environment can happen in a safe way in development, QA, and then finally pushed into production without adversely affecting production jobs. This is especially important if you have batch jobs that end users are depending on happening and even a day or two delay would be untenable.

I can use latest 2019.10.14 (LTS) version of orchestrator.

Then you have one more approach, that is simpler and can suit your needs well, would be using folders to separate resources for different environments:

1 Like

@Palaniyappan @Lahiru.Fernando @dmccammond If I can use the first approach then I need to buy licenses for each tenant ,Right?


Of course yes buddy
Like when we create a tenant it is unlicensed until you add a license file. The same applies with the default tenant. If you don’t add a license file on it, it will remain unlicensed. Each license file that you add to your tenants has a number of Robots that you bought, So for that we need to pay for the numbers we buy

But is of less cost when compared to the third approach though is the one everyone prefers because of its data integrity.

If we are ready to afford the third approach of buying different orchestrator license for each instance then it’s the best

Cheers @Umang_Mehta

1 Like

If i have single Enterprise license key then I can use same license key for activating different tenant in same orchestrator ?

1 Like


Yes it’s possible buddy
Like in both ways
Either with one license for each tenant
One license for multiple tenant

For more details

Cheers @Umang_Mehta

@Umang_Mehta - I was wondering if you could please share , how did you finally setup the environments? Can you please share?

HI @Tech_Geek

Welcome to the community… May i know what is your question in detail please? Would be glad to help

I’ve seen my peers use test sets, i.e., TestsQA, TestsStage, etc… and it looks to be working for them. Any feedback is appreciated.


approach 4: single Tenant (Default). separate domain by using Modern Folder such as Testing. then we assigned a non-production Robot to this folder. for Developers, they can use their personal workspace folder and we use Orchestrator manager to migrate resources to other folders or u can use links manage links.