A tag is a moving reference
Docker documents that image tags can be changed by their publisher, while a digest identifies a particular image. For an edge application, record the digest used in a successful deployment alongside its readable tag. That gives a later investigation a concrete starting point. The surrounding release record should still identify the model, application configuration and host software: an image identifier cannot describe everything the device uses, especially when hardware drivers or external data come from elsewhere.
Define the host boundary
List what the container expects from Linux: device access, mounted directories, permissions and any vendor runtime integration. Treat these as installation requirements, not details left in an interactive shell history. A replacement board should be able to expose the same resources using documented setup. This also helps explain failures: an application image can remain identical while a host update changes a dependency it reaches across the container boundary. Reproduction starts by identifying both sides of that boundary.
Keep building and running separate
Docker’s multi-stage build guidance provides a way to separate build tools from the final runtime image. Use that separation to make the deployed contents easier to account for, then verify the actual application rather than assuming that a smaller image is automatically sufficient. Keep the conversion recipe and generated artifacts available outside an ephemeral development session. If rebuilding requires an undocumented package or a manually copied library, the release is still tied to the original workstation.
Give the pinned image a successor
Pinning freezes a known reference; it also means newer fixes require an intentional update. Set a simple release procedure: build a candidate, run the retained workload, check hardware access and promote it only after the results are reviewed. Keep the previous release available until rollback has been exercised. This turns updates into named transitions between working configurations. It is more useful than choosing between an image that changes without notice and one whose maintenance stops after the first deployment.
Sources & publication notes
Retrospective period: May 2025. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.