Documentation for Crowd 2.9. Documentation for earlier versions of Crowd is available too.

Skip to end of metadata
Go to start of metadata
Deploying multiple Atlassian applications in a single Tomcat container is not supported. We do not test this configuration and upgrading any of the applications (even for point releases) is likely to break it. There are also a number of known issues with this configuration:
  • You may not be able to start up all of the applications in the container, due to class conflicts (in 3rd party libraries bundled with our application) that result from the Atlassian applications sharing a single JVM in the Tomcat container.
  • You will not be able to determine the startup order of the applications. Hence, you may experience problems such as JIRA starting before Crowd, rather than vice versa.
  • Memory problems are also common as one application may allocate all of the memory in the Tomcat JVM to itself, starving the other applications.

We also do not support deploying multiple Atlassian applications to a single Tomcat container for a number of practical reasons. Firstly, you must shut down Tomcat to upgrade any application and secondly, if one application crashes, the other applications running in that Tomcat container will be inaccessible.

Finally, we recommend not deploying any other applications to the same Tomcat container that runs the Atlassian application, especially if these other applications have large memory requirements or require additional libraries in Tomcat's lib subdirectory.

  • No labels


  1. Anonymous

    I'm really surprised that there are no comments here.  

    The problem with having a different Tomcat container for every application is that the extra memory that is wasted in each heap accumulates to a substantial amount.  Like water, there's never enough memory to waste.

    And I can't log in to this site, apparently my user account is no longer in existence.

    Sadly, I am losing faith in Atlassian software.  The applications are getting harder and harder to deploy and keep running, and the innovation seems to be focused in areas that make increasingly less difference to users like myself.  

    I know it's hard to go through and fix your apps so they do the right things with classloaders, but it's gotta be done.

    1. Hi,

      I understand the memory issue. It certainly doesn't help that a lot of our apps are rather greedy in that respect.

      Unfortunately, the multiple apps in one JVM configuration has proven extremely difficult to support. Because a lot of our customers are running older versions of our software, the matrix we need to test becomes the dot product of the number of JIRA releases in the last 2 years by the number of Confluence releases in the last two years by the number of Crowd releases.... etc. We simply don't have the ability to test and verify that all of these work together correctly and to fix them when they don't.

      Which means that while we say the configuration is supported, the person that finds the problems is you rather than us. Which we believe sucks more than the extra memory usage of running separate Tomcats.

      Does this make sense?

      Integration Product Manager.

      ps: We reset a bunch of user passwords last April; click on 'Forgot your password?' and get a new one sent to you.

      1. Anonymous

        Thanks for your response, Dave.  I was the author of the original post, and for various reasons (mostly the risk of my frustration creating long term repercussions), I chose to post anonymously.  Now I cannot get logged in, no matter how often I change my password or how long I wait between attempts.  I truly do hope to help your teams find the best solution here.

        The thing that is hardest about the memory situation is that any container is going to run best with a relatively large amount of free space for surprise loads. Which isn't a problem, except if I have to duplicate that much memory four times.  I think you can appreciate... :-)

        When I think back several years, my perception about being able to run Jira inside any container was means to get an instance of Jira deployed "under the radar".  While this no longer seems to be necessary with Atlassian's success, I could secretly deploy an instance in an existing container (like a copy of WebLogic that happens to be on an idle machine) to "get it in the door".  
        That was great when it was just Jira, but now there are four apps in the stack, and it's become non-negotiable that these apps can't run in the same container.  No matter how it's sliced, deploying the Atlassian stack now requires the ability to deploy containers on hardware.  So why support the WAR distro at all?Since corporate IT department deployers look to vendors to suggest best practice, by bringing the container in-house, Atlassian could make an "Atlassian container base" (aka OSGi runtime), and contribution archives that added the proper functionality for each suite. Everything runs together in the same container, overcoming the memory issues, but more importantly (as an OSGi container), modules could be upgraded and version conflicts avoided.  Even better, upgrades with cross-suite functionality could bring in backwards compatible versions of new libraries, without completely upgrading the peer suite.  Everyone wins.WDYT?

      2. Anonymous

        For the most part the Atlassian suite is awesome, but like the person above this greatly irritates me.  You mention that part of the problem is that you are required to support 2 years worth of versions for each product.  Perhaps if it wasn't so frustratingly difficult to upgrade to the latest versions, this wouldn't be necessary?

  2. Dave,

    It's very easy to understand the impossibility of supporting every combination of your apps in the same container. However, you might find that customers are not bothered by this limitation if you address the reasons they would want to set up such a configuration.

    For example, I have only one server, with one static IP address, and I wish to host bamboo, jira and confluence, all on port 80. The only way I know of to do this is to throw them all in one tomcat container, and use tomcat's virtual hosting capability with DNS CNAME aliases. Luckily, I'm using the most recent versions of the three applications, and there is no sign of incompatibility.

    In my case, if there is some other way to achieve the same result without sacrificing my ability to get support, I would be less cautious about deeply integrating your products in to my workflow.

    1. Anonymous

      Hi Michael,

      The best way to do this is to run Apache on port 80, forwarding the /jira context path to JIRA on Tomcat 8080, /confluence to Conf on Tomcat 8081, etc.

      That configuration is totally supported, and is how we deploy our apps for JIRA Studio.

      Does that work for you?



      1. Anonymous

        This sounds like what we need to do. Is there a document that describes how to do these forwardings:

        "The best way to do this is to run Apache on port 80, forwarding the /jira context path to JIRA on Tomcat 8080, /confluence to Conf on Tomcat 8081, etc."

  3. Anonymous

    I have  been running Crowd 2, Confluence 3 and Jira 4 successfully in this configuration for a year now with about 15 users on a virtual machine. So far there hasn't been any issues. Some libraries need to be scoped to individual apps because they conflict from time to time but once set up this is pretty easy to manage.

  4. Anonymous

    "The best way to do this is to run Apache on port 80, forwarding the /jira context path to JIRA on Tomcat 8080, /confluence to Conf on Tomcat 8081, etc."

    Is this referring to having a single Tomcat instance? 

    Perhaps someone on Atlassian staff could post an example Tomcat setup for this

    (and indicate it is 'unsupported' of course).  I'm not familiar enough with Tomcat to know how

    to scope libraries (or which might need it).




    (my login didn't work for some reason)

  5. I always thought the "correct" way of deploying Java applications was in a single container (read JBoss, Glassfish, Tomcat etc)

    It's always been a surprise that atlassian WAR distrubutions don't play nice between themselves. If versioning is a problem, you can always state that deployment in a single container only works within one release. I am using all 7 starter products, I'm lucky to have a dedicated server for the atlassian products, and I'm running out of memory.

    Anyways, a small tutorial for the aformentioned apache configuration would be useful.

  6. Anonymous

    I agree it's silly Atlassian doesn't support a single container. I'm sure if this required version compatibility restrictions that would be fine with most people (who want the latest versions running anyway).

    Anyway, we run multiple Atlassian webapps behind a single Apache instance like this:

    RedirectMatch ^/wiki$ /wiki/
    ProxyPass /wiki/ ajp://
    ProxyPassReverse /wiki/ ajp://
    RedirectMatch ^/jira$ /jira/
    ProxyPass /jira/ ajp://
    ProxyPassReverse /jira/ ajp://

    where tomcat has the webapps published to /wiki, /jira, etc. You need to enable mod_proxy and mod_proxy_ajp.

    You might also need this:

      # Work around this issue:
      <Proxy *>
          RequestHeader unset Authorization
  7. Anonymous

    It's downright crazy that I need to run all these tools under separate services!

    They produce all these nice tools for integration, but can't do their own integration?

    1. Anonymous

      I'm guessing it's because they want to sell more Studio licenses... ;)

      But I agree that the tools could have better integration for others.

  8. Anonymous

    Hello everyone,

    First of all this was totally an interesting discussion.

    We also use Apache reverse proxy to shorten the URL, etc. You have to remember URL suffix rather than the port number. Cool.

    We were evaluating Atlassian products to build an ALM solution. After this discussion it's  hard to believe for me that Atlassian wants to play in the ALM league.

    Isolated silos  of applications which are masterpieces by themselves, but do not play all together.

    Yes, I know there is the hosting service for those, which does not suit me for we look for an on-site solution.

    I wish I could install them all at once with full integration on a single machine.

    Do you have any plans to be more ALM and less "isolated silos"?

    Thank you