Documentation for Confluence 5.8 (Server).
Documentation for Confluence Cloud and earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata

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.


(warning) The information on this page does not apply to Confluence Cloud.

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:

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


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

    1. Anonymous

      You've done what they recommend. 

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

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

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

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

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

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

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

  4. Anonymous

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

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

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

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



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




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

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


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

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

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

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

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

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

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

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

        1. Here's something I pulled from a quick google...

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

          <VirtualHost *:80>
            ServerAlias jira
            ProxyPreserveHost On
            ProxyPass /
            ProxyPassReverse /

          <VirtualHost *:80>
            ServerAlias confluence
            ProxyPreserveHost On
            ProxyPass /
            ProxyPassReverse /

          Change 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!

          1. Anonymous

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

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

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

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

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

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

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

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

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


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

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