Operating midPoint in Production: Monitoring, HA, Backups, Upgrades, and the Support Chain

Operating midPoint in production means owning five things: monitoring that covers all layers of the deployment, backups that have actually been restored at least once, an availability design matched to real business needs, a disciplined upgrade cadence aligned with Evolveum’s release model, and a support chain where responsibilities are named and the escalation path to the vendor actually works. None of these are features you install. They are operational capabilities someone has to build and staff. This article describes what each one involves, based on how Evolveum documents the platform and on what we deliver when we operate midPoint for clients.

The gap between deployed and operated

A midPoint deployment that passed its acceptance tests is not yet an operated service. Acceptance tests prove the configuration works on a good day. Operations is everything that happens on the other days: the sync task that silently stops, the connector that starts timing out after a target system patch, the certificate that expires on a Saturday, the upgrade that has to happen because the version you run is approaching end of support.

The difference matters commercially too. An identity platform sits in the critical path of onboarding, offboarding, and access control. When it stops working, onboarding and offboarding can be delayed, access changes can stop propagating, and audit evidence can stop being produced. Whoever owns operations owns that risk.

The support issues we repeatedly see tend to fall into a few patterns: errors in recurring tasks such as live synchronization, reconciliation, and recomputation; connector failures toward particular target systems; and data or mapping problems triggered by edge cases that were not modeled during implementation. Almost never is the first symptom “midPoint is down.” It is “midPoint is running and something inside it quietly stopped doing its job,” which is exactly why the monitoring section below exists.

Environments: production alone is a choice nobody should make

Before monitoring or upgrades, the structural question: how many environments do you run? Evolveum itself recommends a three-environment model, and our position matches it. At minimum, production should be accompanied by a properly isolated testing environment that mirrors the production architecture, configuration, and data characteristics as closely as practical, while using test endpoints and appropriately anonymized or synthetic data wherever possible. A test instance with three dummy users and no integration endpoints tests nothing but the installer.

The best case is three environments with distinct jobs. Development is where configuration gets built and broken freely, on reduced or dummy data and simulated resources. Test is where changes meet production-representative data at production-like volume, against testing instances of the connected systems. Production is where nothing should ever happen for the first time. Isolation between them is part of the design: a test environment that can accidentally write into production target systems is a hazard, not a safety net.

Simulations make production changes safer, but they do not replace a testing environment. A simulation evaluates what a policy change would do. It does not test a binary upgrade, a Java or PostgreSQL change, a connector library update, a certificate rotation, or the behavior of a patched target application. Those changes still need somewhere to happen for the first time, and that somewhere should not be production.

Monitoring: four layers, not one dashboard

midPoint deployments fail at different layers, so monitoring has to watch all of them. In practice we think in four:

Infrastructure. Hosts, containers, network, storage, certificates. Standard tooling, nothing midPoint-specific, but certificate expiry deserves explicit mention because identity platforms are unusually full of TLS relationships: connectors, LDAP, HR feeds, the GUI itself.

Application and JVM. midPoint is a Java application, so heap usage, garbage collection behavior, and thread health are the early warning system for capacity problems. Sizing problems tend to show up here first, long before users notice.

Repository. For current midPoint versions (4.10 and later), PostgreSQL is the only supported repository database, which makes PostgreSQL health a first-class operational concern: connections, replication health where replicas exist, storage growth, vacuum behavior. Earlier supported branches such as 4.8 may still run the deprecated generic repository on other databases, but native PostgreSQL is the strategic direction, and a legacy repository is itself an upgrade-planning topic.

Identity operations. This is the layer generic monitoring misses. midPoint maintains detailed task statistics: synchronization progress, reconciliation results, errors per task. Operationally, the questions that matter are: is live synchronization keeping up with the source, are reconciliation tasks completing, are connector operations failing, and is anything accumulating in error states. A midPoint instance can look perfectly healthy at the infrastructure layer while provisioning has been failing for days. Alerting on task failures and synchronization lag is what closes that gap.

