At a high level I have been searching to find steps or documentation per setting up a passive deployer as a fail over for an active deployer. Using Tridion 2013 and Tomcat as a deployer, is there any documentation/manual or blogs regarding this (maybe I may have overlooked or not come upon yet), available?

2 Answers 2


The installation and setup of the deployer is exactly the same whether it is an active or a passive deployer which you can refer here Deployer Setup

The active/passive setup is done via the NLB. In the NLB you have to setup active/passive (failover) partners in terms of your deployers. So, only one deployer is active at a time while is the other one is a failover partner.

Also, in your publication targets you need to specify the NLB endpoint of the deployers so that the transaction will always go to the active deployer, like:


This setup will ensure that publish transactions are picked up by only the active deployer.

Also, if you do plan to use Tridion caching on content delivery, you will need to setup NLB for cache channel service as well on port 1099 so that your oData servers can listen in for publish events and cache clearing can happen on the same as well.


Be aware that the passive deployer must not become active until the previously active deployer has ceased all deployment (or you could get out-of-order deployment commits).

Ideally before making the passive deployer the active one the previously active deployer must be terminated (or disconnected from the network, or otherwise ensured to no longer commit deployments).

Edit: There are several ways of achieving this:

  1. make the failover action a manual action and explicitly verify the original active deployer is no longer performing deployments before making the switch
  2. use clustering instead of NLB failover and restrict access to the database to the cluster IP address (which only ever one node in the cluster will use at a given time)
  3. Extend the deployer and implement a database-level lock which only one of the deployers can hold. The lock must expire if the deployer loses its connection with the database server (most likely via a timeout mechanism). Deployments should be put "on hold" until the lock can be acquired.

The core of the problem is that NLB failover works fine for stateless applications but deployers are stateful and not explicitly designed with this kind of failover in mind. As such making a truly high available and reliable deployment solution requires much more work than just implementing NLB failover.

Of course you can always "take the risk" and hope for the best; depending on the quality requirements of your platform this is by far the simplest solution (apart from manual failover; if failover occurs very infrequently why automate it to begin with?).

  • The NLB configuration ensures that packages only go to the active deployer (which is an easy configuration on the NLB). So, as long as the NLB is setup to have only one node as "green", nothing else needs to be done like removing from network or terminating etc. for the deployer which just became passive because the NLB will route traffic only to the "green" node Commented Jun 3, 2015 at 21:04
  • The problem occurs when the NLB sees a node is no longer responding to requests but the node is actually still deploying in the background (just not picking up new deployments). You would break the commit order this way (a later publish transaction can commit earlier and be overwritten by an earlier publish transaction that commits later) Commented Jun 4, 2015 at 9:39
  • We have been using the configuration that I mentioned in my answer for over 3 years and not even once we had a scenario when the active deployer became passive and was still deploying. The scenario you are describing is rare (since failover is rare unless there are some real network glithces). Commented Jun 4, 2015 at 21:22
  • Given you are saying in your answer that it should be taken care of, can you please describe how? Since you haven't specified how to address/stop the passive deployer from continuing the current thread. Taking into consideration that the failover time on an NLB is in seconds/miliseconds, how to address it with any other program utility. It will really benefit the community if we know how to address this scenario Commented Jun 4, 2015 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.