Back to all use cases

AssessmentSoftware / Digital Platforms

Prove the restore and the failover before the next Keycloak upgrade

Platform Engineering Team

Reviewing how Keycloak runs on Kubernetes with PostgreSQL, testing the failure and the restore, and writing the upgrade path from the current version.

Overview

A typical request: a platform team runs Keycloak on Kubernetes with PostgreSQL as the identity provider for internal applications and a message broker, several minors behind the current release. AceMQ delivers a written review and an upgrade path, scope and process, not a past result.

Challenge

Keycloak's upgrade guide says its database schema is not compatible with the old server after an upgrade and that database changes cannot be rolled back, so the only rollback is a restored backup that no one has tested. The team also cannot say what happens to token issuance for the broker when the database is slow or fails over.

Environment

Keycloak deployed with the Keycloak Operator on Kubernetes, a PostgreSQL primary with replicas, an ingress or load balancer in front and a message broker that authenticates clients with OAuth 2.0 tokens.

Approach

AceMQ reviews the topology against Keycloak's high-availability guide, the database settings and backup evidence, the Operator update approval and the token lifetimes the broker clients use. It then restores a backup to a copy, upgrades the copy through each minor on the path, reads the breaking changes for each against the team's realms, and tests token issuance and a broker connection against the result.

Solution

  1. Topology review against Keycloak's high-availability guide: single-cluster or multi-cluster, database replication and the load balancer
  2. Test restore of the database backup onto a copy, with the result recorded
  3. Breaking-changes list for every minor on the path from the current version to the target
  4. Rehearsal of the upgrade on the restored copy with the real clients and the broker pointed at it
  5. Token lifetime check against the broker's behavior when a token expires
  6. Operator update approval set to manual, and a runbook for patch releases and for minor upgrades

Outcome

The team receives a written review with ranked findings, a restore that has been proven on a copy, an upgrade path with its breaking changes and a rehearsal record, and a runbook for the next release. The team decides whether to run the upgrade itself, add 24/7 cover or move Keycloak to a managed service.

Technologies

KeycloakPostgreSQLKubernetesRabbitMQ
  • Consulting

    PostgreSQL High Availability and Failover Design

    Telecommunications OperatorTelecommunications

    Designing an automated failover architecture with quorum-based leader election, synchronous replication policy, and tested recovery procedures.

    PostgreSQLPatroniKubernetesetcdHAProxy
    Read case study: PostgreSQL High Availability and Failover Design
  • Consulting

    RabbitMQ Kubernetes Stabilization

    Smart Home Security PlatformCross-Industry

    Hardening RabbitMQ in Kubernetes environments with StatefulSet tuning, quorum queue optimization, storage isolation, and memory/network configuration.

    RabbitMQKubernetes
    Read case study: RabbitMQ Kubernetes Stabilization
  • Consulting

    Kubernetes Cluster-to-Cluster Migration with Stateful Workloads

    SaaS Platform TeamSoftware

    A typical engagement for a platform team that has to leave a Kubernetes version the project no longer patches: an inventory of what each namespace needs, a data-movement method for each broker and database, and a rehearsed cut-over to a new cluster, wave by wave.

    KubernetesRabbitMQPostgreSQLRedis
    Read case study: Kubernetes Cluster-to-Cluster Migration with Stateful Workloads
  • Assessment

    MuleSoft Integration Estate Assessment

    Regional Healthcare NetworkHealthcare

    Inventorying and evaluating a MuleSoft estate for reliability, error handling, and reuse before committing to either investment or migration.

    MuleSoftRabbitMQPostgreSQLKubernetes
    Read case study: MuleSoft Integration Estate Assessment
  • Managed Services

    Managed Apache Airflow in the Customer's Own Account

    SaaS Platform TeamSoftware

    What a Tier 3 managed Airflow engagement covers when a platform team wants Airflow run for it inside its own cloud account, with DAG ownership staying in-house.

    Apache AirflowKubernetesPostgreSQLCelery
    Read case study: Managed Apache Airflow in the Customer's Own Account
  • Assessment

    Argo CD Multi-Cluster Upgrade Window Assessment

    Platform Engineering TeamSoftware

    A typical engagement to check a fleet of Argo CD instances against the project's three-minor patch window and to plan the upgrade order, the rehearsal and the controller sizing for the instances that move.

    Argo CDGitOpsKubernetes
    Read case study: Argo CD Multi-Cluster Upgrade Window Assessment

Related Reading

Ready for a Keycloak Health Check?

AceMQ's senior Keycloak engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.