Our standard monitoring pattern is built on Prometheus and Grafana: node exporters on every host for the infrastructure layer, midPoint’s own actuator health and application metrics, and an external midPoint exporter we deploy that reads operational task state through supported interfaces and exposes it to Prometheus. That last piece is our implementation pattern rather than a native product capability, and it is what makes the identity operations layer visible on the same dashboards as everything else.

High availability: what clustering solves and what it does not

midPoint supports high availability through clustering: several midPoint nodes work as one instance over a shared repository, and a load balancer spreads GUI and REST traffic. Persistent tasks are resilient by default and can resume on surviving nodes after a node failure, although task behavior can be configured differently for cases where automatic restart is undesirable. The clustering setup is documented and works well when configured correctly, including the detail that every node sharing a repository must have clustering enabled, otherwise task scheduling misbehaves. One planning fact that surprises people: Evolveum supports clustering in production only for deployments with a valid subscription identifier from a paid subscription. HA is a subscriber capability, so the availability design and the support relationship get decided together, not separately.

The honest architectural point: clustering protects against node failure, which is only one failure class. In a clustered deployment, the shared repository becomes one of the most critical dependencies, so the availability design has to cover the database, not only the midPoint nodes. A two-node midPoint cluster in front of an unprotected single database has moved the single point of failure, not removed it.

For deployments where repository HA is justified, PostgreSQL should use an active-passive failover design with a connection mechanism supported by the target midPoint version. Evolveum’s current guidance favors PostgreSQL and JDBC-driver-level failover, and explicitly supports direct database connections rather than database proxies or SQL load balancers, which can alter the communication in unsupported ways. The exact topology should be validated against the midPoint version being deployed, not copied from a generic HA cookbook.

The other honest point: not every deployment needs a cluster. HA adds moving parts, and moving parts add operational load. The right question is not “can we cluster midPoint” but “what does the business actually lose per hour of identity platform downtime.” For some organizations the answer justifies full HA with database failover. For others, a well-tested restore procedure with a defined recovery time is the more rational design. Both are legitimate. Choosing without asking the question is not.

Backups: the restore is the deliverable

A complete midPoint backup strategy has four parts, and they are not equally well known.

The repository and audit. Standard PostgreSQL backup practice applies: regular base backups plus continuous archiving where recovery point objectives demand it, with the audit trail included in the scope. This is well-trodden ground for any database team.

Reproducible configuration. midPoint configuration lives as objects in the repository, but treating Git as the source of truth is what makes deployments reproducible: initial objects, resource definitions, role definitions, deployment descriptors. If the configuration exists only inside the running system, rebuilding after a serious failure means archaeology.

midpoint.home and the cryptographic material. The midPoint home directory holds what the repository does not: the initial configuration file, cryptographic keys, schema extensions, custom connectors, custom libraries, and localization. The single scariest file in it is the encryption keystore, by default keystore.jceks. Sensitive values in the repository are encrypted with keys that live in that keystore, not in the database. If the live database is lost but you have a valid repository backup and the required keystore, recovery is possible. If you retain the database backup but lose the encryption keys used by its encrypted values, those values may become unusable. A database backup without the encryption keys needed to decrypt it is not a complete midPoint backup.

The proof. A backup that has never been restored is an assumption, not a capability. Restore testing on a schedule, into a real environment, with the time measured, is the part most organizations skip and the part an auditor or an actual disaster eventually asks about. The measured restore time is also the only honest input for any recovery time commitment anyone makes to the business.

Upgrades: cadence is a decision, not an event

Evolveum currently follows roughly an annual feature-release cycle, a change from the older twice-yearly model that ended around midPoint 4.8. The recent sequence shows it: 4.9 in October 2024, 4.10 in November 2025, 4.11 planned for October 2026. LTS releases serve longer-lived deployments, with a direct upgrade path between LTS versions. That gives a deployment two rational strategies: follow the supported feature releases as they arrive, or stay on an LTS branch and plan the direct jump to the next LTS. midPoint 4.8 LTS is supported until 17 October 2028, and 4.12 is currently planned as the next LTS release, which means every 4.8 deployment already has a dateable upgrade project on its horizon whether it has scheduled one or not.

