What the UI does
The deployment details page opens an Upgrade Deployment dialog. The user enters a target version, and the UI calls:
with this body:
The Admin Server validates the requested version against the version catalog, checks that the cluster exists, rejects upgrades for clusters in Failed state, refuses versions older than the one the deployment runs (prereleases included: 4.22.0-rc1 is older than 4.22.0), and updates the cluster version. If it can’t determine which version a deployment runs, it refuses any version change rather than risk a downgrade.
FalkorDB upgrades are one-way. A newer version can write data that older versions can’t load; for example, FalkorDB 4.22.0 writes RDB encoding v20, which earlier releases can’t read. Take a backup and confirm it restores before you upgrade a deployment whose data matters.
Upgrade from Admin UI
- Open Deployments.
- Open the target deployment.
- Select Upgrade.
- Enter the target FalkorDB version, for example
v2.0.0 or another version shown by your version catalog.
- Select Confirm Upgrade.
The UI warns that the deployment will undergo a rolling restart and brief downtime may occur.
Validate
In the Admin UI, review General, Pods, Operations, and Events.
Failure handling
- If the version is invalid or unavailable, older than the version the deployment runs, or the running version can’t be determined, the backend returns a
400 response.
- If the cluster is not found, the backend returns a
404 response.
- If the cluster is in
Failed state, resolve the cluster condition before retrying.
Rolling back
There is no downgrade. Requesting an older FalkorDB version than a deployment runs is refused, because the older version may not be able to read the data the newer one wrote, and its pods would fail to start. To go back, restore a backup taken before the upgrade into a deployment on the older version.
