Documentation for JIRA 6.4 (This documentation includes the project navigation sidebar). Not using this? See below:
(JIRA 6.4 without sidebar documentation | JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

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

    What a pain...

  2. Anonymous

    So you are seriously suggesting to have one TC instance per product? So either individual machines per product or all running on different ports? That doesn't feel like a customer friendly solution.

  3. Anonymous

    Memory problems are also common as one application may allocate all of the memory in the Tomcat JVM to itself, starving the other applications.

    Hmm, loading nearly the same libraries 3 times in 3 different servlet container instances (jira+confluence+crowd) are not supposed to be a memory problem? Doesn't the Jira team talk to Confluence team or why are you using different versions of the same libraries in each product?

  4. Anonymous

    Also not very happy with this.  It makes in-situ upgrade nigh-on impossible.  As a principle point-version upgrades should be capable of being done in situ, with major version upgrades requiring a new build... surely?  How about some scripted upgrade executables with a database script as well? Next time..

  5. Anonymous

    That's pretty crazy, having to run several JVMs and use non-standard ports for each of the Atlassian apps. I'm not sure why having different versions of third-party libs is a problem. They would normally live each within their own classloader, no?

  6. Anonymous

    is this restriction only for Tomcat? What about Glassfish? 

    1. Hello there,

      As indicated on our Supported Platforms page, the only application server that we support for running JIRA is Apache Tomcat. Unfortunately, we do not support Glassfish. To add to that, the documentation we continue to develop and maintain in this documentation space relates to platforms that JIRA supports.



  7. Anonymous

    Any update on this?  It seems like a very inefficient way to run a server if you need 2 or 3 things in the same place.  My understanding on tomcat is that it is an application container designed to run multiple applications at a time...

  8. Anonymous

    This sounds very strage too me.

    You offer a hosted service that includes all the products, right ? So internally you managed the "integrated" deployment.

  9. Anonymous

    How do I know if JIRA and Confluence are using the same Tomcat instance?

    And how can I change that to use separate Tomcat instances without damaging my installation??

    1. Hi there,

      Did you install the 'Standalone' distributions of JIRA and Confluence? If so, then both JIRA and Confluence will be using their own (separate) Tomcat instances. (As indicated on the Installing JIRA Installing JIRA Standalone page in the JIRA 4.4 documentation, the Standalone distribution of JIRA comes pre-packaged with its own Tomcat application server - as does the Confluence Standalone distribution.)

      This page relates to JIRA WAR distributions and their installation.

      An easy way to find out if JIRA and Confluence are using the same Tomcat instance, check the webapps directory within your Tomcat instance (that you suspect might be running both JIRA and Confluence). If you don't see both JIRA and Confluence directories in webapps (but only one of them), then that Tomcat instance is only running one of these apps.



      P.S. From JIRA 5.0, we are removing the term 'Standalone' from 'recommended' JIRA distributions that a pre-configured with their own Apache Tomcat app server.

  10. Anonymous

    Bye Bye Atlassian...


    1. Anonymous

      I am really disappointed. I am preparing a new production JIRA server right now, I didn't expect to have any problem running other applications used by the team (so far it would be non-Atlassian apps, such as Probe, Artifactory, out current bug tracking product JTrac,...) on the same TC instance  !!

      I'll try anyway and hopes it works... It would really suck, from the admin pov to have to manage multiple TC instances and from the user pov if you must have different ports for different apps !

  11. Anonymous

    Thanks for documenting this so clearly it makes decisions easier.   Do not understand this at all.  Also not understanding why only Tomcat is supported as the container.  Why can't I deploy this to my existing Java EE infrastructure.   Considering there are documents at Atlassian site about how to do it, I find it very strange.   Overall this leaves a very bad taste in my mouth and turns me off to the whole Atlassian stack. 

  12. Anonymous

    "Does not play well with other children" comes to mind – not even children in the same family. It's really ironic that a company ostensibly committed to collaboration tools builds tools that don't collaborate with each other. It's been nearly a year since the last comment on this question and there's been no forward progress. Failure to progress forward is in fact falling behind. VERY disappointing.

    1. Sadly, agreed - and the news that WAR distribution will no longer be available from v7.0 just looks like an admission of defeat to snowballing complexity...  Come on Atlassian, we're on your side, but please don't go this way :-/


  13. Since Tomcat is really just a Servlet container and not a full-blown Application Server, this is not really surprising. What is surprising though is that Atlassian doesn't support or recommend deployment to a full-blown Application Server, like JBoss (which btw uses free Confluence wiki for their docs, and JIRA for their issue tracking, due to them being Open Source). I wonder how JBoss themselves deploy their Atlassian products? The "recommended" way?

  14. Anonymous

    The UI of JIRA 5+ is amazing, I think the best of all, but this java behind the scenes is terrible. Why not rewrite the server-side code in node.js, PHP, or something that can make a better use of system resources?

  15. I really like Atlassian products, but honestly the stark advice to deploy a whole new container for each WebApp seems like an admission of failure to adhere to best practises in your own development.  Have the JVM and WAR Container standards let you down that badly?  Or, are there just glaring inconsistencies and poorly understood complexities in your code that need to be contained and hidden within the high-walled garden of a unique container instance?  Sorry to describe it that way, but you should know that's exactly how it looks.