Podman Image Versioning for Schema Change Rollback Safety

Short answer

Podman does not verify schema-rollback filesystem integrity automatically, and it does not guarantee read access to all layers of a previously tagged image merely because the tag existed. The precise verification mechanism is content-addressed digest comparison: record the image manifest digest before migration, confirm the rollback target resolves to the same digest and layer set, and treat persistent schema data as separate from image layers.

Confirmed behavior

• OCI image layers are immutable and content-addressed; a tag is a mutable pointer to a manifest digest.
• Reverting to an old tag gives the same filesystem only if the tag still resolves to the recorded digest and the layers have not been pruned, garbage-collected, or overwritten in the registry.
• Podman does not transactionally roll back data in container writable layers, named volumes, or bind mounts when you switch image tags.

Steps for this case

1. Before migration, record the digest: podman image inspect example/app:current --format '{{.Digest}}' and note any RepoDigests values in the full inspect output.
2. Deploy the schema-change image pinned by digest, for example example/app@sha256:old-digest, not a mutable tag.
3. On rollback, stop the new container, restore the pre-migration backup of any named volume, bind mount, or database, then start the old image by its recorded digest: podman run --rm --volume app-data:/data example/app@sha256:old-digest.
4. Verify the rollback target with podman image exists example/app@sha256:old-digest and podman image inspect example/app@sha256:old-digest --format '{{.Digest}}'; compare the digest to the pre-migration record.
5. For registry images, confirm read access before relying on rollback: podman pull --quiet example/app@sha256:old-digest on a staging host.

Verification

Compare digest strings, not tag names. If the digest or repository digests differ after retagging or pulling, the layer set is not the same baseline. A nonzero exit from podman image exists means the local reference is missing; do not assume an old tag remains readable after podman image prune or podman system prune.

Assumptions and uncertainty

Assumes Linux Podman with OCI-compatible storage or registry access. Exact inspect output and layer-path behavior vary by Podman version and storage driver; confirm field names in your environment. Layer readability is not guaranteed after garbage collection, prune, registry tag mutation, credential loss, or network failure. Mark exact inspect fields and overlay permission behavior for review in your target Podman version.

Missing diagnostic detail

Is the schema-change state stored in a named volume, bind mount, or external database, or only inside the container image or writable layer? This determines whether image rollback alone is sufficient or whether you must also restore the data backup.