> 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/choosing-a-topology.md). # Choosing a topology The nine shipped OpenIAM topologies, what each one costs and buys, and what moves a design from one to the next — availability target first, batch profile second, and why population is not the thresho ## What this is, and when you need it OpenIAM ships nine deployment topologies across three substrates: packaged Linux, packaged Linux with cloud platform services, and Kubernetes. They are not nine points on a slider — they differ in what they survive, what they isolate, and how much of the stateful tier you operate. This page is the catalogue and the selection criteria: which shape, and why. You need this before the infrastructure budget is set and before the network design is frozen. Moving between topologies later is a re-deployment, not a configuration change, so the cost of choosing badly is paid twice. ## The decision Nine shapes, in the order they grow. The node counts are the shapes' defining property; the per-node figures are covered in [Sizing](/solution-architecture/deployment/sizing.md), where their provenance is stated honestly. | # | Topology | Nodes | What it buys | What it costs | | - | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | 1 | Single instance | One Linux VM; database optionally on a second | The whole product on one machine, fast to build and fast to rebuild | No availability whatever. Every restart and every patch is an outage. Non-production only | | 2 | Small HA | Three Linux nodes behind a load balancer, plus a highly available database service | Survives the loss of a node; patch without a window | Three times the compute, a load balancer, and infrastructure components that must themselves be clustered on the same three nodes | | 3 | Medium HA with distributed services | Three OpenIAM nodes plus a three-node infrastructure cluster carrying the broker, cache and search tier | Batch work stops competing with sign-in for memory and disk | A second cluster to build, monitor and patch | | 4 | Large HA with distributed services and UI | As #3, with the consoles and the identity provider on their own three nodes | Interactive experience decoupled from the service tier; the two scale independently | Nine nodes plus the database, and a more complicated ingress design | | 5 | Non-HA with platform services | One Linux VM; database, cache and graph store handed to managed services | The cheapest shape that keeps no durable state on the VM — the VM becomes rebuildable | Still no availability. The single node remains a single point of failure | | 6 | Medium HA with platform services | Three Linux nodes plus managed database, cache and graph store | Node-level availability with much less stateful operational load | Managed-service cost, and only the components your platform has a module for | | 7 | Large HA with platform and distributed services | Three console and reverse-proxy nodes, three service and infrastructure nodes, managed database, cache and graph store, and a link to on-premise connector hosts | The largest packaged-Linux shape; separates ingress, services and managed state | Most infrastructure, most cost, and a network design with a security review attached | | 8 | Kubernetes, non-production | One cluster, one worker node, with managed cache and database | Exercises the production manifests on a single worker | One worker means one replica of everything. Not an availability shape | | 9 | Kubernetes, production | One cluster, three worker nodes, with a managed graph store, managed cache and a highly available managed database | Three replicas of every workload, rolling upgrades, and a GitOps deployment path | A cluster, a registry and a pipeline to operate, and the same platform gaps as any cloud deployment | Topologies 1 to 4 use no cloud platform services. Topologies 5 to 7 substitute managed services for part of the stateful tier. Topologies 8 and 9 run the same product as container workloads. ## Choose on availability first The first question is not how many users you have. It is **what an outage of the identity service costs you**, because that answer removes six of the nine shapes immediately. **If OpenIAM is on the sign-in path for anything that matters, you need three nodes.** Topologies 1, 5 and 8 are single-node shapes with no redundancy anywhere, and OpenIAM's three hard dependencies — the relational database, the message broker and the cache — have no degraded mode, as Part 1, *The OpenIAM architecture* sets out. A single node is not a small production deployment; it is a development deployment that will eventually be treated as production by accident. The single-node shapes earn their place elsewhere. Topology 1 is what you build to demonstrate the product, to develop against, and to validate an upgrade before it touches an environment anyone uses. Topology 5 is the same thing on a cloud platform, and it is the better of the two for a long-lived development environment: with the database, cache and graph store outside the VM, the VM itself holds nothing you cannot recreate, so rebuilding it is cheap. Once you are at three nodes, availability stops being the discriminator and the remaining question is what to separate from what. ## Then choose on the batch profile, not the head-count The threshold that moves a design from topology 2 to topology 3 is contention, and the signal is what the identity design asks the platform to do in bulk rather than how many people it manages. Four workloads dominate: **Full synchronizations from an authoritative source.** A full run over a large HR extract or a large directory reads, transforms and matches every record. It is memory-hungry in the synchronization service and write-heavy against the database and the search tier. **Reconciliation against a large managed system.** Reconciliation pulls the target's whole population and compares it, so its cost tracks the size of the target, not the size of your OpenIAM population. An estate with several large directories will reconcile more data than it synchronizes. **Certification campaigns with wide scope.** A campaign that covers every user and every entitlement materialises a very large set of review line items in one operation, then keeps them hot for the duration of the campaign. **Bulk provisioning.** Birthright changes, role redesigns and decommissioning waves fan out to connectors through the broker, and the broker and the connector processes carry that load. When any of these is frequent, long, or has to complete inside a fixed window, separate the infrastructure tier. In topology 3 the broker, the cache and the search tier move onto their own three nodes so that a synchronization saturating the search tier does not slow the console for everybody else. That is the whole of the argument for topology 3, and it is a better one than any user count. The move from topology 3 to topology 4 is a different argument: **blast radius and independent scaling on the interactive side.** Putting the consoles and the identity provider on their own nodes means a service-tier problem does not take the sign-in experience with it, and it lets you add console capacity for a busy sign-in hour without adding service capacity you do not need. It is worth the extra three nodes when sign-in volume is high, when the consoles are exposed to a wide population through self-service, or when the interactive tier sits in a different network zone from the service tier. ## Where population size does come in Population matters, but it enters late and it enters through the database and the search tier rather than through node count. Two thresholds are worth naming. **The database is sized by service replicas, not by users.** OpenIAM's shipped deployment tooling provisions database connections as a multiple of the replica count of the ESB, workflow and authorization services — thirty-five connections per replica of each. Adding nodes therefore raises the database's connection requirement in a way that catches people out on managed database tiers with low connection caps. [Sizing](/solution-architecture/deployment/sizing.md) covers this, and it is the single most common cause of a managed database being provisioned too small. **The search tier is sized by object count and by audit volume.** Every user, group, role, resource, organization, managed system, orphan account and provisioning request is indexed, and so is every audit event. Audit volume in particular grows with activity rather than with population, and it is the part of the search tier that cannot be rebuilt from the database — see [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md). ## Choose the substrate separately Which family you are in is largely independent of which substrate you deploy on. | Substrate | Choose it when | Be aware | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Packaged Linux (topologies 1–4) | You have no container platform, or your operations function runs Linux VMs and would rather not learn one | Each OpenIAM service is a systemd unit and the infrastructure components are installed alongside them. Enterprise Linux 9 and 10 dependency bundles ship | | Packaged Linux with platform services (topologies 5–7) | You are in a cloud already and want the stateful tier operated for you | What you can hand away differs by cloud. See [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) | | Kubernetes (topologies 8–9) | The organization already runs clusters and a deployment pipeline, and OpenIAM would be one more tenant of an existing capability | Kubernetes is not an availability strategy on its own — the node count still is. OpenShift is supported and ships its own material | The substrate decision should be made on what your operations function already runs, not on what is modern. A team that runs Kubernetes well will find topology 9 cheaper to operate than topology 4. A team that does not will find it considerably more expensive, and will have added a platform to learn on top of an identity product to learn. ## How the shapes relate The relationship worth holding in your head is that the families are separations, applied in a fixed order, on top of a three-node base. ```mermaid flowchart LR A[Single node] --> B[Three nodes behind a load balancer] B --> C[Separate the infrastructure tier] C --> D[Separate the console tier] B --> E[Hand stateful components to platform services] E --> C ``` Read it as: availability comes first and is not optional for production; the infrastructure tier separates before the console tier does; and taking platform services is orthogonal — you can do it at any node count, and it removes work rather than adding a tier. ## What we recommend **Start every production conversation at three nodes.** Present topology 2 as the smallest production shape and topologies 1 and 5 as what they are: non-production. A design that offers a single node as a small-production option produces a platform that cannot be patched without an outage, and that constraint surfaces about six months after go-live. **Take topology 6 as the default in a cloud.** Three nodes with a managed database, managed cache and — where your platform has one — a managed graph store removes most of the stateful operational load for the least design complexity. Move to topology 7 only when you have a specific reason to separate ingress from services, such as a network zoning requirement. **Take topology 3 when the batch profile says so, not when the user count does.** Ask three questions: how large is the biggest full synchronization, how often does reconciliation run against the biggest directory, and is certification quarterly across the whole population. Two yes answers justify the separate infrastructure cluster. **Choose topology 9 only if you already run Kubernetes.** The shipped Kubernetes material is complete and current, and if a platform team already operates clusters it is the least incremental operational load of any shape. Adopting Kubernetes *for* OpenIAM is a different proposition and is rarely the cheapest path. **Decide connector placement now, with the topology.** Where connector processes run is a network and security decision, and in a cloud-hosted design it is the most common late surprise. See [Connector placement](/solution-architecture/integration/connector-placement.md). The circumstance that changes all of this is a regulatory or contractual constraint on where data may live. If managed services are not permitted, topologies 5 to 7 are unavailable regardless of their merits, and you are choosing between 2, 3, 4 and a self-managed Kubernetes deployment. ## What OpenIAM does not do here * **There is no supported single-node production topology.** The smallest shapes run every hard dependency on one machine; they do not remove any of them. * **The topologies are not a runtime scaling continuum.** Moving between them is a re-deployment. * **Kubernetes does not give you a separate infrastructure node pool.** The shipped cluster modules provision a single node pool whose size equals the replica count, so the topology 3 and 4 separations have no direct Kubernetes equivalent — see [Kubernetes topologies](/solution-architecture/deployment/kubernetes-topologies.md). * **No platform lets you hand away the message broker.** RabbitMQ, Vault and Consul are self-managed in every shipped topology on every platform. * **Tanzu is not part of the shipped material.** OpenShift is. ## Related * [RPM topologies](/solution-architecture/deployment/rpm-topologies.md), [Topologies using cloud platform services](/solution-architecture/deployment/platform-service-topologies.md) and [Kubernetes topologies](/solution-architecture/deployment/kubernetes-topologies.md) — the three catalogues in detail. * [Sizing](/solution-architecture/deployment/sizing.md) — what drives load, and how to read the reference numbers. * [Where load lands](/solution-architecture/deployment/where-load-lands.md) — which components feel which workload, and where more nodes will not help. * [Network zones and traffic flow](/solution-architecture/deployment/network-design.md) — the boundaries each of these shapes has to sit inside. * [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md) — what each shape survives. * *Where settings live* in the Administration Guide — the configuration layers that a re-deployment has to reproduce. * The [Installation Guide](/installation/installation.md) — building the topology you chose. *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/choosing-a-topology.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.