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

# Minor upgrade

A point upgrade inside your current release line — set the version, check out the matching tag, and re-run the deployment.

## What this is, and when you need it

A move to a later release **on the line you are already on**. Nothing is added or replaced underneath the deployment: the same databases, the same components, the same charts.

Every release is deployed as an upgrade-or-install, so a minor upgrade is the ordinary deployment run again against a newer version. The schema migration runs as part of it.

{% hint style="warning" %}
**Check whether your target needs anything extra first.** A few 2026 releases add a database and a chart, which the deployment cannot create for you — and passing through one of them counts even if you are not stopping there. See [*Release-specific steps*](/installation/kubernetes/kubernetes-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/kubernetes/kubernetes-upgrade/major-upgrade.md) instead.

## Before you begin

Take the backups and checks in [*Upgrading OpenIAM*](/installation/kubernetes/kubernetes-upgrade.md#before-any-upgrade) first.

{% hint style="danger" %}
**Back up the database and the `secrets` secret before you start.** The migration alters schemas and cannot be undone by re-running the previous version.
{% endhint %}

## If you are on the 4.2.1 line

Every hop from 4.2.1.10 through 4.2.1.15 uses the same procedure below — set `OPENIAM_VERSION_NUMBER` to your target, check out the matching tag, and re-run the deployment. Unlike the RPM line, no version-specific manual step is documented for any of these hops.

## If you are on the 2026.x line

Each tab gives the target for the **next** release from where you are, and flags it when that hop crosses a database arrival — the deployment does not provision those for you. If you are more than one release behind, take one hop at a time.

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

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

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

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

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

{% 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/kubernetes/kubernetes-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 value from the release notes with the procedure below.
{% endtab %}
{% endtabs %}

## Upgrade

{% tabs %}
{% tab title="Helm" %}
{% stepper %}
{% step %}

### Carry your customisations forward

Commit your local customisations, then check out the tag of the deployment materials that matches your target release and merge them in. Confirm `env.sh` still contains your values afterwards.
{% endstep %}

{% step %}

### Set the release

Set `OPENIAM_VERSION_NUMBER` to the new release in **both** `env.sh` and `setup-no-tf.sh`. Changing only one leaves half the deployment on the old version.
{% endstep %}

{% step %}

### Re-run the deployment

{% code overflow="wrap" %}

```bash
./setup.sh
./setup-no-tf.sh
```

{% endcode %}

Each release is upgraded in place and the schema migration runs against the new version.
{% endstep %}
{% endstepper %}
{% endtab %}

{% tab title="Terraform" %}
{% stepper %}
{% step %}

### Carry your customisations forward

Commit your local customisations, then check out the tag of the deployment materials that matches your target release and merge them in. Confirm both `env.sh` and `terraform.tfvars` still contain your values.
{% endstep %}

{% step %}

### Clear the completed jobs

Jobs from the previous deployment block the new ones from being created:

{% code overflow="wrap" %}

```bash
kubectl delete jobs --all
```

{% endcode %}

{% hint style="warning" %}
**`--all` also removes the secret-store bootstrap and the broker's keystore generator**, which do not re-create themselves on a re-run. To restart only a failed migration, delete `flyway-job` by name instead.
{% endhint %}
{% endstep %}

{% step %}

### Re-run the deployment

{% code overflow="wrap" %}

```bash
./setup.sh
terraform init
terraform apply
```

{% endcode %}
{% endstep %}
{% endstepper %}
{% endtab %}
{% endtabs %}

## Verify

Every release should report `STATUS: deployed`. A release showing `failed` or `pending-upgrade` has not finished — see [*Verify a Kubernetes deployment*](/installation/kubernetes/verify.md) for the full check, and [*Troubleshoot*](/installation/kubernetes/troubleshoot.md) for what to do about it.

## Related

* [Upgrading OpenIAM](/installation/kubernetes/kubernetes-upgrade.md) — which kind of upgrade you are doing, and the pre-upgrade checks
* [Major upgrade](/installation/kubernetes/kubernetes-upgrade/major-upgrade.md) — crossing to a different release line
* [Deploy with Helm](/installation/kubernetes/deploy-with-helm.md) — the deployment run in full, including re-running it safely

*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/kubernetes/kubernetes-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.