> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/deployment/rpm-topologies.md). # RPM topologies The four packaged-Linux topologies — single instance, small HA, medium HA with distributed services, and large HA with a separated console tier — and what each one separates from what. ## What this is, and when you need it Four of OpenIAM's nine shipped topologies deploy the packaged Linux distribution onto virtual machines with no cloud platform services underneath. This page sets out what each of the four actually separates, and which separation is worth its cost in your estate. It is the right page when the organization runs virtual machines rather than containers, when managed services are not permitted, or when the deployment is on-premise. The decision is which of the four to build. It is made by whoever owns the virtual-machine estate, with the identity lead, because the threshold between the second and third shapes is set by the batch work the identity design implies rather than by anything the infrastructure team can see. ## The decision | Topology | What runs where | What it buys | What it costs | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **1. Single instance** | Every OpenIAM service, every console, every infrastructure component and the Linux connectors on one VM. The database may move to a second VM | The whole product on one machine. Fast to build, fast to destroy, easy to snapshot | No redundancy anywhere. Every restart is a full outage. Non-production only | | **2. Small HA** | Three identical nodes behind a load balancer, each running the full service set, the consoles and the infrastructure components clustered across the three. Database provided as a separate highly available service | Survives the loss of one node; lets you patch a node at a time | Three times the compute. The broker, cache, search tier and graph store are clustered across the same three nodes that serve interactive traffic | | **3. Medium HA with distributed services** | Three OpenIAM nodes running services and consoles; a separate three-node infrastructure cluster running the broker, cache and search tier | Bulk work no longer competes with sign-in for memory, disk and heap on the same machines | A second three-node cluster to build, monitor, patch and secure | | **4. Large HA with distributed services and UI** | Three console nodes; three service nodes; three infrastructure nodes | The interactive tier is isolated from the service tier and scales independently | Nine virtual machines before the database, and an ingress design that has to route to the right tier | All four run on Enterprise Linux. The packaged distribution builds dependency bundles for Enterprise Linux 9 and Enterprise Linux 10, which covers Red Hat Enterprise Linux, Rocky Linux and AlmaLinux at those major versions. ## What the packaging actually gives you Two properties of the Linux packaging shape every one of these topologies, and both are easy to miss from a diagram. **Each OpenIAM service is an independent systemd unit.** The ESB, the authorization service, the provisioning service, workflow, synchronization, reconciliation, the audit log service, the batch task service, the business rule service, certification, privacy, email, device, the Groovy service, the consoles, the identity provider and the report viewer each start, stop, restart and fail on their own. That is what makes topologies 3 and 4 possible at all: separating a tier is a matter of installing and enabling a different subset of units on a different set of machines, not of running a different build. **Connectors and source adapters are templated units, and there can be many of them per host.** A connector process is small — the shipped units cap each connector and each source adapter at a quarter of a gigabyte of heap — and they attach to the message broker rather than to the services, so they are not tied to the node that runs the ESB. In practice this means connector placement is a separate decision from topology, and it is covered in [Connector placement](/solution-architecture/integration/connector-placement.md). ## What the infrastructure cluster carries The separation in topology 3 is the important one, so it is worth being precise about what moves. The infrastructure tier is the broker, the cache, the search tier, and — when the graph runs self-managed — JanusGraph and the Cassandra store behind it. The packaged distribution's environment configuration carries a list of cluster member hosts for each of these independently: one list for the broker, one for the cache, one for the search tier, one for Cassandra, one for JanusGraph and one for the secrets store. Those lists exist precisely because these components are expected to be clustered across their own machines in the larger shapes, and they are what makes topology 3 a supported configuration rather than an improvisation. Three consequences follow. **Each of those components is clustered on its own terms.** Three OpenIAM nodes do not automatically give you a three-node broker, a three-node cache and a three-node search tier; each is a separate cluster with its own quorum, its own failure behaviour and its own patch cycle. In topology 2 those clusters happen to sit on the same three machines as the services, which is why topology 2 is the shape where a heavy synchronization is felt by everyone. **The search tier is the component most sensitive to being co-located.** It is disk-bound and heap-bound, it is written to by synchronization, reconciliation and audit at the same time, and it is read by every list screen in every console. When bulk work and interactive work share a node, the search tier is usually where the contention shows up first. **The secrets store is clustered separately as well.** It matters at service startup rather than continuously, which means its failure mode is a node that cannot restart rather than a platform that stops — but a three-node deployment with a single-node secrets store cannot restart a service while that node is down. ## Which separation to make, and in what order Both separations are worth making eventually in a large estate. The order is not negotiable, and doing them in the wrong order wastes money. **Separate the infrastructure tier first.** It removes contention between two genuinely different workloads — one that runs in bursts and saturates disk and heap, and one that must stay responsive every second of the working day. This is the separation that changes user-visible behaviour. **Separate the console tier second, and only for a reason.** Moving the consoles and the identity provider onto their own three nodes buys blast-radius isolation and independent scaling, not throughput. It is worth it when sign-in volume is high, when self-service is exposed to a wide population, or when a network zoning requirement puts the interactive tier in a different segment from the service tier. If none of those is true, the third cluster is three more machines to patch. The size difference between the tiers is real and asymmetric. The consoles, the identity provider and the report viewer together account for roughly half of the total heap the shipped units allocate on a single-instance deployment — each console runs with a generous ceiling because they render pages and hold sessions. The backend services collectively account for the other half. That is why the shipped console tier in topology 4 is specified with less CPU and less memory than the service tier, and it is a useful check on any sizing you are given: if a proposed console node is the same size as a proposed service node, one of the two is wrong. ## The search engine choice is real on Linux, and only on Linux The packaged Linux distribution can install either OpenSearch or Elasticsearch as the search tier, and the shipped environment configuration selects OpenSearch. The container deployment offers no such choice — OpenSearch is the only search chart that ships. Treat OpenSearch as the answer unless you have a specific reason not to. The Webconsole names the component as OpenSearch, the container path uses it exclusively, and an Elasticsearch installation puts you on a path the rest of the shipped material does not follow. A design document that says "Elasticsearch" without having made that choice deliberately has almost certainly copied it from an older diagram. ## What we recommend **Topology 2 is the smallest thing to call production.** Three nodes, a load balancer, and a database service made highly available separately. Present topology 1 as what it is — a development and demonstration shape — and resist any framing of it as a small production option. **Move to topology 3 when the batch profile justifies it, and prefer moving early over moving later.** Retro-fitting the separation onto a running production deployment means re-pointing every service at new broker, cache and search endpoints and rebuilding the search indices, which is a maintenance window you would rather not spend. **Do not build topology 4 speculatively.** It is the right answer for a large, high-sign-in-volume estate or for one with a hard network zoning boundary. It is the wrong answer as a default, because the third cluster's cost is permanent and its benefit is situational. **If you are in a cloud, compare against topology 6 before committing to any of these.** The packaged Linux shapes require you to operate the database, the cache, the search tier and the graph store yourself. Where a managed equivalent exists, taking it removes more operational load than any of these separations does — see [Topologies using cloud platform services](/solution-architecture/deployment/platform-service-topologies.md). The circumstance that changes this advice is an estate with no appetite for managed services and a small operations team. There, topology 2 with a well-run database service is a better outcome than topology 3 built by a team that cannot keep two clusters patched. ## What OpenIAM does not do here * **There is no supported two-node shape.** The shapes are one node or three; two nodes give you the cost of high availability without the quorum that makes the clustered infrastructure components work. * **Three OpenIAM nodes do not imply three of everything else.** The broker, the cache, the search tier, the graph and the secrets store each have to be clustered deliberately. * **The packaged distribution does not provision the load balancer or the database service.** Both are yours to supply in every one of these four shapes. * **There is no in-place move between topologies.** Separating the infrastructure or console tier is a re-deployment of those components, not a configuration change. * **The consoles cannot be scaled independently in topologies 1 to 3.** They run on the same units, on the same nodes, as the services. ## Related * [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md) — where these four sit among the nine, and the thresholds between them. * [Sizing](/solution-architecture/deployment/sizing.md) — how large each node has to be, and where the reference figures come from. * [Connector placement](/solution-architecture/integration/connector-placement.md) — where connector processes sit relative to these nodes. * *Configure platform services* in the Administration Guide — what the infrastructure components do for the administrator once they are running. * The [Installation Guide](/installation/installation.md) — installing the packaged distribution and clustering each component. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/deployment/rpm-topologies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.