Upgrade and Rollback

On ObjectOS Self-Managed, the image you run is pinned by digest, never by a tag, so an upgrade is a change of digest and a rollback is the previous one. Docker → Upgrade and rollback documents this procedure and the reason for each step; this page repeats it as a checklist.

Upgrade

1. Take the new digest from the release notes and read the image's release manifest before rolling it out: confirm the product major line is the one you are on, and check whether the embedded runtime's compatibility range moved. A runtime major-version move means breaking changes underneath — read that release's notes first.
2. Back up the database. Schema migrations are forward: rolling the image back does not roll the schema back.
3. Change the image digest and restart the stack. The migration runs to completion before new replicas take traffic.
4. Confirm readiness (/api/v1/ready) returns 200 and the replicas report healthy.

Roll back

Keep the previous digest: that is what a rollback is. To roll back, restore the previous digest and repeat step 3 — valid as long as the version you are leaving made no incompatible schema change (the release notes say when it did).

On Kubernetes and air-gapped sites

• Kubernetes — upgrading is the same change of image digest, with the migration Job running to completion before the new replicas serve. See Kubernetes → Rolling upgrades change the digest.
• Air-gapped — verify the new digest outside, transfer it in, change the pinned digest, restart. Keep the previous digest: inside an air-gapped network it may be the only copy you have to roll back to. See Air-gapped → Getting the image inside the network.

The app versions separately

The app itself, when it is delivered as a published artifact, versions independently of the image — see Deployment → How the app gets in. Treat published artifacts as immutable: if you overwrite one in place, you lose the ability to roll back cleanly even when the database backup is perfect (Backup → Artifact versioning).