> 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.md).

# Deployment architecture, scale and environments

The deployment decisions that come before anyone builds anything — which of the nine shipped topologies fits, what your cloud platform will and will not run for you, where the network boundaries fall,

## What this is, and when you need it

Part 7 answers the questions an infrastructure owner asks once the identity design is settled: **how many machines, of what size, running which components, on what platform, and how many copies of the whole thing?** These are decisions, not procedures. This part holds the catalogue of shapes OpenIAM ships and the criteria that pick one of them; the Installation Guide holds how to build the one you chose.

The decision belongs jointly to whoever owns the infrastructure budget, whoever owns the availability target, and the identity lead — because the thing that most often moves a design up a size is not the user population, it is the batch work the identity design implies. Settle Part 2 before you commit to a topology, or you will size for the wrong workload.

Part 1, *Deployment shapes at a glance* is the one-page orientation across the three families. This part is the detail underneath it: nine named topologies, the per-platform infrastructure matrix, where connector processes physically sit, what actually drives load, what availability each shape buys, and how many environments the programme needs.

## The decisions in this part

| Decision                                                                           | Where it is made                                                                                             | What it turns on                                                                                                                                            |
| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Which of the nine shipped topologies to build                                      | [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md)                              | Availability target first, batch profile second — population enters through the database connection count and the search tier, not as a headcount threshold |
| Whether to deploy on packaged Linux, on Kubernetes, or on a managed cloud platform | [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md)                              | Whether you already run a container platform, and whether you are willing to operate stateful services                                                      |
| What each Linux-packaged shape actually looks like on the wire                     | [RPM topologies](/solution-architecture/deployment/rpm-topologies.md)                                        | Whether the infrastructure tier and the console tier are separated from the service tier                                                                    |
| Which components you hand to a cloud platform service                              | [Topologies using cloud platform services](/solution-architecture/deployment/platform-service-topologies.md) | What your platform has a shipped module for — which is not the same on all three clouds                                                                     |
| Whether Kubernetes buys you anything here                                          | [Kubernetes topologies](/solution-architecture/deployment/kubernetes-topologies.md)                          | Whether the organization already runs a cluster and a GitOps pipeline                                                                                       |
| What is managed and what is self-managed on AWS, Azure and Google Cloud            | [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md)                      | The shipped infrastructure modules — three gaps in that table change a design                                                                               |
| Where connector processes run, and what needs Windows                              | [Connector placement](/solution-architecture/integration/connector-placement.md)                             | Which managed systems the design integrates, and whether the targets are on-premise                                                                         |
| Where each component sits relative to your network boundaries                      | [Network zones and traffic flow](/solution-architecture/deployment/network-design.md)                        | What may be published, what must never be reachable, and which direction each connection is opened                                                          |
| How big each node has to be                                                        | [Sizing](/solution-architecture/deployment/sizing.md)                                                        | Concurrent sign-in, synchronization and reconciliation volume, and campaign scope                                                                           |
| Which components need headroom, and where more nodes will not help                 | [Where load lands](/solution-architecture/deployment/where-load-lands.md)                                    | Which workloads this estate actually runs, and which of them are cluster-serialised by design                                                               |
| What each shape survives, and what a backup must cover                             | [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md)                  | Your recovery time objective, and which components hold state that cannot be regenerated                                                                    |
| How many environments, and what moves between them                                 | [Environments and tenancy](/solution-architecture/deployment/environments-and-tenancy.md)                    | Whether configuration is rebuilt per environment — it is — and whether one deployment must serve several populations                                        |
| How this estate takes a new release                                                | [Taking a new release](/solution-architecture/deployment/upgrade-strategy.md)                                | Which upgrade path the substrate gives you, what downtime it costs, and who takes the backup that is your only rollback                                     |

## Start here

If you only read one page in this part, read [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md). It carries the catalogue and the thresholds, and every other page in Part 7 is an expansion of one column in it.

Two things are worth knowing before you open it, because they close off options people assume are open.

**There is no supported single-node production shape.** The smallest topology puts every service, every infrastructure component and optionally the database on one machine. It is a demonstration and development shape. Part 1, *The OpenIAM architecture* explains why: the relational database, the message broker and the cache are hard dependencies with no degraded mode, so a single node means every restart is a full outage of the identity service.

**What your cloud platform will run for you differs by cloud, and the difference is larger than most designs assume.** There is no Azure graph module, and no platform has a working managed search module. [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) states it plainly; discovering it after the architecture board has approved a "fully managed stateful tier" is expensive.

## What this part does not cover

Everything in Part 7 stops at the decision. Building the topology — provisioning, installing, configuring, upgrading, patching and tuning it — belongs to the **Installation Guide**, and every page here ends by handing off to it. Administering the running platform belongs to the **Administration Guide**.

## Related

* Part 1, *The OpenIAM architecture* — what each component holds and what its loss costs you.
* Part 1, *Deployment shapes at a glance* — the three families and the thresholds between them, in one page.
* The [Installation Guide](/installation/installation.md) — building, sizing in practice, upgrading and recovering 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/deployment.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.