What is the precise mechanism for safe configuration rollback in Ory upgrades

Direct answer

Ory does not inherently track previous configuration states, and it does not provide an atomic, versioned rollback point independent of your orchestration layer. During an upgrade, the active configuration file or database schema is replaced; prior states are not automatically preserved. A guaranteed rollback therefore requires you to redeploy the prior configuration artifact and restore the data store from a backup taken before the upgrade.

Confirmed behavior versus likely explanation

Item	Status
Native Ory versioned config store	Not present; upgrades replace active config
Built-in “down” migration for configuration	Not available; Ory CLI migration commands are generally forward-only
Rollback mechanism	External orchestration, such as Kubernetes or Helm, plus manual data-store restore
Artifact to redeploy	Pre-upgrade config.yaml or Helm values.yaml and the corresponding prior chart revision

Steps for this case

1. Before upgrading, back up the Ory data store (PostgreSQL, MySQL, or equivalent) and the active config.yaml or Helm values.yaml to version control.
2. If the upgrade fails, revert the deployment manifest to the previous revision, for example with helm rollback <release> <revision> or kubectl rollout undo deployment/ory-kratos. This restores the container image and manifest, but not necessarily Ory runtime data.
3. Restore the pre-upgrade data-store backup so identities, schemas, and session state match the older configuration.
4. Restart the Ory service and verify that prior feature flags, connection strings, and schema versions are active.

Assumptions and uncertainty

• This applies to self-managed Ory services such as Ory Kratos or Ory Hydra, not Ory Network, where rollback is managed by Ory.
• Behavior can change between Ory minor versions; verify the upgrade guide for your exact version before relying on these steps.
• Platform-level rollback does not guarantee Ory-level consistency if the data store has already migrated forward.

One missing diagnostic detail changes the exact command: which Ory service and deployment method are you using, for example Kratos on Helm or Hydra on raw Kubernetes manifests?

Verification

In a test cluster, perform the upgrade, then run the rollback commands above and compare the Ory admin UI and database state against the pre-upgrade baseline. Confirm that connection strings and feature flags match the earlier version.