Why midPoint high availability is harder than adding a second node
midPoint high availability means running several midPoint nodes that share one central database, placed behind a sticky HTTP load balancer, with the database itself made highly available. Adding a second node to an existing installation is the easy part. The difficulty is that a midPoint cluster only behaves like one system when the nodes agree on sessions, cached data, scheduled work and stored state, and each of those four areas needs a deliberate decision before go-live.
Session stickiness comes first. midPoint's multi-node model depends on the load balancer keeping a user's HTTP requests on the same node, so a user working through an access request or a certification campaign is not bounced between nodes mid-task. Confirm with your load balancer team how stickiness is set (cookie or source address), how it behaves when a node is drained for maintenance, and what happens to a user whose node fails. The system requirements page describes the sticky load balancer as a requirement for multi-node deployments, so treat it as a design input, not an optional tuning step.
Cache consistency is the second problem. Each node keeps in-memory caches of objects it has read from the repository. When one node changes an object, the others must invalidate their copies, and midPoint does this node to node over HTTPS. That means the nodes need reachable, correctly configured internal endpoints, and your network and certificate processes must cover them. A failed or blocked invalidation path does not usually stop the cluster from starting. It shows up later as stale data, which is harder to diagnose than a clear outage. Plan a test in which you change a role or user on one node and verify the change on another.
Scheduled tasks are the third problem. Reconciliation, synchronization, and other recurring jobs must run once across the cluster, not once per node, or they will overlap, duplicate provisioning actions and compete for connector sessions. midPoint uses Quartz for distributed task scheduling, but the operational questions remain yours: which nodes may execute tasks, how a task interrupted by a node failure is resumed, and whether any job must be pinned. Ask your implementation team to list every scheduled task and record its expected behavior when a node disappears during a run.
The database is the real availability boundary. Every node depends on the same PostgreSQL repository, so a cluster of three nodes with one database server has the availability of that database. Confirm the replication topology, failover mechanism, recovery time you can accept, and how backups are tested by restoring them into a separate environment. midPoint recommends running PostgreSQL on a separate database server from the application nodes. This section covers the cluster and database layer only. Connector design and single sign-on are covered in other sections of this page's topic set.
Which midPoint components must be clustered and how they talk
A midPoint cluster is only as available as its weakest shared component, so every node, the load balancer, the database and the scheduler need a deliberate design. The cards below cover each moving part, what it contributes to availability, and what your team must configure before go-live.
midPoint nodes as identical Java applications
Each midPoint node is a Java application that runs on Linux, either in a virtual machine or from Docker images. Availability depends on running several nodes with identical versions, Java runtimes and configuration, so that any node can serve any request. Check that the Java version matches the midPoint release you chose, since midPoint documents different recommended Java versions for 4.10 and older than for 4.11 and later. Confirm that configuration and any custom files are deployed to every node the same way.
Sticky HTTP load balancer
The load balancer distributes administrator and user browser sessions across midPoint nodes and must keep each session pinned to one node. Without stickiness, a login or a multi-step web form can break when a request lands on a node that does not hold the session. Configure session affinity on the balancer, define a health check that removes a failed node from rotation, and test a node failure during an active session. Confirm the exact stickiness method with your balancer vendor and midPoint's system requirements.
Shared central database
All nodes read and write one central repository, so the database is the single point that must survive a failure for the cluster to keep working. Every node must point to the same database endpoint, which can be a virtual address managed by a database high availability layer. Plan replication, failover and backup for this database as its own project, because a clustered application tier does not protect data held in a single database instance. Ask for the failover behavior in writing before relying on it.
PostgreSQL native repository on a separate server
midPoint uses PostgreSQL as its native repository, and midPoint's system requirements recommend running it on a separate database server rather than on the midPoint nodes. Separation lets you size, patch, replicate and back up the database without restarting the application tier, and it keeps database load from competing with the Java processes. Confirm the PostgreSQL version your midPoint release supports, and plan connection limits so that all nodes can connect at peak times. Test restore procedures against this server, not only the application.
Node-to-node cache invalidation over HTTPS
midPoint nodes keep local caches, so a change made on one node must invalidate the matching cache entries on the others, and this happens node to node over HTTPS. If the nodes cannot reach each other on the configured HTTPS path, a node can keep serving stale objects after a change elsewhere. Open the required ports between nodes, decide how the nodes trust each other's certificates, and check cache consistency after a change that is made through a different node than the one users are on. Confirm the configuration keys with the midPoint documentation for your release.
Quartz for distributed task scheduling
midPoint uses the Quartz scheduler to distribute tasks such as reconciliation, synchronization and certification campaigns across cluster nodes. Quartz must share one job store so that each scheduled task runs once, not once per node, and so that a surviving node takes over tasks from a node that fails. Configure every node to use the same clustered job store and the same cluster identity settings, then confirm with a test task that only one node executes it. Review task timing so that heavy synchronizations do not overlap during business hours.
Decisions to settle before building a midPoint cluster
This table compares the topology, database and release decisions that shape a midPoint high availability design. Read each row as a choice with its operational cost, and settle the database and Java questions first because they constrain the node design.
| Decision | Option and when it fits | Operational cost | What to confirm |
|---|---|---|---|
| Node topology | Single node with VM-level recovery fits teams that accept a restart window and want the smallest moving part set | Recovery depends on the hypervisor and restore runbook, and the team must rehearse it to trust the recovery time | How quickly the platform team can restore a VM from backup in your environment |
| Node topology | Two or more active nodes behind a sticky HTTP load balancer fits teams that need rolling patches and no single point of failure at the application tier | Each node needs identical configuration and Java, the team patches nodes one at a time, and session stickiness must be tested at the balancer | Balancer support for session affinity and health checks, and your change process for rolling node restarts |
| Node identity and cache | Multi-node deployments rely on cache invalidation between nodes over HTTPS | Node addresses, certificates and trust settings must stay consistent, and a misconfigured node can serve stale cache data | Node-to-node network paths, certificate lifecycle and how cache consistency is checked after a change |
| Database topology | Single PostgreSQL server with tested backups fits teams whose database platform cannot yet provide replication, with a longer recovery path | Recovery is a restore from backup, so the repository is unavailable until restore and reconciliation complete | Backup frequency, restore test evidence and the owner of restore decisions |
| Database topology | Replicated PostgreSQL managed by the team's own database platform fits teams with an established DBA standard for failover and replication | Failover behavior, fencing and connection routing belong to the database platform, so midPoint depends on that team's runbooks | The database high availability product and failover method used by your DBA standard, confirmed with the DBA team before design starts |
| Failover testing | Exercise node loss, database failover and balancer failover on a non-production copy before go-live | Each test needs a rehearsed procedure, a named owner and repeat runs after upgrades | Who schedules failover drills and where results are recorded for audit |
| Java version | midPoint recommends Java 25 for version 4.11 and later (Java 21 supported) and Java 21 for 4.10 and older (Java 17 supported) | Every node must run the same supported Java version, and Java changes require a planned test cycle | Your organization's approved Java build and patch process |
| midPoint release line | midPoint 4.8 (Curie) is an LTS release supported until 17 October 2028, midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026 | LTS lines suit teams that want fewer upgrades, while feature lines bring newer capabilities and more frequent upgrade testing | Support window against your planned go-live date and whether Evolveum subscriptions cover the chosen line |
How to build the midPoint high availability cluster step by step
This sequence builds a multi-node midPoint cluster on a shared PostgreSQL repository, with node-to-node cache invalidation, a sticky HTTP load balancer, and a single scheduler owner for Quartz tasks. Each step closes with a check you can record as evidence, and later steps assume the earlier checks passed.
Confirm release and Java version
Confirm the midPoint release you will run and the Java version it requires by reading the system requirements for that release. For 4.10 and older, midPoint recommends Java 21 with Java 17 supported. For 4.11 and later, it recommends Java 25 with Java 21 supported. Your platform team installs the same JDK on every planned node and records the release and JDK versions in the build record. The step is done when every node reports the agreed JDK and the release notes for the chosen version have been reviewed.
Provision PostgreSQL with tested backups
A database administrator provisions PostgreSQL on a server that runs nothing else, separate from the midPoint nodes, as the system requirements advise. Configure regular backups and retain the transaction logs needed for point-in-time recovery. Then restore a copy to a scratch server and point a test midPoint instance at it to prove the backup works. Ask the DBA to confirm which PostgreSQL version your release supports. The step is done when the restore completes, midPoint starts against the restored copy, and the restore time is written down.
Install and start the first node
The platform engineer installs midPoint on the first node, either in a Linux virtual machine or from a Docker image, and sets its repository configuration to the shared PostgreSQL database. Start the node once and let it initialize the schema. Store the initial administrator credentials in your secrets store rather than in configuration files. The step is done when you can sign in to the node directly, the repository tables exist, and the node logs show a clean start against the shared database.
Add further nodes with identical configuration
Build each additional node from the same release, the same JDK, and the same configuration files as the first node, changing only host-specific values such as host name and node identifier. Every node must point to the same repository database. Start the nodes one at a time so that schema checks and logs are easy to read. The step is done when every node starts against the shared repository and a test change made through one node, such as a new test user, is visible when the same object is opened through another node.
Configure cache invalidation over HTTPS
Configure cache invalidation so that a change on one node clears cached data on the others. midPoint carries this traffic over HTTPS, so each node needs a certificate that its peers trust, and firewall rules must allow node-to-node traffic on the port you choose. Confirm the exact cluster settings in the documentation for your release before changing them. The step is done when a change to a role or object on one node is visible on every other node without a restart, and a deliberately stopped peer shows up as an error in the logs.
Place a sticky HTTP load balancer
The network team places an HTTP load balancer in front of the nodes and enables session affinity, so that each browser session stays on the node that created it. Configure health checks against an endpoint that you confirm in your release documentation, and check that forwarded headers match what midPoint expects. Decide with your security team where TLS terminates. The step is done when you sign in through the balancer, refresh several pages without losing the session, and a new browser session lands on a different node from the first.
Confirm single-node Quartz task execution
midPoint uses Quartz for distributed task scheduling, so confirm that scheduled work such as reconciliation and certification runs on one node only. Check the scheduler settings on each node against the cluster design your team agreed, following the guidance for your release. Then open the task list in the administration interface and confirm that each scheduled task appears once and is assigned to a single node. The step is done when a test task runs once rather than once per node and the result is recorded in your build evidence.
How the cluster differs on Linux VMs, Docker and other platforms
On Linux virtual machines, each midPoint node is a Java process that your team installs, starts and manages on a host. The cluster is defined by host configuration, service definitions and network rules that you write and maintain. Node configuration lives on each VM, so the midPoint version, Java runtime and shared repository settings must match across nodes, while each node keeps its own identity. Node-to-node cache invalidation runs over HTTPS, so every VM needs a certificate chain that the other nodes trust.
- Node configuration: Keep the same midPoint version and Java runtime on every VM, and give each node its own identifier while sharing the repository parameters.
- Database connectivity: Allow each VM to reach the PostgreSQL primary through firewall rules, and size database connection limits for all nodes together.
- Certificate trust: Issue node certificates from an internal CA and add that CA to the trust store that midPoint's Java runtime uses.
- Load balancer health checks: Point the sticky HTTP load balancer at a health endpoint on each node that confirms the node is serving requests, not only that a port is open.
- Ownership: Your team owns OS patching, JVM updates, service management, certificate renewal and firewall rules.
Confirm with Evolveum the health endpoint and cluster settings that apply to your midPoint version before you build the load balancer checks.
midPoint can run from Docker images. The process moves into containers, but the cluster concepts stay the same: sticky routing, a shared central database, HTTPS between nodes and distributed task scheduling. Node settings reach the container through environment variables, mounted files or volumes, so the image tag and its configuration must be versioned together. Certificates are mounted into containers, and the container runtime determines how nodes reach the database and each other.
- Node configuration: Pin image tags per release and inject per-node settings at container start, keeping shared repository parameters in one source.
- Database connectivity: Confirm that container networking lets every node reach the external PostgreSQL server, and keep the database outside the application containers.
- Certificate trust: Mount the internal CA and node certificates as read-only volumes, and decide whether renewal triggers a container restart or a reload.
- Load balancer health checks: Align the container health probe with the load balancer probe so that an unhealthy container leaves rotation.
- Ownership: Your team owns image builds, registry access, volume storage, container hosts and image vulnerability scanning.
Confirm with Evolveum that the image you plan to use is documented for your target midPoint version and explains how it handles persistent state.
Container orchestration and air-gapped networks change assumptions about image sources, DNS, certificate issuance and health probing. Orchestrators add scheduling, service discovery and session affinity features, and those features must still provide the sticky routing midPoint requires. In an air-gapped network, images, packages and certificates arrive through an internal transfer process, so updates move on a slower and more controlled path. No pattern in this section should be treated as supported until it is verified.
- Node configuration: Decide whether nodes run as stateful workloads with stable identities, and confirm with Evolveum whether that layout is supported.
- Database connectivity: Keep the PostgreSQL server outside the cluster, or confirm how an operator-managed database fits midPoint's requirements.
- Certificate trust: Use the cluster's internal issuer or an offline CA, and confirm how node-to-node HTTPS trust is distributed and renewed.
- Load balancer health checks: Map ingress or service session affinity to midPoint's sticky requirement, then test node failover before go-live.
- Ownership: Your platform team owns the cluster, the internal image and package mirrors, the air-gap transfer process and the upgrade path, while your identity team owns midPoint configuration.
Confirm supported orchestration and air-gap patterns with Evolveum and your own platform team before committing to a design.
What drives the effort and cost of a midPoint cluster
This table lists the factors that change how much work a midPoint high availability design takes to build and run, and how to keep each one manageable. Read it before asking for a quote, because each driver maps to a line item that a fixed-scope proposal should spell out. The main takeaway is that standard node builds, one tested database runbook and automated health checks reduce effort more than any single infrastructure choice.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of nodes and environments | Each node needs its own configuration, patching, monitoring and upgrade step. Production, test and disaster recovery copies multiply that work and must match closely enough for failover tests to mean something. | Use one standard node build for every environment, managed with the same automation. Keep the test environment close to production in topology, even if it is smaller. |
| Database size and backup retention | The PostgreSQL repository holds identity, audit and task history. Larger volumes lengthen backups, restores and replication catch-up, and longer retention adds storage and restore testing. | Agree retention periods with compliance and audit owners before design. Define audit and history cleanup policies early and confirm the restore time you can accept with your own environment. |
| Connectors and scheduled reconciliation tasks | Every connector adds credentials, network paths and configuration to validate. Reconciliation tasks run on the cluster through Quartz, so their schedules, overlaps and load on target systems need planning across nodes. | Limit the initial connector set to systems in scope. Stagger reconciliation schedules, confirm which node runs each task, and monitor task durations and failures from the start. |
| Existing infrastructure: load balancers and PKI | A sticky HTTP load balancer, TLS certificates and internal certificate authority integration may already exist or may need new configuration. Gaps here often surface late in testing. | Inventory load balancer session stickiness, certificate issuance and trust chains before the design is fixed. Ask your network and PKI teams to confirm their change lead times. |
| Compliance evidence for backups and failover tests | Auditors and internal assurance teams usually expect documented backup jobs, restore results and failover test records. Producing this evidence repeatedly takes effort if it is done by hand. | Define the evidence list in advance, such as backup logs, restore test outcomes and failover test records. Automate collection where possible and store results in a location the assessors can access. |
| Team experience with PostgreSQL operations | Replication, failover, vacuum, backup tooling and upgrades all need skills the identity team may not hold. Limited experience usually shifts work to a partner or extends the learning period. | Assign a named database owner, document one tested runbook for failover and restore, and confirm which PostgreSQL skills are present internally before choosing who builds and operates the cluster. |
How to test that midPoint high availability works and fails safely
Start the test plan by proving the behaviors that users and auditors will notice first: sessions stay where they are placed, work survives a node restart, and every change reaches every node. Run these checks against a staging cluster that matches production in node count, load balancer configuration and PostgreSQL topology. First, confirm that the sticky HTTP load balancer keeps an administrator's session on one midPoint node for the whole session. Then restart that node while a multi-step change, such as a bulk assignment or a long-running import, is in progress, and confirm the work either completes or is recorded as interrupted with a clear status, with no silent partial results.
Next, verify cache invalidation across nodes. Make a configuration change on one node, such as an object template edit or a role definition update, and then read the same object through the other nodes. The change should be visible on every node within the window your design accepts. Repeat the check with a role assignment change that triggers provisioning, because a stale cache on one node can cause that node to make decisions against outdated configuration. Record the observed delay and the node logs that show invalidation messages being sent and received over the node-to-node channel.
Scheduled tasks need their own check. midPoint uses Quartz for distributed task scheduling, so confirm that each scheduled reconciliation, recomputation and certification task runs on exactly one node at a time. Review the task scheduling configuration, trigger a task manually, and inspect the task history for duplicate executions. Then stop the node that owns a running task and confirm that the task is either resumed on another node or marked for re-run according to the behavior you have documented. Ask your implementation partner or Evolveum to confirm the exact recovery behavior for the midPoint version you run, since it differs between releases.
Simulate the loss of one midPoint node under the load balancer health check. Stop the node's service or its container, confirm the health check removes it from rotation within the expected interval, and confirm that user requests succeed on the surviving node. Then observe provisioning. The expected safe behavior is that outbound provisioning to target systems pauses or queues rather than writing inconsistent data, and that tasks which cannot complete are reported as failed or suspended rather than silently dropped. If your tests show provisioning continuing with errors on a target system, treat that as a defect to fix before go-live.
Rehearse a PostgreSQL primary failover and a restore from backup as separate exercises. For failover, promote the standby using your chosen tooling, point midPoint at the new primary as your design specifies, and confirm that midPoint reconnects, that in-flight tasks are handled as in the earlier tests, and that no duplicate writes occur. For restore, restore the latest backup into a separate environment, start midPoint against it, and reconcile a sample of accounts against target systems. Time both exercises and record the results. Every test result, including failures and the steps taken to fix them, should be written up with date, tester, version and outcome. Keep these records as audit evidence, because they show an assessor that the availability design was tested and not only described.
Securing node traffic, the database and cluster secrets
A midPoint cluster adds network paths and shared credentials that a single node does not have. The controls below cover the database connection, traffic between nodes and the load balancer, and where secrets and configuration live. Each one is a decision your team should make and record before the cluster takes production load.
Database connection and repository credentials
midPoint keeps its state in a shared PostgreSQL repository, so every node holds credentials for that database. Give midPoint a dedicated database role with rights limited to its own schema, and encrypt the connection with TLS so credentials and identity data do not cross the network in clear text. Confirm the TLS mode that your PostgreSQL version and JDBC driver support, and agree how the password is rotated across all nodes in the same change window.
Database network access
Only midPoint nodes and the administrators who maintain them should reach the PostgreSQL port. Restrict this with firewall rules or security groups that allow the node addresses and nothing else, and keep the database on its own server, as the midPoint system requirements recommend. Test the rule from a host outside the cluster and record the result. Add backup agents and monitoring hosts to the allow list only after reviewing each one.
Node-to-node cache invalidation over TLS
Nodes tell each other to drop stale cached objects over HTTPS, so a node that accepts an unverified peer could receive or send changes that other nodes trust. Issue node certificates from an internal certificate authority that every node trusts, and confirm that hostnames match the certificate names. Keep peer certificate validation enabled during testing, and document how certificates are renewed before they expire.
TLS on load balancer traffic
Sticky load balancing sends each user session to the same node, so the balancer handles login traffic and session cookies. Decide where TLS ends: at the balancer only, or re-encrypted from the balancer to each node. Confirm that session cookies are marked secure and that the balancer passes the original client address in a forwarding header that midPoint accepts only from the balancer's own addresses. Verify these settings against the documentation for your midPoint version.
Connector and repository secrets
Connector credentials for target systems and the repository password should not sit as plain values in configuration files that are copied between nodes or stored in version control. Decide how each secret is supplied at runtime, such as environment variables or a secrets manager your team already operates, and confirm which mechanisms your midPoint version reads. Keep a register of which secrets each node needs so that rotation does not miss one.
Who can change node configuration
A change to one node's configuration can alter how the cluster authenticates, reaches the database or schedules tasks. Limit write access to the midPoint home directory and the deployment pipeline to a small named group, route every change through review, and check that all nodes end up with identical configuration after each change. Log access to the hosts themselves. Administrator authorizations and audit trail settings belong to the wider security hardening work for midPoint.
What to monitor, back up and document after the cluster goes live
Once the midPoint cluster is serving traffic, the operating routine decides whether high availability actually holds. Start with health checks at two levels: each midPoint node should be checked individually, and the load balancer should be checked for the pool membership it believes is healthy. A node that is up but has dropped out of the pool, or a pool that still routes to a node that is failing, both look fine from a single dashboard. Watch the HTTP response behavior of each node, JVM memory and garbage collection pressure, and the thread and error logs, and confirm that the sticky session settings still send a user's requests to the same node after a failover event.
The shared PostgreSQL database is the component most likely to become the bottleneck or the single point of failure, so monitor it as its own service. Track the number of open connections from each node against the connection limit you configured, because a leak or a pool that is too large will starve the cluster during peak provisioning runs. Track replication lag if you run a standby, since a failover to a lagging replica can lose recent identity changes. Track disk growth on the data and write-ahead log volumes. Ask your database team to confirm the alert thresholds and who receives them, and make sure the midPoint operations team can see the same metrics.
Scheduled tasks need a specific check. Quartz coordinates distributed tasks through the shared database, so after any node restart, confirm that each scheduled task runs on exactly one node and that none has been silently paused or duplicated. Review the task list and recent run history in the midPoint administration interface after planned restarts and after simulated node loss during testing. Duplicate runs of a reconciliation or a provisioning task can write the same change twice, so treat a duplicate as an incident, not a curiosity.
Backups need two things: a schedule and proof that restores work. Back up the PostgreSQL database on a schedule your recovery objectives support, and keep the backups in a location separate from the database hosts. Also back up the midPoint configuration directory and the keystore or secret material it depends on, because a database restore without the matching configuration and encryption material will not bring the system back. Run restore tests on a fixed calendar, restore into a separate environment, start a midPoint node against the restored data, and record how long each step took. Ask your team to confirm the retention period and who may approve a restore.
Upgrades in a cluster should be rolling, one node at a time, with the pool keeping the remaining nodes in service. Plan the timing around the release support dates. midPoint 4.9 support ends 18 October 2026, midPoint 4.10 is supported until 26 November 2027, and midPoint 4.8 (Curie) is a long-term support release with support until 17 October 2028. midPoint 4.11 is planned for 21 October 2026 as a feature release. Java changes need their own step: midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, so build a test node on the target Java version, run your configuration and connector checks there, and only then roll the change through production nodes. Confirm the Java version against the current system requirements before you commit. The handover set should contain a topology diagram showing nodes, load balancer, database and task placement; a node build standard covering OS, Java, midPoint version and configuration files; failover and restore runbooks with named owners; and the test evidence from failover, restore and upgrade rehearsals, kept with the change records your auditors will ask to see.
Questions buyers ask about midPoint high availability
How much more effort is a midPoint cluster than a single node?
A cluster takes noticeably more effort than a single node because the work spans several coordinated components instead of one application host. A single node needs an application server, a PostgreSQL repository and a backup routine. A multi-node setup adds a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and distributed task scheduling through Quartz. Each of these must be configured, tested and monitored together. Database high availability with tested failover adds more design and verification work. The size of the gap depends on your load, your existing load balancer and database standards, and how many environments you must replicate, so ask any provider to show the effort split in the quote.
Can our own team build a midPoint high availability cluster alone?
It can, if the team already runs Java applications, administers PostgreSQL and manages load balancers, and has time to test. The install itself is rarely the hard part. The harder work is confirming session stickiness under your load balancer, checking cache invalidation across nodes, observing how scheduled tasks behave when a node fails and proving that backups restore cleanly. Ask whether anyone has operated a multi-node midPoint cluster before and who will own it after go-live. Many teams use a partner for the first build, an independent review of the design or a set of failover drills, and a written scope lets you compare that option with building in-house.
What does a midPoint cluster need from our platform, database and network teams?
Your platform team provides Linux virtual machines or Docker hosts, sizing, configuration management, patch windows and the Java runtime. midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, so confirm the version you plan to run. Your database team provides a PostgreSQL server, ideally separate from the application nodes, with replication, failover, backup and restore procedures. Your network team provides the load balancer, TLS certificates, DNS, and firewall rules that allow node-to-node HTTPS for cache invalidation. Agree on named owners for each area before design starts, because gaps between these teams cause most delays.
How long does it take to reach a tested midPoint cluster?
The duration depends on your environment and the scope of work. The main factors are the number of nodes, how well your existing database and load balancer standards fit midPoint, how long your change approvals take, how many environments need the build, and how deep the testing goes. A fixed-scope quote defines the duration, deliverables and timeline in writing before work starts. Ask the provider to break the plan into design, non-production build, failover and backup tests, and handover. A tested state should mean that node loss, database failover and backup restore have each been demonstrated, not only that the nodes start. Review the assumptions behind any timeline as carefully as the timeline itself.
Do Evolveum subscriptions cover midPoint cluster setup and infrastructure?
No. Evolveum's Product Support subscriptions cover resolving midPoint product bugs, with an 8x5 next-business-day or 24x7 service level, and its Platform Subscriptions add feature development and roadmap influence. Neither includes building your infrastructure. Provisioning nodes, configuring the load balancer, setting up database replication and designing backups are separate work, delivered by your team, a partner or a contractor. Confirm the exact coverage with Evolveum in writing, and check the support subscriptions page for current terms. Budget for the subscription and the infrastructure build as separate lines so neither is assumed to cover the other.
What drives midPoint high availability cost up or down?
Cost comes from several sources: internal staff time, partner fees for scoped work, infrastructure such as virtual machines, database servers, storage and load balancers, and an Evolveum subscription if you choose one. Design, build and testing are mostly one-time costs. Infrastructure, subscriptions, patching, restore tests and on-call support recur. Costs rise with more environments, strict change control, an unfamiliar database high availability stack, multiple sites and custom monitoring. Costs fall when you reuse standard infrastructure templates, already run PostgreSQL high availability and settle requirements early. In a quote, ask for the components in scope, the environments covered, the test scenarios, the handover content and the items explicitly excluded.
Which midPoint release should a high availability cluster run on?
Choose the release by its support window and the Java version your platform team can run. According to the midPoint releases page, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028. midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.9 support ends on 18 October 2026. midPoint 4.11 (Čapek) is planned as a feature release for 21 October 2026. A cluster is harder to upgrade than a single node, so a release with a longer support window often reduces the number of cluster-wide upgrades you must test. Confirm the current status on the releases page before you commit to a version.
How DeployOpen scopes, builds and hands over midPoint clusters
DeployOpen plans, builds, hardens, documents and supports midPoint clusters inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Each engagement is fixed-scope, and the written scope fixes what the cluster includes before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- Written scope names the midPoint version, node layout, load balancer and PostgreSQL topology before work starts.
- Scope records where nodes run: Linux virtual machines or Docker images, in your own infrastructure.
- Failover, session, cache and task requirements are agreed up front, including which scheduled jobs must run on one node.
How we build
- Configure a sticky HTTP load balancer so each user session stays with the node that issued it.
- Point all nodes at one shared PostgreSQL repository on a separate database server, with connection settings verified.
- Verify node-to-node cache invalidation over HTTPS and Quartz-based task scheduling across nodes before go-live.
How we hand over
- Test node failure, load balancer failover and database switchover in a staging cluster, with results recorded.
- Document the topology, node configuration, backup and restore runbooks, and the failover procedure for your operators.
- Hand over backup and restore evidence, including a tested restore of the midPoint repository database.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Plan midPoint upgrades, including Java changes, against the release support dates Evolveum publishes for each line.
- Combine DeployOpen operations with an Evolveum Product Support subscription if your bug-fix requirements call for one.
