Recommended procedure for upgrading Keycloak Operator and instances on OKD (v26.3.5 to v26.5.2) without OLM #45854

k0muc · 2026-01-29T10:40:24Z

k0muc
Jan 29, 2026

Hi Keycloak Community,

I am planning an upgrade of our Keycloak environment on OKD from v26.3.5 to v26.5.2 using the Keycloak Operator.

Context & Constraints: I am not using OLM (Operator Lifecycle Manager) for this specific installation. The reason is that we have multiple operators running in a single namespace. Since OLM's InstallPlan tends to bundle updates for all operators within the same namespace, it would force us to update other components simultaneously or manually disable/enable subscriptions for each operator every time—a workaround that adds significant overhead to our CI/CD. Therefore, we manage the Keycloak Operator manifests manually via kubectl/oc commands.

I would like to clarify the officially recommended manual procedure to ensure a safe database migration. Specifically:

Operator Upgrade Procedure: Since OLM is not an option, what is the preferred way to upgrade the Operator itself? Is it recommended to simply apply the new manifests over the existing installation, or is a "clean" approach (fully uninstalling the old Operator deployment while keeping CRDs/CRs, then installing the new version) preferred by the maintainers to avoid stale resource issues?
Upgrade Sequence: Does the team recommend upgrading the Operator to the target version (26.5.2) before updating the spec.image field in the Keycloak Custom Resource, or is there a different recommended order?
Update Strategy & DB Migration Safety: My current setup is moving across minor/patch versions (26.3.x to 26.5.x), which involves Liquibase schema changes. Will the Operator (using either Auto or the default RecreateOnImageChange strategy) strictly ensure that the old pods are terminated before the new version starts the migration? I want to ensure that no two versions are ever connected to the same database during the upgrade process to prevent schema corruption.

Any guidance on the "ideal" manual workflow for OKD from the developers' perspective would be greatly appreciated.

Thank you!

shawkins · 2026-01-29T14:18:44Z

shawkins
Jan 29, 2026
Collaborator

@k0muc we have an issue captured on this, but have not updated the docs: #40902

We haven't talked specifically about adding non-olm docs, but that certainly could be mentioned in the issue.

Is it recommended to simply apply the new manifests over the existing installation

Yes, there shouldn't be a problem doing that.

Upgrade Sequence: Does the team recommend upgrading the Operator to the target version (26.5.2) before updating the spec.image field in the Keycloak Custom Resource, or is there a different recommended order?

Currently I would recommend doing the spec.image first, then doing the operator upgrade. At least for minor and fix releases that should be straight-forward.

Update Strategy & DB Migration Safety: My current setup is moving across minor/patch versions (26.3.x to 26.5.x), which involves Liquibase schema changes. Will the Operator (using either Auto or the default RecreateOnImageChange strategy) strictly ensure that the old pods are terminated before the new version starts the migration? I want to ensure that no two versions are ever connected to the same database during the upgrade process to prevent schema corruption.

Yes, Auto (or RecreateOnImageChange) in this scenario will ensure that all pods are stopped before starting one with the new version.

0 replies

Navigation Menu

Repository navigation

Recommended procedure for upgrading Keycloak Operator and instances on OKD (v26.3.5 to v26.5.2) without OLM #45854

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Recommended procedure for upgrading Keycloak Operator and instances on OKD (v26.3.5 to v26.5.2) without OLM #45854

Uh oh!

k0muc Jan 29, 2026

Replies: 1 comment

Uh oh!

shawkins Jan 29, 2026 Collaborator

k0muc
Jan 29, 2026

shawkins
Jan 29, 2026
Collaborator