Top 4 recipes to deploy Jira with Docker in a single click

Guillaume VialIntegrations

It could be challenging to deploy Jira with Docker for the first time

At Apwide we develop apps/gadgets for Jira and Confluence. For development and testing purpose we constantly need to to create on demand Jira and Confluence instances with specific configuration. Applying the “eating your own dog food” principle, we have built an Atlassian Environment Self-service using Apwide Golive to deploy Jira with Docker.

In this article, we are sharing some of our resources and recipes so that you can deploy your own Jira with Docker!

Official Docker images

Atlassian propose an official docker image for almost all of their products. You should first have a look at it and use one of these official images maintained by Atlassian. However, it would be too easy if every Atlassian product would be available here…

Unofficial Docker images for Jira

At the time we are writing these lines, there is still no official Jira Docker image.

The reasons why Atlassian is not willing to publish an official Jira image are not very clear to us. There are some useful information about how to migrate Confluence and Jira to Docker. There is another interesting thread debating about using Docker images with Open JDK or not.

You are not left with no solution as there are many good and unofficial alternatives available. In the table below, we have tried to make a summary of the different Jira images you may find on Docker Hub. Our listing is not exhaustive, we have listed the ones that we found interesting to mention and to compare to each other.

Comparison matrix of unofficial Jira Docker images

Comments JDKJira Server + Data CenterPraqma did a great job providing and documenting this image, you should really check this option first!
cptactionhankOpenJDKJira Core
Jira Software
Jira Service Desk
Very popular, what we use at Apwide
JiraGood doc, includes postgres db
ahaaslerOracleJira SoftwareMaintains also ready to use postgres images for Jira
dchevellOpen JDKJira Service Desk
Jira Core
Jira Software

frogbisOracleJira SoftwareNo support of Reverse Proxy configuration, not popular
zcalusicOracleJira Core

An alternative to build your own Images

An alternative to using existing docker images, is to build your own images that fit exactly to your needs. You can naturally start from scratch or fork one of existing docker image.

Idalko provides an open source tool to help you to build and maintain your own images of Atlassian tools. If you like Docker compose, Python and Ansible, you may be interested to learn more about it!

Even if we have not used this solution at Apwide, this approach seems to be very flexible and powerful.

Jira/Confluence Data Center on Kubernetes

Watch this excellent talk that was given by Praqma during the Atlassian Summit 2018 at Barcelona:

Praqma has recently made all their production grade Helm Chart and docker images available as open source: !

We have deployed several testing Jira instances to our Kubernetes cluster using these Praqma Helm chart and it rocks!!

Recipes and Takeaways

In the following sections we will give you some recipes using the cptactionhank docker images.

Recipe 1: Create a new empty Jira / Confluence docker container

docker run \
    --name "new-dockerized-jira" \
    -p 8081:8080 \
  • Very convenient to get a completely standalone and “vanilla” running container
  • Not convenient if you have already an existing dataset, with a set of plugins and licenses you must install at each time you create a new container…
  • N.B. cptactionhank provides an online command generator that may help you

Recipe 2: Re-use data of an existing Jira instance to create new Docker container

  1. Stop your running Jira server
  2. Backup the database
  3. Backup the JIRA_HOME folder
  4. Edit the “dbconfig.xml” file at the root of your JIRA_HOME
    It is important to check that the url used to connect to the database is accessible from the docker container that will run JIRA. For example: localhost or will not work if the database is not installed in the same container than JIRA. Use for example the IP address of the database or a domain name that is visible from JIRA docker container.
  5. Create and start a new Docker container using the existing JIRA_HOME and DB with these 2 docker commands:
# jira-home must point to the jira-home folder of the Docker Host
docker create \
    --name "jira-aug" \
    -e X_PROXY_NAME='localhost' -e X_PROXY_PORT='8082' -e X_PROXY_SCHEME='http'  \
    -p 8082:8080 \
    --volume "your/host/path/to/jira-home:/var/atlassian/jira" \
    --env "CATALINA_OPTS= -Xms512m -Xmx1g -Datlassian.plugins.enable.wait=60" \
docker start jira-aug

Depending on your current configuration, certain data may not be stored in “JIRA_HOME” folder. For example:

  • proxy settings or any other settings that are stored in Tomcat server.xml file
  • specific libs or configuration that may have been added to your tomcat installation (ex: libraries for SSO authentication)
  • container logs

These specific files and setup must be integrated in your docker container or modified after installation.

Recipe 3: Upgrade to a newer version of Jira with Docker

Upgrade operation is basically the same as described in Recipe 2: 

  1. stop your existing container and rename it (just in case…)
  2. create a new container with the version of Jira that you need and using the same parameters as the old one (use docker inspect command on the old docker container if required)
  3. start the new Jira container: the upgrade will be performed automatically at startup
  4. Check that the upgrade worked (or rollback)

You cannot “downgrade” an existing Jira dataset. Let say that you have a running Jira 7.8.1 server: you will not be able to start a new container with Jira version<7.8.1 using a Jira 7.8.1 database. If you have good reason to often go back to older versions of Jira, your reference data set should be generated from the OLDEST version of Jira that you want to be able to use.

Recipe 4: Manage your docker containers in Jira

Writing docker command is very convenient but it is not the only way to go, especially if you want to give more autonomy to non technical guys that may require new Atlassian environments. We will show how you can go a step further and use Awide Golive to build a completely automated self-service in Jira to create, upgrade and remove Atlassian environments!


  • 1 running Jira instance with Apwide Golive installed, we will call it the Jira MASTER environment
  • 1 Jenkins server
  • at least 1 Docker host to create and run new Jira Docker containers

Behind the scene:

For more information and examples on how you can configure this, check our Jenkins Shared Library documentation.

Apwide can drastically help Atlassian administrators to manage their Atlassian environments assets: learn how to visualise add-ons expiration dates on a timeline, version of add-ons installed, status of environments, urls,…


Some useful Docker commands

#open a bash in a running container as root
docker exec -it -u root your-container-name /bin/bash
#map a port that is only visible from (required if container must be protected by a reverse proxy)
docker create --name "jira-aug" -p cptactionhank/atlassian-jira-software:7.12.1
#visualise configuration of an existing container
docker inspect <container_id>
docker inspect -f '{{json .Config.Cmd}}' <container_id>

Check also this article:
Top 10 docker run command options you can’t live without

Docker Pitfalls and Lessons Learned

Even if we love Docker, it was sometimes painful and we learned from our errors. Below are some of our “lessons” learned (and we are keeping on learning!  ):

  • By default Docker is exposing your mapped port to anyone able to connect to the docker host. If you want to protect your docker containers behind a reverse proxy, you should expose your port to the reverse proxy machine only using advanced port mapping options
  • It is a good idea not to use root user to execute docker command. Problem arise when docker host and docker (often executed as root) container share a common volume: groups/users/permissions must be writable by both host and container!! Check this very interesting/useful article on the topic:
    Running a docker container as a non root user
  • quite obvious but… when something is wrong: always ask yourself if the faulty command must be executed in the docker container or in the docker host. They are completely different execution environments!