What a disciplined upgrade actually involves: reading the release notes for schema and behavior changes, verifying platform prerequisites early, checking connector compatibility against the target systems, running the upgrade in the test environment against production-representative data, using the verification tooling Evolveum provides to detect deprecated configuration before it breaks, and simulating policy behavior where simulation applies. The upgrade itself is usually the easy part. The preparation is the work.

Platform prerequisites deserve their own line because they are the most commonly missed class: the supported Java version, the PostgreSQL version, the repository implementation, connector versions, container image and runtime assumptions, and any custom libraries. midPoint 4.8 dropped support for Java 11 and PostgreSQL 13, and 4.10 removed the generic repository entirely. Sometimes the “midPoint upgrade” quietly contains an infrastructure upgrade that has to be planned and staged separately.

The upgrade tooling improved significantly around the 4.8 generation. The enhanced ninja-assisted upgrade procedure was introduced for 4.8 and backported to selected maintenance releases such as 4.4.6 and 4.7.2, and a supported direct LTS path exists from 4.4 to 4.8, provided the 4.4 deployment is first brought to at least 4.4.6. Older deployments therefore need to be assessed from their exact source version, repository implementation, and configuration state rather than classified simply as before or after some version line. Very old deployments can require intermediate upgrades, repository migration, or manual configuration remediation before the current tooling can do most of the work.

The anti-pattern we advise against is drift: skipping releases without choosing the LTS strategy, until the deployment is several versions behind with no tested path forward. At that point every upgrade is a project, and urgent fixes become genuinely painful.

The support chain: name the responsibilities before go-live

This is the part of operations most often left implicit, and Evolveum’s own model makes it explicit. In Evolveum’s support model, level 1 is end-user support, level 2 is solution-level troubleshooting of configuration, integration, and environment, and level 3 is product support: investigation and bugfixing of defects in midPoint itself, provided under subscription. Premium programs add level 4, which covers improvements and new feature development. Evolveum L3 is product support rather than a replacement for operating the deployed solution. Configuration and integration issues are primarily L2 responsibilities, although Evolveum may assist in diagnosis when it is unclear whether the underlying cause is a product defect.

The practical consequence: somebody on the deployment side has to genuinely run L1 and L2. Watching the alerts, diagnosing whether a problem is configuration, integration, data, or product, and when it truly is a product bug, producing the clean reproduction and evidence that makes the L3 escalation effective. A well-diagnosed escalation gets fixed dramatically faster than “midPoint is broken, please help.”

This is where our support offering sits: WeKnowIdentity provides specialist midPoint solution and operational support, corresponding primarily to L2 in Evolveum’s model, under an agreed SLA, typically with 8×5 coverage, with 24×7 coverage available where the business requires it. In practice that means monitoring response, diagnosis, and configuration-level and integration-level fixes, with managed escalation to Evolveum L3 when the root cause is a product defect, where the fix comes through the customer’s Evolveum subscription. We also build internal teams up to run this layer themselves.

The support line is also only one slice of a wider responsibility map, and the map needs names before go-live, not after the first incident. An identity platform touches more teams than any other system in the estate: every connected application needs a named owner who answers for its data and its access model, the HR and other source systems need owners who can fix wrong source data, system administrators own the infrastructure underneath, and IAM personnel own the policies and the platform itself. Who approves a policy change, who resolves a data dispute between HR and a target system, who is called for each class of incident: written down, with names, agreed by the people named. Without this, every incident starts with an ownership negotiation instead of a diagnosis, and the negotiation usually takes longer than the fix.

How to assess where you stand

Five questions, answerable this week, no tooling required:

1. When was your last restore test, did it include midpoint.home and the keystore, and how long did it take? If the answer is “never” or “unknown,” that is finding number one.
2. How would you learn that live synchronization stopped? If the answer involves a user complaining, monitoring has a gap at the identity operations layer.
3. What version are you on, and what is the support end date for it? If nobody can answer from memory, upgrade planning is reactive.
4. Who gets called when provisioning fails outside business hours, and do they have access and knowledge to act? A name, not a team alias that nobody watches.
5. Where is your configuration versioned, and could you rebuild the environment from it? If the running system is the only copy, treat that as a risk register entry.

