> 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/frame/deployment-shapes.md). # Deployment shapes at a glance The three families of OpenIAM deployment — single node, high availability, and high availability with distributed or managed services — and the thresholds that move a design from one to the next. ## What this is, and when you need it Once you know what OpenIAM is made of, the next question is how those components are laid out across machines. This page orients you across the three families that the shipped topologies fall into and names the thresholds that move a design from one family to the next. It is deliberately short: Part 7 holds the topology catalogue with node counts and sizing, the per-platform service mapping, connector placement and the availability and recovery decisions that follow. Read this to work out which part of that catalogue you are shopping in. The decision belongs to whoever owns the infrastructure budget and the availability target, and it is made jointly with the identity lead — because the thing that most often forces a move between families is not the user population, it is the batch work the design implies. ## The decision | Family | What it is | What it buys | What it costs | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Single node** | Every OpenIAM service, the infrastructure components and, optionally, the database on one machine | The cheapest thing that runs the whole product; fast to stand up and to rebuild | No availability at all. Any restart is an outage, and so is any patch. Not appropriate for production | | **High availability** | Three nodes behind a load balancer, each running the full service set, with the database made highly available separately | Survives the loss of a node and lets you patch without a window | Three times the compute, a load balancer, and an HA database — and shared infrastructure components that must themselves be clustered | | **HA with distributed or managed services** | Three service nodes plus either a separate infrastructure cluster or cloud platform services for the database, cache and graph store; at larger sizes the consoles move to their own nodes as well | Isolates the noisy stateful tier from the interactive tier, so a bulk synchronization stops competing with sign-in. Managed services remove most of the stateful operational load | The most infrastructure and the most cost. On some platforms, only part of the stateful tier can be handed away | ## The thresholds that move you between families **From single node to HA: any production use.** The single-node shape exists for demonstration, development and non-production validation. There is no degraded mode across the platform's three hard dependencies — the relational database, RabbitMQ and Redis, as [The OpenIAM architecture](/solution-architecture/frame/architecture.md) sets out — so a single node means every restart is an outage of the whole identity service. Sizing has nothing to do with it: a thousand-user production estate needs HA as much as a hundred-thousand-user one. **From HA to distributed services: contention between batch work and interactive work.** The signal is not the head-count on the HR feed, it is what the design asks the platform to do in bulk. Large full synchronizations, reconciliation across a big directory, certification campaigns that touch every user, and bulk provisioning all run in services that share nodes with the ones answering sign-in. When those runs are frequent, long, or must complete inside a fixed window, separate the infrastructure tier — broker, cache and search — onto its own cluster so the two workloads stop competing for the same memory and disk. **From distributed services to a separated console tier: sign-in volume and blast radius.** At the top end the consoles and the IdP application move onto their own nodes. That decouples the interactive experience from anything happening in the service tier and lets you scale the two independently. **Onto platform services: whenever your cloud offers them.** This is orthogonal to the three families — you can take managed components in a non-HA shape or a large HA one. What it changes is which stateful components you still run yourself, and that differs by platform in a way that catches people out. ## What your platform will and will not give you Established from the shipped infrastructure modules. This table is the one to check before you promise an architecture board a fully managed stateful tier. | Component | AWS | Azure | Google Cloud | Self-managed | | ------------------- | ----------------- | ---------------- | -------------------------------- | ------------------------- | | Relational database | Managed | Managed | Managed | Yes | | Redis | Managed | Managed | Managed | Yes | | Graph store | Managed (Neptune) | **No module** | JanusGraph over managed Bigtable | JanusGraph over Cassandra | | OpenSearch | **Self-managed** | **Self-managed** | **Self-managed** | Yes | Two consequences worth carrying into a design conversation. **On Azure, plan for a self-managed graph** — JanusGraph and the Cassandra cluster behind it are both deployed by Helm as in-cluster workloads, not a managed Cassandra service, so an Azure design carries a distributed database that an AWS one does not. **And plan for a self-managed search tier on every platform**: a managed search module exists in the shipped material for AWS but is not connected to the deployment, so on all three clouds you operate OpenSearch yourself. Google Cloud is fully supported and is easy to overlook, because it appears in neither the older topology material nor most of the reference diagrams. ## The substrates OpenIAM deploys three ways, and the family you choose is largely independent of which one you pick. **RPM on Enterprise Linux.** The packaged distribution builds against Enterprise Linux 9 and 10. Each OpenIAM service is a systemd unit, and the infrastructure components — Vault, Consul, JanusGraph, the broker, the cache, the search tier, Cassandra and the web tier — are installed alongside them. This is the substrate for the single-node and the pure-HA families, and it is the right choice for an estate with no container platform. **Kubernetes.** Each service is its own workload, deployed by Helm chart; the shipped GitOps manifests deploy the same set through Argo CD. The two documented Kubernetes shapes are a single-worker non-production cluster and a three-worker production cluster, both assuming managed database and cache. **OpenShift is supported** — its own charts and templates ship. **Tanzu is not present in the shipped material; do not promise it.** **Containers on a managed cloud platform.** The Terraform in the shipped infrastructure modules provisions the stateful tier per platform, as the table above sets out, and deploys the services onto the cluster. ## What we recommend **Assume three nodes for anything production, and start the conversation there.** The single-node shape is a non-production tool. Presenting it as a small-production option invites a design that cannot be patched. **Choose the family from the batch profile, not from the user count.** Ask what the largest synchronization will be, how often reconciliation runs across the biggest directory, and whether certification campaigns are quarterly across the whole population. Those answers move a design to distributed services far more often than head-count does. **Take every managed component your platform offers a module for**, and design every case around a self-managed search tier, and the Azure case around a self-managed graph and its Cassandra cluster, rather than discovering either late. **Decide connector placement at the same time as the topology, not afterwards.** Where connector processes run is a networking decision with a security review attached — some Microsoft integrations run as a remote connector hosted on Windows, and on-premise targets reached from a cloud deployment need a site-to-site link. Part 6 covers this; the cost of leaving it late is that it lands after the network design is frozen. ## What OpenIAM does not do here * **There is no supported single-node production shape.** The smallest shape runs everything on one machine, including the three hard dependencies, and any restart takes the platform down. * **The families are not a scaling continuum you slide along at run time.** Moving from one to the next is a re-deployment, not a configuration change. * **Tanzu is not shipped.** OpenShift is. * **A managed component is not always available.** See the platform table above before committing. In particular there is **no managed search option on any platform**, and no managed Cassandra behind the Azure graph — both run as workloads you operate. ## Related * [The OpenIAM architecture](/solution-architecture/frame/architecture.md) — what each component holds and what its loss costs you. * Part 7, *Deployment architecture, scale and environments* — the full topology catalogue, node counts and sizing, connector placement, and availability and recovery. * The [Installation Guide](/installation/installation.md) — building and operating the shape 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/frame/deployment-shapes.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.