Dockerizing a Liferay Bundle, Part 1

A Brief Overview of the official Liferay Docker images

While the official Liferay Docker images have been out and available for many years now, and I'm sure many people are making use of them, I haven't been able to find documentation or a guide that talks about using them, so I wrote this. This is the result of my own experimentation and usage of said images.

In this part, we will cover what the Liferay Docker image offers and the features/functions that are unique to the official Docker images. The official Docker images can be found here: and the Overview tab provides all the information here. I am using the DXP version, but the equivalent Portal CE version will be the same. Of course, people are free to make their own Docker images to suit their needs, but this puts the burden of maintenance of said bundle on them, not on Liferay. I have also rolled my own Docker image of Liferay, and maintenance was not easy, especially when considering repeatability and distributing copies to others.


I will assume you (the reader) will have Docker installed and know how to start a Docker image, as that Is about the extent of knowledge I had going into this. I will also assume a fair familiarity with a Liferay Tomcat bundle, and general familiarity with how a Liferay deployment works.

Environment Variables

The exact entries can be found in the Liferay file with the key is ALL_CAPS_WITH_UNDERSCORES. Not all values will have equivalent Docker environment settings, but some will be useful when setting up things like JVM options or database connections.

My personal preference is to keep the environment settings to a minimum and do the rest in

Environment Variable Example:
For example, if you want to provide only English and Portuguese, you could create a with the entry:
Or, you could set the environment variable:

These environment variables go into the docker-compose.yml file of the Docker images. Underneath the section for the Liferay image, there will be a portion of environment variables. This will become clearer when we look at the docker-compose.yml file in Part 2

File System

This caused the most confusion for me and took some experimentation to figure out. The Docker Hub documentation lists 4 directories that can be mapped and used. All of these directories will be copied into the Docker image and will some way interact with the image itself.

   - mount (head directory)
        - deploy
        - files
        - patching
        - scripts

If we understand how these directories work in relation to the Docker container, we can use it to patch or even “Dockerize” a bundle.


Hot deploy directory for the image. Place files here and they will be deployed into the image. This is good for testing things out on a running image. If you deploy something here, it will not persist if the image volumes are cleared.


Internal file mapping for the bundle. This is where you interact with the file system of the application server (Tomcat). Inside here is where the file goes, and anything you want to add to the app server deployment, such as JDBC drivers and custom plugins that you want to persist. In Part 2, the bulk of the work to convert a bundle to Docker will be here.


This is where you need to deploy any hotfixes that Support will hand out. You COULD deploy fixpacks here, but you'll need the Patching Files for the baseline bundle that you are using. Patching Files is 1 GB itself, and adding in 600 MB for the fixpack, you're adding 1.6 GB to the bundle that you can save by specifying the fixpack version as your baseline image.


Executable scripts can be deployed here. They are run alphabetically. These scripts are run after all the files in the other directories are processed. I have yet to execute a script.

In Part 2, I will show the process I went through to convert one of the demo bundles that was created into a Docker setup. I used this Docker setup along with GitHub to distribute the demo to other Liferay Sales Engineers and affiliated parties.