Rollback

At Cloud-IAM, rollback is a native capability that restores your Keycloak deployment to a previous state using its most recent backup. It acts as a safety net for the critical Keycloak service, guaranteeing availability and accessibility when a recent change has introduced an error or unexpected behavior.

Rollback is a team-operated process. It is never performed in self-service from the console, and is only executed at the explicit request of the customer. No operator will ever roll back a deployment without express validation.

Overview

A rollback reuses the latest backup of your deployment, who is a full PostgreSQL database dump stored separately from the deployment environment. When triggered, it restores the entire Keycloak deployment to the state captured by that backup.

Because the operation replaces the current database with the contents of the last backup, it is powerful but not without consequences. Any action performed between the last backup and the moment of the rollback is permanently lost (see Data-loss impact).

Rollback is distinct from disaster recovery: both rely on backups, but they address different situations (see Rollback vs. disaster recovery).

When is a rollback used?

In practice, rollback is used almost exclusively after a change made to a healthy deployment turns out to be problematic. The two main cases are:

• After a version upgrade — A customer realizes that a Keycloak version upgrade has caused an error or unexpected behavior, and wants to return to the previous working state.
• After a custom extension issue — A custom extension has misbehaved and corrupted data, and the deployment needs to be restored to a clean state. In both cases, the customer raises a request with the Cloud-IAM support team, and our teams perform the operation.

How a rollback is triggered

Rollback is operated by the Cloud-IAM support team and can only be requested through the following channels, depending on availability:

• Support ticket — Submit a request through the Support Ticket Center during support availability.
• Trigger on-call — Customers with the on-call escalation option can request a rollback outside of standard support availability. Every rollback requires the explicit validation of the customer before it begins. No critical action is taken without your consent, in line with our RACI framework.

Duration of data loss

The size of this window and therefore the potential data loss depends directly on which backup is used as the restore point. That backup can come from:

• Your configured backup frequency — the automatic backups taken on the schedule you defined.
• A manual backup — taken by our support team before a critical operation.
• An automatic pre-operation backup — taken automatically by Cloud-IAM support before critical processes, typically a Keycloak version upgrade.

A higher backup frequency reduces the maximum amount of data that can be lost during a rollback. This is the same principle as the Recovery Point Objective (RPO) described in the Disaster Recovery documentation.

Rollback impact and data loss

A rollback is a one-way operation: once it has been performed, there is no way to undo it or to recover the data created between the last backup and the moment of the rollback. The previous database state replaces the current one entirely, and the data written in that window is gone for good.

For example, within that window:

• A user account created during this period will disappear.
• A password updated during this period will revert to its previous value.
• Any configuration change, new client, or role assignment made after the backup will be undone.

This is what makes a rollback fundamentally different from a routine recovery action: it is not a git revert that adds a new commit on top while keeping the history intact it is closer to a hard reset that discards everything written since the last backup. For most rollback situations this is exactly what you want, since the recent changes are precisely the ones that caused the problem but it does mean the decision has to be made with full awareness of the trade-off.

Considerations before performing a rollback

Before requesting a rollback, take a moment to weigh the two sides:

• What you gain — a stable, working deployment restored from a backup taken before the problematic change.
• What you lose — every user, password change, client, role, and configuration update written after that backup.

If recent activity in your deployment is significant for example, a wave of new user registrations or important configuration changes made after the last backup, please consider whether that data can be preserved or re-applied before proceeding. When in doubt, raise the question with the Cloud-IAM support team, who can help you assess the impact and confirm the restore point before any action is taken.

Rollback vs. disaster recovery

Rollback and disaster recovery both rely on Cloud-IAM cold backups, but they respond to fundamentally different situations.

	Rollback	Disaster recovery
Trigger	Voluntary a recent change caused an issue	Involuntary infrastructure or cloud provider outage
Typical cause	Faulty version upgrade or custom extension	Region or availability-zone failure
Goal	Return to a previous working state	Recreate an unavailable deployment
Source	Latest backup	Latest backup
Initiation	Explicit customer request	Cloud-IAM on-call team, with customer validation

In short, a disaster recovery reacts to an outage outside your control, while rollback is a deliberate step back from a change you made.