Installing Confluence and JIRA Together

This page describes Atlassian's recommendation for installing JIRA and Confluence on the same server. Refer to Here Be Dragons for instructions on integrating all Atlassian applications.

(warning) Do not deploy 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 (see this FAQ for more information).

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 Confluence, especially if these other applications have large memory requirements or require additional libraries in Tomcat's lib subdirectory.

Recommended Setup - Separate Stand-Alone Installations

Atlassian recommends running JIRA and Confluence in separate stand-alone instances running behind an Apache Web Server. See the guides for:

Advantages
  • Each application can be restarted without affecting the other.
  • If one webapp hangs for any reason (eg. running out of memory), it doesn't affect the other.
  • Any problems can be debugged more easily. Logs are separate and product-specific, rather than everything going to catalina.out. Thread and heap dumps are smaller and more relevant.
  • It reduces the likelihood of jar conflicts (eg. jars that must be installed in common/lib or lib for Confluence running off Apache Tomcat version 6 or above), particularly if you later want to install a third webapp not from Atlassian.
  • Apache HTTP Web Server is well suited for running publicly available sites, with extensive modules for security and efficiency. It also allows for flexibility with URLs (ie http://confluence.atlassian.comhttp://confluence, and so on).

Apache Web Server is recommended and reliable. It is also a third-party product, and therefore not developed nor supported by Atlassian. See Atlassian Support Offerings for details.

Was this helpful?

Thanks for your feedback!

35 Archived comments

  1. User avatar

    Roger Smith

    "Do not deploy multiple Atlassian applications in a single Tomcat container"

    Someone needs to better define the term "single tomcat container". I have ran a lot of webservers and created a lot of web pages but like lots of folks I am not that familiar with Tomcat. Just what does it mean to run multiple applications in a single tomcat container. I am currently running JIRA on 8084 using control port 8004 and Confluence on 8080 using control port 8001 and it seems to work. So what am I missing and what should I look out for.

    26 Feb 2011
    1. User avatar

      Anonymous

      You've done what they recommend. 

      A tomcat container is the same as an asp.net application pool. I don't know if tomcat can be configured to get www.domain.com and portal.domain.com to be directed to different containers but answering on the same port. 

      11 Mar 2011
    1. User avatar

      Todd Trimmer

      It means you have two distinctly separate installations of Tomcat. Two CATALINA_HOME values, if you will. Two different processes running java controlling each Tomcat. If you defined two <Container> tags in the same conf/server.xml, that's NOT what they mean. If you look at advantages above, the point is to have separate CATALINA_HOME/common/lib and CATALINA_HOME/lib directories.

      29 May 2013
  2. User avatar

    Anonymous

    A question? What would be the system requirements. We are using a 4G ram machine with the server using about 2.5G for confluence (even though the confluence jvm is assigned 1G of ram). This leaves about 1.5G of ram available for Jira. Do we still need to increase the ram considering Confluence and Jira both can use up more than 3-3.3G of memory?

    21 Mar 2011
  3. User avatar

    Shawn Durrani

    I am also strugging to understand the technical implications of 'not deploying multiple Atlassian applications in a single Tomcat container' - I understand the concept but don't fully understand the resulting configuration changes.  I have followed Atlassian's recommendations on this page:

    • Installed JIRA as standalone using the installed Tomcat (w/MySQL on Ubuntu)
    • Installed Confluence as standalone using the installed Tomcat (w/MySQL on Ubuntu)
    • Configured Apache2 and directed httpd traffic to JIRA and Confluence
    • Note: These are all on the same physical server, no VMs involved (funnily, I did go about using VMs on my laptop for each app and it worked great across VMs).  

    Oddly, I can run JIRA on its own and I can run Confluence on its own.  However, if I fire them both up, either one of them or both of them fail.  As soon as I shut down one of them, I can recover the other application.  I've checked the server.xml files and confirmed that there are no shared ports between the two Tomcats. 

    Anyone have any ideas?  Have I still managed to run these two Atlassian products in the 'same container' and don't realise it? 

    10 Aug 2011
    1. User avatar

      Damon Tkoch

      It's a bit tardy but those that keep returning to this page, like I do, may find this information helpful.

      Each standalone installation provides its own container so you are indeed running separate containers.  It sounds like you may be short on memory or other resources.  (Other resources generally include the max # of open files, etc. but I would bet on memory.)

      My current medium-business installation runs confluence (256-512MB RAM configured) alongside Crowd (same), JIRA (256-678MB) and fisheye/crucible (128-1024MB?  hmm; I'll have to ask our sysadmin about that).  All this ran, sluggishly, on a VM with 4GB RAM (apache, postgres and basic linux services also running, and this regularly reached into swap space).

      We originally ran it on a 2GB VM and saw regular failures something like your own.  Doubling RAM to 4GB meant everything ran, sluggishly.  Doubling RAM again to 8GB eliminated swap space usage, improving performance; also doubling the number of CPU cores assigned to this VM (4 dedicated cores of a recent gen Xeon) gives us services that are, if not exactly snappy, entirely usable.

      20 Jan 2012
    1. User avatar

      Patrick Regan

      I'm running the same setup.  I just read through all the comments on this page: Deploying Multiple Atlassian Applications in a Single Tomcat Container, and my take-away is that if you do not use the self-install packages for JIRA and Confluence, you'll get this error with Tomcat.  The reason is that you can't run two Tomcat instances (for this software) under one JVM.  This is why the self-installers each include their own JVMs.  There are work-arounds to getting both to work properly under the same JVM, but it sounds like a real pain in the...well, pick a sensitive body part for reference!  

      24 Jan 2012
      1. User avatar

        Anonymous

        A little late in the game - but the JVM is just files. You can run all your Java software using a single JVM install. You probably should not try to run 2 Tomcats in one JVM (and I am not sure how you even can (smile) )

        14 Dec 2012
  4. User avatar

    Anonymous

    We are having the same problem. It won't run both at the same time.

    13 Oct 2011
  5. User avatar

    Anonymous

    I had that problem too - then increased the memory on the machine.  I am running Crowd, Jira, Confluence all behind Apache on a host with 4G of ram.  So far so good.

    19 Oct 2011
  6. User avatar

    Patrick Regan

    I'm having the same issue as Shawn outlined above.  Each instruction component above ('here's how to install Confluence...," "Here's how to install JIRA...") has multiple options, thus leading to about 8 (guesstimate) different installation scenarios for someone who wants to have Confluence, JIRA and/or Crowd all living happily together on one machine!

    In my case, installing Confluence and JIRA per the installers (Linux) was OK until I tried to enable SSL.  I then got into issues with each piece of software trying to reference the same cert keys.  Not fun.  I tried installing Confluence and JIRA via the archived zips, and now I'm having an issue with both applications trying to run on the same Tomcat instance (same PID).  I'm not sure what the fix is, but any help is appreciated.

    Atlassian: please clean up your install instructions!  It would be great to have all this information on one page rather than linked to pages within the separate Confluence and JIRA wikis (i.e. having two different design teams writing install instructions).

    24 Jan 2012
  7. User avatar

    Jeet Kumar

    We're planning to run JIRA and Confluence with MS SQL server on the same server.

    Which version of MS SQL Server should we use ?

    According to the documentation, Confluence supports 2008 R2, but JIRA only supports everything up to 2008.

    Should we just use 2008 ?

     

     

    14 Feb 2012
  8. User avatar

    Darren Pegg

    Is it recommended at all to run both Jira and Confluence on the same VM?

     

    Thanks


    Darren

    20 Mar 2012
    1. User avatar

      Sam Hall

      You can do it if you have well maintained virtualization infrastructure. I don't think Atlassian recommend running either Jira or Confluence on a VM even separately... and I quote "Virtual Machines are Evil".

      30 Apr 2012
      1. User avatar

        Darren Pegg

        I have now installed both on the same VM.. So far so good (smile)

        Our user base for confluence is around 70 users and half that for Jira.. So I doubt I'll see a huge problem.. Here's Hoping!!!!  (smile)

        Darren

        20 Jun 2012
      1. User avatar

        Zack Yovel

        Can't see where they say not to use VM in the link you posted. Dedicating a physical machine just for Atlassian apps sounds very impractical to me...
        I am currently installing a JIRA+stash+confluence+bamboo stack in a CentOS 7 VM with 6 GB ram and so far so good. Also as many comments here show, people do it in VMs and it works. Just know how much RAM to give your VM and how to fine-tune your JVM (which is what they say in your link)

        08 Jun 2015
        1. User avatar

          Sam Hall

          From April 2012...

          Garbage Collector Performance Issues#VirtualMachinesareEvil

          Doesn't say not to use them, but they stated at the time that they "...absolutely do not recommend them unless maintained correctly.".

          I use Jira and Confluence on VMware ESX as that's the platform available to me here. I can also say from experience that virtualisation of servers hosting Tomcat based apps has resulted in a very flakey service from time to time as priorities of the team that provisions this infrastructure differ from the needs of my apps. Or to put it another way, the benefits of virtualisation that the infrastructure team hope to leverage are often at odds with the demands of a Tomcat server. I'm still to this day discovering JVM quirks and possible optimisations at various levels to help stabilise such app servers. I can safely say that the maintenance overhead required to deliver a production service in my environment has far out weighed the cost of a physical server (but that may well be because we are not used to accommodating JVM based app servers, your environment may differ). I still have nightly scheduled app server restart just in case as I can't be guaranteed that nothings going to happen up stream to my server resources which isn't going to lead to rouge threads from Tomcat.

          This may be my last opportunity to comment on Atlassian Documentation, so sorry if I went on and on and on a bit... (smile)

          08 Jun 2015
        1. User avatar

          Sam Hall

          Here's a tip for virtualised CentOS, make sure to install "tuned" and apply the virtual-guest profile. This should help ensure the guest server plays nicer with the host.

          Something else I only recently discovered is that Linux will swap out stale application memory to use for disk caching (many sys admins are in disbelief of this when I point it out). The observable symptom of this will be application processes using swap even though the OS has plenty of free RAM. The culprit is a kernel setting called "vm.swappiness". I haven't found a general recommendation for Java based apps to avoid this behaviour, but this kind of agressive swapping behaviour seems so counterintuitive to me that I normally wind it back to "10" now. Seems to be a good thing to do even if it's hosted on physical server.

          JVM often doesn't access old RAM until it runs low and needs to trigger garbage collection. So this can result in plenty of it's memory pages having been swapped to disk by the time the garbage collector kicks in. The default setting of "60" roughly translates to mean that as soon as applications are using more than 40% of system wide RAM, the system will start preferring old memory pages for disk caching and swap out what ever was using it. When the garbage collector kicks in, it can cause a lot of the sorts of delays that seem to lead to a snowball type of effect where rogue threads start chewing CPU for no apparent reason. After that you gradually end up with more rogue threads due to poor system performance until the system becomes unusable. The usual reaction to this situation is to beef up the RAM on the system and allocate more RAM to the JVM. But if swappiness is the root cause, it's possible this could actually make matters worse as the garbage collection cycle would take longer and simply more RAM would be swapped out by the system by the time the garbage collector kicks in, leading to more unexpected delays for the JVM.

          09 Jun 2015
  9. User avatar

    Daniel Koch

    I use Jira 5.0.6 (EAR-WAR) and Confluence (EAR-WAR), running in a Tomcat 6 (6.0.35) multihost setup with mod_proxy. After Upgrade from Confluence 3.4.6 to 4.2.4 the configuration not working anymore. Are there any changes regarding running in Tomcat enironment?

    Actually the configuration of the host are configured in Tomcat´s server.xml (this worked for me since now):

     

    If I configure only one <host> the corresponding application (Jira OR Confluence) is working. But if I configure both of them only the Confluence instance is working, Jira got 500er errors. Do you have any idea how to solve this? Please write if you need logging statements...

    09 Jun 2012
  10. User avatar

    Jorge

    What about hardware requirements when they are both installed in the same server?

    18 Oct 2012
  11. User avatar

    Anonymous

    Is it possible to run both JIRA and Confluence on the same machine, with both responding on port 80?

    I'd like to have friendly URLs, without port numbers. E.g. wiki.example.com and bugs.example.com

    05 Nov 2012
    1. User avatar

      Sam Hall

      I think you'll want to setup a virtual host reverse proxy dealy. Apache is probably the most common option for this. Just run them both on different non-80 ports internally, then use Apache on port 80 with virtual hosts and proxypass/proxypassreverse directives to redirect the port 80 traffic on to the separate non-port 80 tomcat servers.

      05 Nov 2012
      1. User avatar

        Anonymous

        Hi Sam,  Can you share the way to to it? I don't know Apache at all... basically I need to proxy all traffic from port 8090 to port 80, and I have no idea how to do it. 

        21 Nov 2012
        1. User avatar

          Sam Hall

          Here's something I pulled from a quick google... http://linuxnextgen.blogspot.com.au/2012/01/reverse-proxy-in-apache.html

          Follow steps 1 and 2, then skip steps 3 and 4 and add this to the bottom of your httpd.conf instead:

          <VirtualHost *:80>
            ServerName jira.mydomain.com
            ServerAlias jira
           
            ProxyPreserveHost On
           
            ProxyPass / http://127.0.0.1:8090/
            ProxyPassReverse / http://127.0.0.1:8090/
          </VirtualHost>

          <VirtualHost *:80>
            ServerName confluence.mydomain.com
            ServerAlias confluence
           
            ProxyPreserveHost On
           
            ProxyPass / http://127.0.0.1:8080/
            ProxyPassReverse / http://127.0.0.1:8080/
          </VirtualHost>

          Change mydomain.com to whatever and also I've assumed jira is on 8090 and confluence on 8080. Of course you need to get the DNS pointing those subdomains to the same server. Hope that helps!

          21 Nov 2012
          1. User avatar

            Anonymous

            Done that already, I put it in  mods-enabled/proxy.conf but it's still doesn't seems to be working...

            21 Nov 2012
            1. User avatar

              Sam Hall

              I forgot to mention, you also need to specify somewhere before these a NamedVirtualHost directive.

              21 Nov 2012
    1. User avatar

      Anonymous

      If running Windows, you can do this with IIS too. Look to the Apache Tomcat site for help. I suggest sticking with Apache HTTPD (aka Apache Web Server) though.

      14 Dec 2012
  12. User avatar

    Anonymous

    Note 1: Running 2 instances of Tomcat will increase your memory requirements on the server/VM.  The disadvantage of one instance of Tomcat is that if you have to restart the container, you affect all the apps in that container.

    Note 2: Always front your Tomcat server(s) with Apache Web server or IIS so you can put up down pages, etc.

    Note 3: Tomcat runs in a JVM which has its own memory management - meaning, you might have more than enough memory on the server but not enough allocated in the JVM. If you run more than one product in the JVM, make sure you increase the JVM memory settings (more than one) appropriately.

    14 Dec 2012
  13. User avatar

    Marthinus Jansen van Vuuren

    I need some assistance.

    We have JIRA and Confluence installed together and it is working on our local network, I need to provide access to both instance in a secure way from our website that is hosted by third party vendor. How would I go about this? I assume I would have to setup an apache web server but need some guidance as to secure the connection. Can someone please help?

    And thank you in advance to your advice and precious time

    20 Dec 2013
  14. User avatar

    Melvyn Sopacua

    What really is missing here, is what the Integration in Here Be Dragons accomplishes, if you need to take another route. I'm currently tasked with moving our OnDemand Confluence installation to a local one and integrating JIRA alongside.

    I've setup JIRA as the user directory in Confluence and it's synchronized, yet is that all there's to the integration or do I need to do more to have JIRA issues show up on Confluence?

    30 Mar 2014
    1. User avatar

      Rachel Robins [Atlassian Tech Writer]

      Hi Melvyn,  you'll also need an application link between Confluence and JIRA.  See Linking to Another Application for more info.   Its the application link that allows you to view JIRA issues in Confluence, and see linked Confluence pages in JIRA. 

      30 Mar 2014
      1. User avatar

        Melvyn Sopacua

        Hi Rachel,

        thanks, but after some tinkering I found out this route only leads to flock of enraged wyverns. The core issue being that we've experimented with JIRA OnDemand in the Confluence OnDemand installation and quickly found out that we need greater control (macro's being the main) than OnDemand offers.

        This resulted in a system link in the Confluence OnDemand that required some direct database queries to get out. This kind of surgery I shy away from in complex environments like these, since I cannot confidently assess such a fix addresses all issues.

        So instead I rolled back to before I setup Confluence and setup an empty environment and JIRA integration through the setup wizard. Since we only had 11 spaces, I simply used XML Space import/export to get the content over.

        The added benefit is that all users are now centralized in JIRA and there's only a copy of my administrator account in the local Confluence user directory. I've kept a log of my actions and perhaps I'll do a more structured write-up for this specific case.

        31 Mar 2014
  15. User avatar

    Tuomas Valtonen

    Is there a way to do this without using Apache at all, only tomcat and virtualhosts?

    Tomcat can be configured for virtualhosts, but since JIRA and Confluence are both using their own Tomcat there is no common entrypoint which would have the virtualhost configuration.

    Everybody says its easier to use Apache as proxy in this situation, but Im not looking for an easy way here, can anybody tell me what options do i have here?

     

    21 Apr 2015
    1. User avatar

      Sam Hall

      Ok, another angle would be to assign an additional IP address to the server and bind each service to separate IP addresses. If new network interfaces are cheaper than figuring out apache then this would be a simpler option for you. Edit server.xml and add an address="X.X.X.X" attribute to the Connector node (I've never tried it, but it should work).

      Otherwise there's no getting around the fact you'll need to use a proxy of some description if you're going to run them both in parallel. Apache may be the cheapest/easiest option depending on what you're familiar with. Otherwise you could try squid, nginx which also have plenty of community examples for this kind of configuration. I'm sure there are plenty of commercial solutions if you don't have time for that. I always like a proxy in place to do SSL offloading if nothing else (I've always assumed that java isn't really the best choice of tools for handling encryption).

      21 Apr 2015
      1. User avatar

        Tuomas Valtonen

        Yes, that sounds like something that would solve this.
        It just creates additional dependency for the environment (another network interface).

        Looks like the best option is just to separate them on their own servers.

        21 Apr 2015
Powered by Confluence and Scroll Viewport