JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

Deploying Multiple Atlassian Applications in a Single Tomcat Container

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.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

19 Archived comments

  1. User avatar


    What a pain...

    11 Oct 2010
  2. User avatar


    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.

    13 Oct 2010
  3. User avatar


    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?

    06 Nov 2010
  4. User avatar


    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..

    17 Nov 2010
  5. User avatar


    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?

    07 Dec 2010
  6. User avatar


    is this restriction only for Tomcat? What about Glassfish? 

    24 Dec 2010
    1. User avatar

      Giles Gaskell

      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.



      19 Oct 2011
  7. User avatar


    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...

    24 Feb 2011
  8. User avatar


    This sounds very strage too me.

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

    28 Sep 2011
  9. User avatar


    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??

    18 Oct 2011
    1. User avatar

      Giles Gaskell

      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.

      19 Oct 2011
  10. User avatar


    Bye Bye Atlassian...


    26 Jun 2012
    1. User avatar


      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 !

      24 Jul 2012
  11. User avatar


    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. 

    06 Sep 2012
  12. User avatar


    "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.

    07 Jul 2013
    1. User avatar

      Christopher Hatton

      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 :-/


      15 Sep 2014
  13. User avatar

    Jason Smart

    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?

    23 Nov 2013
  14. User avatar


    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?

    29 Jan 2014
  15. User avatar

    Christopher Hatton

    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.


    15 Sep 2014
Powered by Confluence and Scroll Viewport