What good looks like

As with data quality, there is no universal standard, but the shape of a well-operated midPoint deployment is recognizable. Treat these as examples to adapt:

• A properly isolated test environment mirrors production architecture, integration behavior, and data characteristics, using test endpoints and appropriately protected, anonymized, or synthetic data
• Responsibilities are written down with names: an owner for every connected application, owners for the authoritative sources, system administration, and IAM operations, agreed before go-live
• Monitoring covers all four layers, and task failures or synchronization lag raise an actionable alert to a human according to the agreed support coverage
• Restore has been tested on a schedule including midpoint.home and the keystore, and the measured recovery time is documented and accepted by the business
• The availability design matches a stated business requirement, not a default
• The deployment runs a supported version, and the path to the next one has an owner and a quarter attached
• L1 and L2 are explicitly staffed, internally or by a specialist, and the Evolveum escalation process, access, and responsible contacts are documented and validated

Frequently asked questions

Does midPoint support high availability?

Yes. midPoint clusters multiple nodes over a shared repository, distributes tasks across them, and supports load balancing for GUI and REST traffic. Production clustering requires an active Evolveum subscription, and the repository needs its own availability design using supported connection mechanisms, so a serious HA plan covers PostgreSQL failover, not only midPoint nodes.

How often should midPoint be upgraded?

Evolveum currently ships roughly one feature release per year, with sequential upgrade paths and direct paths between LTS releases. The two workable strategies are following supported feature releases as they arrive, or staying on an LTS branch and planning the jump to the next LTS well before support ends. Unplanned drift between versions is the option to avoid.

Can we run midPoint in production without an Evolveum subscription?

For a non-clustered deployment, yes: midPoint is open-source software and can be operated without a subscription. Production clustering, however, requires an active subscription. Without one you also do not have the contractual Evolveum L3 relationship for diagnosis, prioritized bugfixes, and supported backports. For a platform in the critical path of access control, most enterprises conclude the subscription is part of the operating cost.

What should monitoring alert on first?

Failed or suspended tasks, synchronization falling behind the source, connector errors toward target systems, and repository health. These catch the failures that generic infrastructure monitoring misses: the instance looks healthy while identity operations quietly stop.

Do we need Kubernetes to run midPoint properly?

No. Kubernetes standardizes deployment and recovery and pairs well with a GitOps approach, which is how we deploy where it fits, but it adds its own operational overhead and skills requirement. A well-run conventional deployment beats a poorly-run cluster. The deciding factor is your platform team’s existing capability, not fashion.

Talk through your operations

If some of the five assessment questions above have uncomfortable answers, that is normal, and it is fixable. We help enterprises operate midPoint: monitoring design, availability architecture, upgrade planning, and specialist solution and operational support under an agreed SLA, with managed escalation toward Evolveum. We also build internal teams up to run it themselves.

Discuss your midPoint operations

Related Resources

• midPoint on Kubernetes: A Production Deployment Guide
• Identity Data Quality Before Automation
• Our Implementation Methodology
• midPoint Consulting and Implementation Services
• Joiner-Mover-Leaver Automation Done Right

Sources

• Evolveum: High Availability. Clustering over a shared repository, task resilience, load balancing.
• Evolveum: Clustering / HA Setup. Configuration requirements, subscription requirement for production clustering.
• Evolveum: System Requirements. Environments, supported databases, HA guidance.
• Evolveum: Long-Term Support. LTS model, 4.8 support until October 2028, direct LTS paths.
• Evolveum: Support Guidelines. L1 to L4 support model, release cycle change after 4.8.
• Evolveum: Upgrade with Ninja. Ninja-assisted upgrade, verification, backports.
• Evolveum: MidPoint Home Directory. Location of configuration, cryptographic keys, connectors, extensions.
• Evolveum: Task Manager. Task statistics and scheduling.