MidPoint System Requirements

Last modified 04 Aug 2025 14:45 +02:00

Table of Contents

Deployment Architecture
MidPoint Server Sizing
- Number of MidPoint Server Instances
Database System Sizing
Connector Servers (Optional)
Your Options for High Availability Deployment
Software and Infrastructure Requirements
- Basic Single-Node Deployment
- Multi-Node Deployment
Environment Requirements
- Keep the Environments as Similar as Possible
See Also

This document describes system requirements for midPoint and its components.

Deployment Architecture

A midPoint deployment consists of the following units:

MidPoint server
Database system
Connector servers (optional)

Each deployment unit has particular characteristics and requirements as described in the sections below.

It is impossible to provide precise midPoint platform sizing and parametrization because it vastly depends on your particular usage patterns, number and nature of running tasks and connected resources, as well as synchronization and workflow processes.

This article gives general rules as well as estimates based on our experiences from typical deployments. You are expected to adjust the parameters based on your specific situation and IT operation best practices.

MidPoint Server Sizing

The midPoint server is the core component of any midPoint installation. It handles the majority of user interactions and data processing, making it particularly sensitive to CPU load and RAM size. The table below summarizes the recommended resources for typical scenarios:

Table 1. Recommended MidPoint server parameters
	Minimum	Less than 5,000 users	5,000 - 50,000 users	50,000 – 100,000 users	More than 100,000 users
CPU	1 core	4 cores	8 cores	16 cores	Custom sizing ^*
RAM	4GB	8GB	16GB	16GB	Custom sizing ^*
Disk space	2GB	10GB	20GB	40GB	Custom sizing ^*
Disk I/O	negligible	negligible	negligible	negligible	Custom sizing ^*

^* Deployments with more than 100,000 users are supported in midPoint. However, due to the variability in large-scale environments, it is recommended to consult the specific hardware requirements with Evolveum Support.

Number of MidPoint Server Instances

The sizing table above assumes a single midPoint instance (node). Multi-node midPoint instances are usually deployed for high availability reasons, and they are usually two-node systems. Each node needs to be sized to handle the full load of the system, therefore each node should be deployed according to the midPoint server sizing requirements outlined in the table above.

Another reason for multi-node deployments is to isolate synchronous load (e.g., user interactions via GUI or REST API) and asynchronous load (e.g., tasks and processes). However, there is no universal rule for sizing such a system, meaning you need to do a case-to-case analysis and measurements. The values provided in the table above may serve as a starting point.

Database System Sizing

The repository database stores the vast majority of midPoint data.

The load on the database system depends mostly on the size and nature of the data, usage patterns, and the type and configuration of the database system used. Use the values below as general guidelines and adjust them to fit your specific use case. For a more precise estimate, contact Evolveum Support.

Table 2. Recommended repository database server parameters
	Minimal	Less than 5,000 users	50,000 – 100,000 users	More than 100,000 users
CPU	1 core	2 cores	8 cores	Custom sizing ^*
RAM	2GB	3GB	12GB	Custom sizing ^*
Disk space	1GB	5GB	20GB-100GB for 3 months audit	Custom sizing ^*
Disk I/O	small	medium	medium to high	Custom sizing ^*

The recommended values assume that beside storing operational data, you set up midPoint to keep only a reasonably small amount of historical data, such as audit records. If you plan to store historical data in midPoint for longer time span, you must account for that when sizing the database.

Shared vs dedicated database

The native repository of midPoint relies on PostgreSQL. We recommend using a separate database server even for smaller midPoint deployments. This is default for containerized installation. You may also consider two separate databases for audits and for the repository, as the access patterns and sizing requirements are quite different.

Connector Servers (Optional)

Connector Servers are small software components that act as a proxy for connectors that cannot run inside midPoint. Deployments of these components are quite rare.

Resource requirements of connector servers are usually negligible: a tiny portion of CPU and RAM, and a disk space measured in megabytes. We strongly recommend deploying these components on shared servers.

Your Options for High Availability Deployment

There are several approaches to implement high availability (HA) for midPoint deployments. Each strategy has different characteristics and costs:

