Proxying Atlassian Server applications

Atlassian Knowledge Base

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community


This page provides an overview of some common network topology options for running any of the Atlassian Server applications (i.e. JIRA server, Bitbucket server, Bamboo server, Confluence server) behind a reverse proxy on a self-hosted environment.

The following guides will cover an overview of how to integrate Atlassian's tool set with proxy technologies with further instructions on basic working set ups on both Windows and Linux platforms.

Note that Atlassian applications do not need to run behind a web server – they are capable of serving web requests directly using the bundled Tomcat application server but that's a fairly common set up amongst our customers.

What do you wish to do?

Connecting to your Atlassian application directly over HTTP


Connecting directly to any of the Atlassian applications via HTTP is the Atlassian out of the box configuration. When set up this way, the user accesses the applications directly over HTTP. That means without using SSL which means that all communication between the user's browser and your Atlassian application will be unsecured. Simply follow one of the guides below:

You may also wish to consider the following:

  • The Atlassian applications, by default, will listen for requests on the following ports:

ApplicationConnector PortServer Port
Bitbucket Server79908006



  • These ports can be changed if required. For example, if you installed JIRA, by default you should be able to access it from:
    • Browser on the local server that hosts JIRA: http://localhost:8080
    • Browser on remote server: http://servername.domain:8080 or http://<Server_IP>:8080.
  • It is required that you Set a context path for Atlassian applications for each one of the Java web applications if you are running them all on the same server (that means, even if they are not Atlassian applications).
Bitbucket server note
  • Securing Git operations over SSH between the user's computer and Bitbucket Server is a separate consideration as this set up we describe here only handles HTTP. Please read through Enabling SSH access to Git for more information.

Connecting to your Atlassian application through a reverse proxy over HTTP

You can run any of your Atlassian applications behind a reverse proxy, such as Apache HTTP Server. You may wish to do this if you want to:

  • Use your Apache reverse proxy to be a gateway through which users outside the firewall can access your Atlassian application
  • Use a different port number to access your hosted Atlassian application, particularly if you are integrating your Atlassian Server application with any of our Cloud applications. See Link to server products from cloud.
    • While ports can be changed, it is not recommended that you run your application using root which is a requirement if you want your Atlassian application to listen on port 80
  • Use a different context path to access your Atlassian application

When set up this way, any external access request to your Atlassian application is done via the reverse proxy using HTTP. Therefore, the communication between the client browser and the proxy is done without using SSL in this setup. All communication between the user's browser and Apache, and so your Atlassian application, will be unsecured, but users can only browse your Atlassian application via proxy and not directly. 

Using Apache httpd reverse proxy

For the purpose of documenting this set up, we used Apache httpd. Other third-party servers (for example nginx or IIS) are not yet documented here.

Which Apache proxy module should you choose?

Here is a quick summary of points you should consider before making a decision:

As of Bitbucket Server 5.0, it is not possible to configure AJP between your proxy and Tomcat server.

Apache Module

Considerations / Advantage


  • mod_proxy_http has its configuration more consistent with other Apache modules  
  • mod_proxy_http works with any application server, and together with mod_proxy_html allows complex URL rewriting to deal with different application paths


  • Using mod_proxy_ajp requires minor changes to the server.xml on the application side. 
  • No additional configuration on the AJP connector (proxyName, proxyPort, scheme) is required which provides tighter coupling
  • Better (and more granular) logging
  • If you are already using one of these modules then changing is likely to cause more hassle than it saves. Stick to the one you are using. As this scenario doesn't require encryption between any of the channels, you're fine with either choice
  • Note that mod_jk and mod_jk2 are other commonly used AJP modules and not covered by this documentation.

Using Microsoft Internet Information Services (IIS) reverse proxy

Internet Information Services (IIS) is one of the most popular web servers in use in the Windows ecosystem.

Configuring IIS with Atlassian's tools allows them to be configured to be accessed in the following methods;

Please follow Proxying Atlassian server applications with Microsoft Internet Information Services (IIS) to set up your Atlassian application with IIS.

Last modified on Nov 2, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.