Identify the exact image content.
A tag is convenient for people, but it can be moved. Pin the intended release to an image digest and verify the content you stage. Docker documents pulling an image by digest as a way to select an exact version of its content. Docker: pull an image by digest.
Also verify the architecture and acquisition path. A cached ARM64 image working on a developer’s machine does not establish that a new x86-64 customer host can acquire, verify and run the same application release. Test the intended environment and distribution route.
Inventory the state outside the image.
List named volumes, database services, application configuration and credentials. Docker volumes persist separately from a container’s writable layer; replacing a container does not itself give you a useful application backup. Docker’s volume documentation explains volume lifecycle and backup/restore mechanics. Docker: volumes.
For a database, use a consistency method appropriate to that database and application. Copying files while a service writes to them can produce an unusable snapshot. Define whether the application must stop, which services must be coordinated and how the snapshot will be verified.
Write a recovery plan that includes the data.
Reverting an image may fail after a database migration. Specify which application version can read the restored state, whether recovery discards writes made after the snapshot and who is allowed to make that decision.
Test recovery with synthetic but representative data. Verify recognizable records, permissions and application behavior after the restore. Merely proving that an archive exists or a container starts is not enough.
Check readiness before stopping anything.
- The intended host identity and application starting state match the plan.
- Verified image content is available for the destination architecture.
- Disk space covers staging, backup and expected growth.
- Configuration and required secrets are present without being exposed in logs.
- The backup can be inspected and its recovery key is available to the right person.
- The maintenance window and exact-plan approval are still valid.
Keep preflight checks read-only wherever possible. A failed prerequisite should be resolved before execution rather than discovered halfway through a destructive change.
Use a health check with a reason.
Choose a bounded check that represents useful application readiness. An open TCP port may show that a process is listening but say nothing about database access. A login page may load while the customer’s data is unavailable. Pair the automated check with application-specific acceptance evidence.
Define the timeout and failure behavior ahead of time. An unhealthy result should remain visible and lead to the documented response. Repeating the deployment until it looks green can erase evidence or repeat a migration.
Keep execution and recovery distinct.
Shipstead records signed, approved operations through a constrained broker workflow. It does not promise automatic rollback of arbitrary database migrations, zero downtime or support for every Compose file. The package contract and recovery procedure still need application-specific review.
Use the compatibility check to compare your application with the planned launch scope. Then use a disposable installation to prove the actual update and recovery path before involving customer production.