Upgrade automation orchestrator

Operator Lifecycle Manager (OLM) delivers operator upgrades automatically based on your channel subscription. Pin the operator to a specific version when you need to control exactly which version runs in production.

Before you begin

Verify which OLM channel your Subscription uses. The channel determines which versions are available. See Understand release channels.
Back up your PostgreSQL databases.
The automation orchestrator operator rejects downgrades. If you apply a lower version than the currently deployed version, the automation orchestrator operator sets ConfigurationValid=False and does not proceed. To roll back to a previous version, restore from a database backup.
For air-gapped environments, use platform-level registry mirroring (for example, oc-mirror with ImageContentSourcePolicy or ImageDigestMirrorSet).

About this task

OLM does not upgrade past the pinned version until you update or remove startingCSV.

Procedure

Set startingCSV in the OLM Subscription to the version you want to pin.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: automation-orchestrator-operator
  namespace: automation-orchestrator
spec:
  channel: stable
  name: automation-orchestrator-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: automation-orchestrator-operator.v2026.8.1785678543

Replace the startingCSV value with the version you want to pin.

Apply the updated Subscription.
```
$ oc apply -f subscription.yaml
```
Verify that the operator installs the pinned version.
```
$ oc get csv -n automation-orchestrator
```
Confirm that the ClusterServiceVersion name matches the version you specified and that its phase is Succeeded.

Results

Note:

To unpin and resume automatic upgrades, remove the startingCSV field and reapply the Subscription.

Understand automation orchestrator upgrades

The automation orchestrator operator manages upgrades through Operator Lifecycle Manager (OLM). OLM delivers new operator versions automatically based on your channel subscription.

Version upgrades

Version upgrades require planned downtime because all components must stop while the automation orchestrator operator applies database changes. The automation orchestrator operator performs the following steps automatically:

Scales all application deployments to zero replicas.
Runs database migrations.
Registers the Temporal namespace.
Deploys the new versions of all components.
Verifies health and sets the Ready condition.
Updates status.currentVersion after the full rollout completes.

You can skip intermediate versions when upgrading, for example from 2026.8 to 2026.11. The operator upgrades directly to the target version, running all intermediate database migrations in sequence. Upgrades that span many versions might take longer because more migrations run.

The operator rejects downgrades because each migration transforms the database schema irreversibly. To roll back to a previous version, restore from a database backup.

Configuration and scaling changes

When you change the custom resource without changing the version, the operator applies a rolling update with no downtime. The rolling update uses maxSurge: 25% and maxUnavailable: 25%. Up to 25% of pods can be temporarily unavailable during the rollout. Update spec.<component>.replicas in the custom resource to scale individual components.

Choose a channel for upgrades

Your OLM channel subscription determines which operator versions are available for upgrade. Only the stable channel supports in-place upgrades. The early-access channel does not support in-place upgrades. To move to a newer version on that channel, perform a fresh installation.

To change your channel, update the channel field in the OLM Subscription resource. Alternatively, use the --set automation-orchestrator-operator.channel=<channel> flag with aapctl.