> 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/installation/scope-and-availability.md).

# Scope and availability

What this release of the guide covers, what each deployment shape protects against, and what is out of scope.

Read this before choosing a deployment shape. It states plainly what each shape survives, so that an availability requirement is met by design rather than by assumption.

## What this release covers

**This release covers single-zone deployments.** Every procedure here builds **one OpenIAM deployment**, in one availability zone or one data centre. **How many instances of each component that deployment runs is set by the shape you choose** — a single node runs one of each, a three-node deployment runs each clustered tier across all three hosts, and a Kubernetes deployment runs one of each unless the shipped configuration requires otherwise. That is a deliberate scope for this release.

| Covered in this release                                   | Covered in the [Solution Architecture and Design Guide](/solution-architecture/solution-architecture.md) |
| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| RPM single node, on your own infrastructure, AWS or Azure | Multi-zone placement                                                                                     |
| RPM three nodes in one zone                               | Multi-region and cross-site design                                                                       |
| Kubernetes on EKS, AKS, or a conformant cluster you run   | Running more than one instance of a component                                                            |
| One OpenIAM deployment per cluster                        | Disaster-recovery topologies and failover between sites                                                  |
| Managed databases on AWS and Azure                        | Sizing beyond the figures in *System requirements*                                                       |

The design guide is the right place for those conversations, and they are best had before the deployment is built rather than after.

**Two things sit outside this scope by their nature**, whichever shape you choose: the database's own availability, which is configured on your database platform, and the entry point — your load balancer or ingress. Both are arranged to your organisation's standards and are not changed by anything in this guide.

## What each shape survives

### RPM, single node

**Nothing.** Loss of the host means rebuilding it and restoring from backup. Choose this shape when that is acceptable, or when the host sits on infrastructure that provides recovery — a hypervisor cluster, a storage snapshot regime, or a documented rebuild procedure.

Recovery time is whatever your restore takes. Measure it — [*Back up and restore*](/installation/rpm/rpm-single-node/back-up-and-restore.md) tells you how.

### RPM, three nodes

**Designed to tolerate the loss of one application host.** Application services, message broker, cache, graph store, search tier and secret store are all clustered across the three hosts, and a majority of two out of three keeps each tier serving.

Three dependencies sit outside that guarantee and need their own arrangements:

<table><thead><tr><th width="180.39999389648438">Dependency</th><th>What it means</th></tr></thead><tbody><tr><td><strong>The database</strong></td><td>Whether external or clustered across the three hosts, its availability is arranged separately. A single database instance behind three application hosts is a single point of failure</td></tr><tr><td><strong>The load balancer</strong></td><td>Yours. If it is a single instance, it is a single point of failure</td></tr><tr><td><strong>Shared storage</strong></td><td>The three hosts share a filesystem exported from the first node. <strong>Loss of that node takes the shared filesystem with it</strong> — see below</td></tr></tbody></table>

**The shared-storage dependency is the significant one.** The cluster build exports three directories from the first node and mounts them on all three. The other two nodes tolerate losing either of their peers; losing the first node removes the shared configuration, upload area and secret-store certificates from every node at once.

Two ways to address it, both outside the installation procedure:

* **Provide the shared filesystem yourself**, from storage that is already resilient — a NAS, a clustered filesystem, or a cloud file service. Mount it at the three paths in [*The clustered tiers*](/installation/rpm/rpm-ha/form-the-clusters.md) on every node, and the dependency moves to infrastructure you already run.
* **Accept it**, and treat the first node as a component whose loss requires intervention. This is a reasonable choice for a deployment where the recovery procedure is understood and rehearsed.

**Do not describe this shape as having no single point of failure** unless the database, the load balancer and the shared filesystem have each been made resilient. [*Start and verify*](/installation/rpm/rpm-ha/start-and-verify.md) tests the loss of a node that is not the shared-storage host, and says so.

### Kubernetes

**The cluster provides the resilience, and the deployment runs one replica of each component.**

A worker node failure is handled by Kubernetes: pods are rescheduled onto surviving nodes. **Users will see an interruption while that happens** — the pod must be scheduled, the image may need pulling, volumes must detach and reattach, and the component must start and become ready. The same interruption applies during node maintenance, cluster upgrades and any rolling update.

That is the expected behaviour of a single-replica deployment, and it is appropriate for evaluation, development, test, and production where a few minutes of interruption is acceptable.

**Where a shorter interruption is required**, running more than one instance of a component is a sizing and architecture exercise. The [Solution Architecture and Design Guide](/solution-architecture/deployment/availability-and-recovery.md) covers it, and the deployment built here is the starting point for it rather than something that has to be rebuilt.

Two dependencies again sit outside the cluster: the **managed database**, whose availability is configured on the provider, and the **entry point** — your load balancer or ingress.

**Deploy into a single zone**, in line with this release's scope. If your cluster spans more than one, constrain the deployment's namespace to one of them with your cluster's usual scheduling controls.

## Reading availability claims in this guide

Where a page says a shape tolerates a failure, it means the platform's own components. It does not extend to the database, the load balancer, the shared filesystem or the cluster itself, each of which is configured for availability in its own right.

**If the requirement is that the service continues through the loss of a zone**, raise it before the deployment is built rather than after. It is an architecture conversation — this release's scope is single-zone, and the [Solution Architecture and Design Guide](/solution-architecture/solution-architecture.md) is where topology beyond that is worked out.

## Related

* [*Choose your route*](/installation/choose-your-route.md)
* [*System requirements*](/installation/system-requirements.md)
* The [Solution Architecture and Design Guide](/solution-architecture/solution-architecture.md) — topology selection and sizing

*Applies to OpenIAM 2026.8.1.*


---

# 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/installation/scope-and-availability.md?ask=<question>&goal=<user_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.