Virtualization-Based Strategy for Failover
Multiple-node deployment

Is midPoint business-critical for you?

MidPoint is an identity management system, and as such, it is seldom a business-critical system. If midPoint fails, the impact is usually negligible. The integrated systems (resources) are independent of the midPoint instance by design. Therefore midPoint failure does not influence the operation of such systems in any significant way. A midPoint failure can influence identity management capabilities, password resets etc. But these functions are usually not critical for operation, especially if the outages of midPoint are short (minutes). Even longer outages (hours) do not usually impact operation of the infrastructure in any significant way. This is important to keep in mind when choosing the right HA strategy.

Virtualization-Based Strategy for Failover

The easiest way to implement a failover strategy is to leverage the underlying virtualization infrastructure. If the host machine running the midPoint virtual machine fails, it is easy to move the entire virtual machine to a different host. The transfer inflicts some downtime (usually a few minutes). However, since midPoint is not a business critical system, this downtime is generally acceptable.

In this scenario, midPoint is set up to run in a single-node configuration (default), and no extra configuration is necessary. You only need to set up backups at adequate frequency to minimize data loss in case of fire. The failover mechanism is completely transparent. MidPoint has internal mechanisms to recover from system outages which are utilized after midPoint restarts on a different machine.

This approach does not achieve high availability per se because midPoint runs on a single node and if that node fails, midPoint goes down. However, it is a cost-efficient failover strategy to prevent a prolonged midPoint downtime, especially if midPoint and the database run on the same virtual machine.

High Availability Through Multiple Nodes

This approach relies on deploying multiple instances (nodes) of midPoint and using a standard HTTP load balancer at the HTTP layer (in the sticky mode). All midPoint nodes connect to the same database. Depending on how you installed midPoint, you may choose to share the database with other systems or dedicate it to midPoint. As mentioned above, we always recommend using a dedicated database for midPoint.

Refer to the section on multiple-node deployment for details.

Database High Availability

MidPoint does not explicitly support repository-level clustering. Even in big deployments, the bottle neck is usually the amount of resources or the effective communication speed of the resources.

We suggest to primarily set up a proper backup solution and verify the time to recovery.

If you require clustering the DB, you can set up an active-passive failover mechanism and take advantage of the PostgreSQL database-side clustering support on the JDBC driver level.

This is the most expensive set-up and it is seldom justifiable due to the cost of the HA database system. The usual compromise in this case is to use active-passive database HA strategies. Due to the low criticality of midPoint, this is usually acceptable from the operational point of view.

Software and Infrastructure Requirements

When starting an IAM project, you must prepare not only the midPoint servers but also the database and load balancer (if required). You need access to the infrastructure where these servers are running, as well as to the source and target systems.

Refer to the midPoint Releases documentation for software requirements.

Basic Single-Node Deployment

The following schema represents a basic deployment environment:

Basic midPoint deployment schema with midPoint and its repository in the center; lines showing access routes to example source and target resources and user’s computer. Optional VPN is placed between midPoint and the computer

Figure 1. Basic single-node midPoint deployment

In the center of the schema, the largest rectangle represents a virtual machine, usually running Linux, with the basic required set of tools installed. MidPoint runs on this virtual machine. It may also be a Docker container with a midPoint image. The database repository preferably runs on a separate virtual machine, albeit possibly on the same physical server.

Shared Database Repository

For the database repository (DB), you can use an existing DB server or set up a new dedicated one. The midPoint server needs to have access to it using SQL via TCP/IP. Do not forget to configure the firewalls to enable communication over the used ports.

The database needs to be configured prior to midPoint installation so that the person who installs midPoint can configure the midPoint instance correctly. If you deploy in containers, see MidPoint in a Container for details.

Notification System

If e-mail notifications are needed, access to the SMTP server and an account with send privileges is required. If you need SMS notifications, you also need access to an SMS gateway and have the account privileges to send SMS.

Secure Access to Your Deployment

