Advantages of creating and running multiple instances of integration server?

Hello Experts,

I would like to understand real time usages and advantages of creating multiple instances of integration server. Please help me with example use cases.

I typically see these in a Development, Sandbox, PoC and throwaway-type setups - manually created our automated.
There are more that I’ve seen, but none come to mind right now.

Update - I assumed you meant multiple instances (via the instance script) on the same machine.


There are few reasons why running more than one instance can be useful.
1-For high availability. Let’s say you want to perform maintenance on your integration server instance. Having another one running can allow you to do it without interruption of the service. There are few ways to configure IS depending on your requirements.
2-You may want to have your services segregated by business domain.
3-You should have different instances for different staging environments (dev, lab, prod, test, etc)

Hope this helps.


Hi @Warrior_S ,
An addendum to the previous answers which refer to multiple instances in same machine and instances on different environments,

Integration server also supports creation of multiple instances in the same installation directory. Refer Overview of Integration Server Instances and About Integration Server Instances for more details about instances in the same installation.

Based on the context , instances can be interpreted in different ways, please more details about your usecase/ what you are looking for , for more pointed answers.


1 Like

Hi all,

Thank you for responding.

Which one is good for high availability ?
1)Having multiple instances on the same machine.
2) Clustering with different machine installations.

Is this (multiple instances) an alternative to have all the environments (dev, test, prod) in single installation?

I am just trying to understand is this nice to have feature or must to use option for a particular scenario (looking for a real-time use case if anyone implemented).

Thanks in advance.

HA in a live environment must always be spread across DIFFERENT machines (i.e., nodes), else you introduce higher points of failure in your landscape. You can improve HA further by spreading those nodes across different (read independent) hardware kits and different data centers.

Note that clustering and HA are 2 different concepts/requirements, so you can have HA without clustering the nodes, unless your business case explicitly requires clustering (shared session states, shared caches, etc.). Read up online about stateful vs stateless clusters.

Multiple instances is only for a few cases that I’ve mentioned above - you must not use these in Test or Production environments.


1 Like


please check the wM Clustering Guide which is available in the documentation section of either Empower or TechCommunity.

Remember that all instances created in one single installation directory need to be updated together otherwise some of them will fail with incompatible shared libs.

Clustering conecpets are dependend on where they are implemented, at OS level or at wM level.

Having Dev, QA and Prod on one box in different instances is not allowed in most cases as the networks should be separated between those envs to avoid having real data in instances where they do not belong to.


1 Like

You may find information at IS Clustering to be avoided to be useful. It is a very old thread but the guiding principles still apply.



additional point to keep in mind:
Regarding SSL/TLS certificates for the IS instances:
Do you need to distinguish the instances by the DN of the certificates while having the same CN for all of them (due to URL being checked against CN during validation for host matching)?
If yes, in which field of the DN do you store these informations as the field OU (which we have used in the past for this) is now deprecated by most of the CAs and should not be used any longer?

This issue was brought to my knowledge today while trying to extend existing certificates for another year.