You’re right. Currently, env-preflight is a separate command; recreating the container doesn’t automatically run it. We have startup guards and health checks, but an older image can still pass its own older checks. So the post describes a useful diagnostic, not a fully closed deployment loop. The missing piece is making deployment success depend on verifying what actually started against the intended release, with both drift and inability to verify treated as failures. That expectation needs to come from outside the image being checked; otherwise an old image can keep certifying itself. Your comment points out a gap we haven’t closed yet. We will fix this right away!

I’ve now wired it into Compose’s post_start hook, so container recreation runs preflight automatically and up -d fails if verification fails or can’t complete. The verifier and reference files come from the checkout, so an old image can’t silently use its own old checks. Diagnostics go into the container logs. I tested this with stale builds, missing programs, unreadable bundles, API failures, and startup timeouts.