> 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/rpm/rpm-upgrade/minor-upgrade.md).

# Minor upgrade

A point upgrade inside your current release line — set two variables, run one command, with an offline route for hosts without internet access.

## What this is, and when you need it

A move to a later release **on the line you are already on** — 4.2.1.12 to 4.2.1.15, or 2026.6.2 to 2026.8.2. Nothing is added or replaced underneath the deployment: the same databases, the same infrastructure components, the same configuration.

The upgrade reads its target from `env.conf` and does the rest itself, so the whole procedure is two variables and one command.

{% hint style="warning" %}
**Check whether your target needs anything extra first.** A few 2026 releases add a database and a service, which the upgrade cannot create for you — and passing through one of them counts even if you are not stopping there. See [*Release-specific steps*](/installation/rpm/rpm-upgrade/release-specific-steps.md).
{% endhint %}

If you are crossing to a different release line — any 4.2.1.x to any 2026.x — read [*Major upgrade*](/installation/rpm/rpm-upgrade/major-upgrade.md) instead. That is a different shape of change, not a bigger version of this one.

## Before you begin

Take the backups and checks in [*Upgrading OpenIAM*](/installation/rpm/rpm-upgrade.md#before-any-upgrade) first. Then confirm these utilities are on the host, since the upgrade shells out to all four:

* `wget`
* `unzip`
* `tar`
* `curl`

**Find the Vault version that ships with your target release** before you start — the exact variables for every hop, on either line, are below.

## If you are on the 4.2.1 line

Each tab gives the variables for the **next** release from where you are. If you are more than one release behind, take one hop at a time — work through your tab, then repeat the procedure using the tab for the release you land on.

{% tabs %}
{% tab title="4.2.1.10" %}
Next release: **4.2.1.11**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="4.2.1.11"
```

{% endcode %}

No `VAULT_VERSION_UPGRADE` for this hop — Vault was not yet part of the upgrade.
{% endtab %}

{% tab title="4.2.1.11" %}
Next release: **4.2.1.12**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="4.2.1.12"
```

{% endcode %}

No `VAULT_VERSION_UPGRADE` for this hop either.
{% endtab %}

{% tab title="4.2.1.12" %}
Next release: **4.2.1.13** — the first release that upgrades Vault as part of the same run.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="4.2.1.13"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}
{% endtab %}

{% tab title="4.2.1.13" %}
Next release: **4.2.1.14**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="4.2.1.14"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}

{% hint style="warning" %}
**On an external database, land on 4.2.1.15 instead of 4.2.1.14.** The `upgrade.sh` shipped for this specific hop did not run its schema migration correctly against an external MySQL/MariaDB, MSSQL, Oracle or PostgreSQL instance — only the bundled local database was unaffected. 4.2.1.15's own procedure carries no such caveat, and going straight there needs nothing beyond the 4.2.1.14 tab's variables with the version numbers swapped. If you must land on 4.2.1.14 itself — an external database and a reason not to skip it — open a support case for the corrected script rather than the one this release shipped with.
{% endhint %}
{% endtab %}

{% tab title="4.2.1.14" %}
Next release: **4.2.1.15**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="4.2.1.15"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}
{% endtab %}

{% tab title="4.2.1.15" %}
**This is the newest maintained release on the 4.2.1 line.** No later point release is currently documented. When one ships, use its own variables from the release notes with the procedure below.

If you want to leave the 4.2.1 line rather than wait for the next point release on it, see [*Major upgrade*](/installation/rpm/rpm-upgrade/major-upgrade.md) instead.
{% endtab %}
{% endtabs %}

## If you are on the 2026.x line

Same shape as above — the target version, plus a Vault version wherever the release you're moving to sets one. Vault has not moved since 4.2.1.13; every release through 2026.8.2 still pairs with `1.18.1`.

{% tabs %}
{% tab title="2026.6.2" %}
Next release: **2026.7.1**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="2026.7.1"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}

{% hint style="warning" %}
**This hop crosses the arrival of `pbac`.** Provision its database and deploy `pbac-manager` — see [*Release-specific steps*](/installation/rpm/rpm-upgrade/release-specific-steps.md) — before you run this upgrade, not after.
{% endhint %}
{% endtab %}