If your setup requires access to your midPoint deployment over the public Internet, you need to secure the communication between end users' computers and the midPoint instance. Typically, HTTP communication encrypted using TLS is enough. A more heavyweight solution is to use a virtual private network (VPN) for everyone who needs to access midPoint. TLS encrypts the communication between users and midPoint server (or the load balancer before it), VPN provides a tunnel from the user’s machine to midPoint (or the load balancer).

Optional SSH Access to Nodes

You can set up an SSH access to your midPoint nodes. You can use it, for example, to access midPoint configuration files and logs or to troubleshoot your deployment. The options for issue resolution vary depending on how you deploy and set up midPoint.

Resources

There are many different communication protocols the resources may use. The schema above shows just a couple of the most common ones.

You may have an HR system which is only able to give midPoint CSV files, there may be more complex systems, data of which you can access using SQL, you may need to connect an Active Directory, and so on. With some resources, such as SAP and JCo, you need to enable API on the target resources, open your firewall on the servers where the target systems run, and create an account with appropriate permissions to manage identities. In certain cases, you may have to deploy a connector server to access some special resources. The list of options is endless and very much depends on what exactly you need to manage with midPoint.

Multi-Node Deployment

The situation gets a bit more complex when you deploy midPoint on two or more nodes:

MidPoint deployment schema with two midPoint nodes and their shared repository in the center; lines showing access routes to example source and target resources and user’s computer. Load balancer and an optional VPN are placed between midPoint and the computer

Figure 2. Deployment of midPoint with two nodes, a load balancer, optional VPN, and a few example resources

Work Distribution

In multi-node deployment, the job distribution among the nodes is handled centrally.

The repository DB keeps track of worker task states, i.e., which are to be done, in progress, or done. MidPoint uses the Quartz job scheduling library on each node. The Quartz library instances use the central JDBC scheduler job store to ensure that no single task is processed by multiple nodes concurrently. The available worker tasks are picked by the nodes on the first-come-first-served basis, which ensures a reasonably even task distribution.

Refer to Task Manager for details on task handling in midPoint.

Communication Among Nodes

The nodes communicate primarily with the central repository database rather than among themselves. One exception is cache invalidation. When a node changes data in the midPoint database, the node informs other nodes about the need to invalidate their cache. The communication between nodes runs over HTTPS.

Refer to the article on high-availability deployment for details about node communication.

All Nodes Are Created Equal

All nodes need to have the same configuration and access levels regardless of whether you deploy midPoint on 200 nodes or just one. There must be no differences because all nodes are created equal: when one node goes down, others need to replace it in full.

You can check that connections to resources work as expected using ping, telnet, or wget, for instance.

Environment Requirements

Usually, at least two environments are typically used for the development of an IAM deployment: test and production. In many cases, there is also a local midPoint installation on the identity engineer’s computer and a separate development environment in the customer’s infrastructure.

Keep the Environments as Similar as Possible

The best practice is to use a configuration that is as similar as possible in all these environments. However, the environments should also be completely isolated so that the test environment cannot touch production data on a resource. VPN can be shared.

We recommend having the same operating system, midPoint version, and resource data for all environments. If same is not possible, as similar as possible is desirable. Any differences may lead to situations where something works and is well tested in one environment, but does not work in another.

Regardless of how similar you can keep your environments, we suggest you simulate every change on the production environment before you deploy it. Using simulations, you can discover issues before they can do any damage to your production data.

If the data you manage with midPoint are sensitive and cannot be used in the development environment, you can obfuscate them and only use a part of them as a sample. However, the schema and all attributes that you use need to be used the same way as in the production environment to minimize differences.

When deploying the solution to production, you need to have access to the production environment and the data there. In this case, it is not necessary to obfuscate data for the test or development environments, because the same identity engineer is responsible for the development, testing and deployment.

Irrespective of whether you use the original or obfuscated data, you need to be able to use production data in the development phase to prevent future issues.

Note that running an IDM project involves consolidating users, changing the data structures, and accessing data in general. Every discrepancy and exception will surface in production, and you will need to decide how to handle it. That is why it is best to implement your IDM project when you are not doing acceptance testing, have problems in production, or face hard deadlines.