Upgrade and rollback policy
Ethyca recommends and supports upgrading Fides one minor version at a time. Upgrading in sequence keeps a reliable recovery path available: you can always roll the application back to the previous minor version and run it against your existing database, with no database rollback required.
This page defines the officially supported upgrade and rollback policy for Fides.
The supported window
Fides releases are numbered MAJOR.MINOR.PATCH (for example, 2.88.0). This policy is defined in terms of minor versions — the middle number.
- Rollback is supported to the immediately preceding minor version (N-1). After you upgrade to a release, you can roll the Fides application back to the prior minor version and it will operate correctly against the already-upgraded database. No database rollback is required.
- Upgrade one minor version at a time. Ethyca recommends upgrading through each minor release in sequence. The rollback guarantee applies only when you upgrade one minor version at a time; skipping versions is not recommended, because it forgoes the guaranteed rollback path even if the upgrade itself succeeds.
- Patch releases are not separately bounded. Any patch release within a minor version (for example,
2.88.0through2.88.3) is covered by the same guarantee; you can move freely between patches of a supported minor version.
Example: If you upgrade from 2.88.x to 2.89.x and encounter a problem, you can roll the Fides application image back to 2.88.x against the same 2.89.x database and expect it to work — the database schema is left untouched.
Upgrading safely
Follow these recommendations to stay within the supported window:
- Upgrade minor-by-minor. Land on each intermediate minor release rather than jumping several minors at once. For example, to move from
2.86to2.89, upgrade to2.87, then2.88, then2.89. - Keep regular database snapshots. Maintaining recent database snapshots gives you a recovery path for any scenario that falls outside the supported rollback window.
- Review the release notes for the version you're moving to before upgrading.
The following table summarizes the rollback guarantee for each upgrade path:
| Upgrade path | Rollback guarantee | Recovery path |
|---|---|---|
| One minor version at a time (recommended) | Roll back to the previous minor version | Redeploy the previous minor version's image; database unchanged |
| Between patch releases of one minor version | Roll back to any patch of that minor version | Redeploy any patch of that minor version; database unchanged |
| Skipping multiple minor versions in a single jump (not recommended) | Not guaranteed | Restore the database from a snapshot |
Rolling back
Each Fides release is designed so the previous minor version continues to work against the upgraded database. This makes application rollback a safe, deployment-level recovery path: to recover from a failed upgrade, you change the application version — the same operation you use to deploy — and leave the database untouched.
When an upgrade to a new minor version goes wrong and you are within the supported window, roll back by redeploying the previous minor version's application image against the unchanged database:
- Redeploy the previous minor version. Set the Fides image tag back to the prior minor version (for example, from
2.89.xto2.88.x) and apply the change through your deployment tooling. - Leave the database untouched. Do not run a database downgrade. The upgraded schema remains compatible with the previous minor version's application.
- Verify the deployment. Confirm the pods are healthy at
https://your-fides-domain/health.
If you upgraded across more than one minor version in a single step, application rollback is not guaranteed. In that case, recover by restoring your database from a recent snapshot, and contact Ethyca support if you need assistance.
Next steps
- Review the release notes before every upgrade
- See the Production Kubernetes Deployment guide for
helm upgradedetails