{% tab title="2026.7.1" %}
Next release: **2026.7.2**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="2026.7.2"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}

No database arrives on this hop.
{% endtab %}

{% tab title="2026.7.2" %}
Next release: **2026.8.2**.

{% code overflow="wrap" %}

```bash
export UPGRADE_TO_VERSION="2026.8.2"
export VAULT_VERSION_UPGRADE="1.18.1"
```

{% endcode %}

{% hint style="warning" %}
**This hop passes through 2026.8.1, where `privacy` arrives**, even though you are not stopping there. Provision its database and deploy `privacy-manager` — see [*Release-specific steps*](/installation/rpm/rpm-upgrade/release-specific-steps.md) — before you run this upgrade.
{% endhint %}
{% endtab %}

{% tab title="2026.8.2" %}
**This is the newest maintained release on the 2026 line covered here.** No later point release is currently documented. When one ships, use its own variables from the release notes with the procedure below.
{% endtab %}
{% endtabs %}

## Upgrade with internet access

{% stepper %}
{% step %}

### Set the target version

Open the environment file:

{% code overflow="wrap" %}

```bash
vi /usr/local/openiam/env.conf
```

{% endcode %}

Set the variables from your tab above. The Vault version moves with the release, so on a hop that includes one, changing only `UPGRADE_TO_VERSION` leaves the secret store behind.
{% endstep %}

{% step %}

### Run the upgrade

{% code overflow="wrap" %}

```bash
openiam-cli upgrade
```

{% endcode %}
{% endstep %}
{% endstepper %}

## Upgrade without internet access

Same two variables, but you stage the artifacts yourself first. Substitute your target release for `<version>`, and the Vault version from its release notes for `<vault-version>`.

{% stepper %}
{% step %}

### Set the target version

As above — `UPGRADE_TO_VERSION` and `VAULT_VERSION_UPGRADE` in `/usr/local/openiam/env.conf`.
{% endstep %}

{% step %}

### Download the artifacts to `/usr/src/`

{% code overflow="wrap" %}

```bash
cd /usr/src/

wget -P /usr/src/ https://releases.hashicorp.com/vault/<vault-version>/vault_<vault-version>_linux_amd64.zip

curl -o openiam-<version>.noarch.x86_64.rpm https://download.openiam.com/release/enterprise/<version>/rpm/openiam-<version>.noarch.x86_64.rpm

wget https://download.openiam.com/release/enterprise/<version>/binaries/frontend.tar.gz

wget https://download.openiam.com/release/enterprise/<version>/binaries/backend.tar.gz
```

{% endcode %}

{% hint style="info" %}
**Short of space on `/`?** Stage the files on a partition that has room and update the script to match, rather than trying to free space under `/usr/src/`.
{% endhint %}
{% endstep %}

{% step %}

### Run the upgrade

{% code overflow="wrap" %}

```bash
openiam-cli upgrade
```

{% endcode %}
{% endstep %}
{% endstepper %}

## When it goes wrong

| Symptom                                              | Cause                                                        | Fix                                                                   |
| ---------------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------- |
| `openiam-cli upgrade` cannot find the upgrade script | The script is registered under a different name on this host | Check the path in `/bin/openiam-cli` and correct it before re-running |
| The upgrade completes but a connector stops working  | The connector predates the new release                       | Update the connector — see the note below                             |

{% hint style="warning" %}
**Update your connectors when you move to a newer release.** Every .NET and PowerShell connector from **5.24.0.0** onward is backward compatible with OpenIAM 4.2.0 and higher, so updating one will not disrupt an older deployment. Running the latest connector version is the recommendation regardless.
{% endhint %}

## Related

* [Upgrading OpenIAM](/installation/rpm/rpm-upgrade.md) — which kind of upgrade you are doing, and the pre-upgrade checks
* [Major upgrade](/installation/rpm/rpm-upgrade/major-upgrade.md) — crossing to a different release line
* [Commands](/installation/commands.md) — `openiam-cli` in full

*Last reviewed 9 September 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/installation/rpm/rpm-upgrade/minor-upgrade.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.