MidPoint in a Container

Last modified 27 Jun 2025 10:39 +02:00

Table of Contents

Quick Start
Benefits of midPoint in a Container
Deployment Schema
Build the Container
- Docker Image Name

Quick Start

Containers are the easiest and the fastest way to start working with midPoint.

If this is your the fist time installing midPoint, see MidPoint Quick Start Guide.

Benefits of midPoint in a Container

Using containerized midPoint has multiple benefits:

Dependency under full control
Containers are created with the required Java version.
Cloud friendly
Container can be run both locally (e.g. Docker, Podman), and in cloud (e.g. Kubernetes, AWS, Azure, Google Cloud).
The starting state is guaranteed
You can start the environment in a fully controlled way to support a range of scenarios.
Pre-configured environment
All elements required to initialize the repository are available.
A basic configuration is available and the environment only needs a few configuration steps to run.
The image can be customized to cover most use cases.

The image is based on Open Container Initiative (OCI) standards. The installation documentation is focused on using midPoint in Docker or vanilla Kubernetes.
You can use any other OCI compatible environment. While the installation instructions will still apply, you may need to customize your environment configuration.

Deployment Schema

MidPoint requires a repository, i.e. a relation DB, for standard operation. Also, a native repository structure (schema), which is available for postgreSQL, is required. In a containerized environment, this is covered by an additional container with a PostgreSQL instance.

The schema has to be initialized in advance. Once a correct schema version is ready, midPoint checks the initial object (content) and pushes it if necessary.

A generic repository implementation, which also covers other than PostgreSQL databases, is available. However, this repository schema is deprecated. Its feature set is limited, and no new features are available for this repository schema. If you are using this repository schema for historic reasons, we strongly recommend to migrate to native repository.

The availability of the deprecated generic repository schema may require an active subscription.

Figure 1. Schema of a containerized environment (basic setup)

In a basic setup, 3 containers are needed.

A midPoint instance (midpoint_server)
Once the environment is ready, midPoint can be started.

Image : evolveum/midpoint
Tag : <released midPoint version number><base OS>,for example 4.9.3-alpine.

Initialization of the environment (data_init)
This container handles all requirements for the environment. These need to be prepared before the midPoint instance starts.

The initialization image version has to match the midPoint container version to ensure the correct definition is used.

Repository init (Network data)
The process uses a ninja application to connect to the database as a client. If needed, the repository structure (schema) is created.

Configuration init (Storage data)
The process uses a ninja application to prepare the basic native repository configuration. All additional information, such as the DB URI, is updated at a later point via environment variables in the container.

In a complex installation, the initialization phase can be skipped by design. The environment would then be initialized separately as an explicit process during the build of the environment.
The provided configuration assumes that the environment is prepared directly during the first run.

Repository (midpoint_data)
For the repository, you only need a running instance of a PostgreSQL server that can connect from the midPoint container. Everything else is handled by the client side of the connection.

Image : postgres
Tag : <PostgreSQL version number><base OS>, for example 16-alpine. See the release notes for the recommended version of PostgreSQL.

For more information, refer to:

Build the Container

We build the images in our Jenkins infrastructure. After some basic tests, in which we make sure, for example, that the environment can be started, we push the tested images to the public Docker hub repository. All the necessary resources for the Docker image build are publicly available, as well as our other resources, on GitHub.

Docker Image Name

The full Docker image name consists of the base image name and a tag. The base image name is fixed (evolveum/midpoint:); while the tag differs depending on the midPoint version and the base operational system (OS) used for the image.

The following base operational systems are supported:

Table 1. Used base OSs for images and their tag suffixes
Base OS	Suffix for the tag	Description
Alpine	-alpine	Planned to replace Ubuntu as the default.
Rocky Linux	-rockylinux
Ubuntu	-ubuntu	Default. Omitting the suffix defaults to "-ubuntu".

See examples of full image names:

Table 2. Examples of tags
Version	Base OS	Full image name
4.8 release	Ubuntu	evolveum/midpoint:4.8
4.8 release	Rocky Linux	evolveum/midpoint:4.8-rockylinux
4.8-support (snapshot)*	Alpine	evolveum/midpoint:4.8-support-alpine
latest dev build	Alpine	evolveum/midpoint:devel-alpine
latest dev build	Ubuntu	evolveum/midpoint:devel-ubuntu evolveum/midpoint:devel
last released version (4.9.3)	Alpine	evolveum/midpoint:latest-alpine evolveum/midpoint:4.9.3-alpine
last released version (4.9.3)	Ubuntu	evolveum/midpoint:latest evolveum/midpoint:latest-ubuntu evolveum/midpoint:4.9.3

Support images are built from unreleased code. They are used to aggregate bug fixes between releases. If you are looking for a bug fix, i.e. the respective ticket is closed and has a code update, the fix will be included in the first subsequent support build. The name of this tag can change in time so it is recommended to check the naming from time to time.
Since version 4.8.3, images are published for the AMD64 and ARM64 platforms. The images are published with a multi-platform manifest. You only need to request a tag, and the appropriate platform is selected automatically.

Was this page helpful?

YES NO

Thanks for your feedback