Dockerizing development and deployment of OpenMRS

As the world has moved to containers for development and deployment we will be working on providing ways for OpenMRS to follow up with the container approach.

OpenMRS is not new to Docker. Containers have been gradually introduced by OpenMRS SDK e.g. providing runtimes and distro Docker builds. Yet, the time has come to step it up.

The use of containers for application development and deployment gives a strict control over dev and production environments and it makes them aligned. Developers write and debug applications in isolated environments that are more closely matching production deployments, which eliminates many of infrastructure issues. In addition dev community can better respond to security issues and upgrade infrastructure that OpenMRS is running on.

As part of the work we will be introducing practices and toolset for common administration tasks such as upgrades and backups. Later down the road we will develop common practices for running OpenMRS in a cluster and enable horizontal scaling.

Do not be put off by all this. It is going to be introduced transparently and you will have a choice to use it or not, yet we will continue to push towards the container first approach. We are hoping that eventually we will all be running in containers.

To start with I will be focusing on:

  1. Migrate OpenMRS 3.x build to docker. The assembly of artifacts is going to happen inside Docker builds as opposed to Docker image being produced of artifacts assembled by OpenMRS SDK outside of Docker. We will benefit from Docker caching and multi-stage builds to speed up the whole process. I will share more details as soon as I have a proof of concept.

  2. Dockerize our main repositories including openmrs-core, openmrs-esm-core, etc. so that we can develop in Docker and produce proper Docker images.

Please do reach out if you already use containers in production deployments of OpenMRS. We would like to learn from your experience and make it better for everyone.


This will be great @raff ! Our team at UW has been doing a lot of work over the past few years on CI pipelines and dockerization of OpenMRS (and other tools). Be sure to reach out to @mozzy and @pmanko to learn/leverage what we’ve experienced/built/lessons learned. I’m hoping that your vision has some similarities (I think I recall Grace saying that we’re aligned with where you say you’re headed here).


Thanks @janflowers!

@mozzy and @pmanko have you been utilising Dockerfiles produced by OpenMRS SDK for your builds? Did you make any tweaks to them? If so, would you be able to share your Dockerfiles?

Are you using docker-compose or deploying to some cluster?

1 Like

Thanks @raff for starting work on this. i believe it will greatly improve developer experience with openmrs .

On our side ,we basically use docker-compose for our deploments.
We include maven builds ,assembly of artifacts etc, as part of our docker builds.
We make use of github actions to integrate this as part of our PR workflows .

Here are of some of our docker files isante-server , isante-db


@raff - I’m here with @samuel34 in person and we’re wondering if there are any updates on item #1 above :slight_smile:

@grace, I’ve been experimenting a bit and I will be proposing the following structure:

  • openmrs core docker image as a main image to be extended by other images and not directly for deployments
  • openmrs platform image built on top of the openmrs core image to be extended by other images and not directly for deployments
  • openmrs infra docker image as a complementary service to be used to do infrastructure maintenance like scheduled DB backups, DB restore scripts, services status page, maintenance page, etc.
  • openmrs distro images built on top of the openmrs core, platform or other distro images e.g. RA In openmrs distro images we will be adding custom modules, metadata and the old style UI. One will be able to take any openmrs distro image and build a customized distro image based on it. It will naturally transform to a backend only service once the new 3.x UI replaces the old style UI.
  • openmrs distro UI images with the new 3.x UI, which will be built and deployed as a separate service. Builds and deployments of a UI service will be independent of a backend service, thus reducing the build and deployment time of the whole distro when a change is applied only to UI or backend.

This structure follows pretty much the same approach that proved to work well when creating distros with OpenMRS SDK and it will naturally coexist with the SDK approach. It has a slight modification on extracting the 3.x UI to a separate build and image as well as introduces yet another service to orchestrate some of the OpenMRS administration tasks.

Given this layout I’ve started from the 2nd point listed in my original post. I expect to have a proof of concept to share within a week or two.


This is great. @mohant and others in Bahmni docker sub-groups have done some interesting work over base openmrs (backend only). Maybe worthwhile to have discussions.