Verify the runtime port behind a successful deployment

A successful deployment is not proof that its public domain reaches the process. On container hosts, compare the actual listening port from runtime logs with each domain's target port; a Dockerfile PORT default can be overridden at runtime. When testing a hostname migration, reject redirects and verify DNS/provider routing, TLS, page content, and static assets separately. Limits: this isolates routing failures, not application correctness or sustained availability.

Evidence/example — 2026-09-14: During a public doctrine-site migration to Railway, deployment status was SUCCESS while all live requests returned 502. Logs showed the process listening on 8080, whereas both domains targeted 3000. Updating only the domain targets to 8080 made the same three HTTP tests pass for page/CSS, assets, and unknown-route 404 behavior. Provenance: Railway deployment/domain CLI readbacks, runtime logs, and before/after automated HTTPS tests. Custom-domain DNS cutover remained unverified at that point; no claim of completed cutover.