<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Over the years the engineering team here at Isos Technology have helped 100s of clients implement and manage Jira Server (and Data Center). An essential part of how we set up Jira is the use of a reverse proxy to handle incoming http/https connections for almost all configuration options. Many customers have questioned why we do this since, as we all know, Jira has a built-in web server. Adding nginx in some cases seems like you are adding complexity to the Jira configuration. If Jira's built in Tomcat can handle connections directly, why add nginx to the mix?

Well wonder no more! Here's a list of why we choose to go the nginx route when setting up Jira (and heck, these all apply to Confluence too):

SSL termination

Yes, Jira's Tomcat DOES support SSL. However, if you read the instructions in the link provided, you'll see a few things that make this configuration less than optimal:

  1. The configuration is pretty complex. Adding SSL certificates to nginx is super easy.
  2. It requires Jira downtime to add or update SSL to Tomcat. You can add or change SSL certs with nginx  with no perceivable downtime to Jira.
  3. In our tests, it appears that nginx is more performant in dealing with SSL connnections over Tomcat.
  4. Letsencrypt support: nginx works with Letsencrypt almost out of the box for free SSL certificates... while Tomcat, not so much.

If  you are running SSL, please use nginx.

Content caching

In many synthetic load tests and real world traffic scenarios, the Isos engineering team has observed that using nginx in front of Jira can increase the load a Jira server can handle while reducing overall load. This is due to the fact nginx can be configured to cache static content. Every time Tomcat serves up any content, static or dynamic, Tomcat must process that request. If nginx senses static data it has served before, it will intercept that call thus saving effort. In some cases, we have seen a 20% lower load / 15% increase in request volume on a single Jira Server node.  Our friends at Service Rocket have written a handy blog post on how to configure nginx for caching with Jira.

Mitigation of security vulnerabilities

If you are an Atlassian customer, you will have noticed that there's been an uptick in security vulnerabilities with Jira, Confluence and Bamboo. In the case of each one of these security issues, we've often found that one can implement security fixes at the nginx layer instead of being forces to immediately upgrade apps. This has allowed our customers to schedule or put off applying security updates until it is convenient for their organization.


In many situations we need http style logging for Jira traffic. You can turn that on within Jira but we've seen that logging puts more burden on Tomcat. Also, the logging format options of nginx are much easier to activate than with Tomcat.

Cluster maintenance

A lot of Isos clients run Jira Data Center. In that configuration there are many cases where one might want to take Jira out of a live cluster without having to fiddle with the load balancer that feeds traffic to said cluster. If you run nginx in front of Jira, all you need to do is shutdown Jira and all traffic will immediately drain to other nodes while Jira remains up for further diagnosis. Once you are done with the maintenance, you can turn on Jira which will almost immediately start serving traffic. Because Jira was never shut down, its index cache should be current and ready to go.

Managing JIRA at Scale White Paper

See More From These Topics