feat(docker): restore failed Compose updates and retain recent releases

README.md

@@ -182,11 +182,42 @@ cron entry with the absolute path of **your** checkout; keep logs in its `logs`
 directory. Do not configure both CI and Compose updates for the same instance.
 The updater refuses an active `epicnext-cms-app` CI-managed container.
 
-Logs: `logs/docker-update.log`. A failure after recreation leaves the candidate
-running for diagnosis and returns nonzero; this Compose updater does not promise
-automatic application or database rollback. Persistent volumes are preserved.
-Before production migrations, retain your normal database backup. The existing
-CI deploy continues to restore its previous container on failed verification.
+Logs: `logs/docker-update.log`. After cutover, a startup, image or HTTP check
+failure automatically recreates the CMS with its previous image and verifies its
+local HTTP release and database health. The command still returns nonzero: a
+rollback is not a successful update. Recovery uses the current Compose configuration
+and `.env`; it restores application code, not configuration edits or database migrations.
+The previous image must carry a valid release label. First installations have no
+previous release: a failed candidate remains available for diagnosis. A failed
+rollback is explicitly logged with a retained `epicnext-cms:rollback-...` recovery tag.
+Public routing must be checked separately after rollback. SIGKILL or host power loss
+cannot run the rollback handler.
+
+After success, the updater keeps the two most recent distinct releases tracked in
+`logs/docker-release-history.log`. Cleanup only removes older recorded CMS image
+tags, without force; images referenced by other containers (including stopped ones)
+are preserved and retried on later updates. Untracked historical images, build cache,
+other services and persistent volumes are not pruned. Retain the history file between
+updates. Before production migrations, retain your normal database backup.
+
+### Shared prebuilt image audit
+
+The current Docker build is installation-specific. A shared registry image needs
+these changes before it can safely replace local builds:
+
+| Configuration | Current source | Required preparation |
+| --- | --- | --- |
+| Avatar imager URL | `src/lib/imager.ts`, direct `NEXT_PUBLIC_IMAGER_URL` access | Supply public runtime configuration; remove the Epicnabbo-specific fallback for other installations. |
+| Badge URL | Admin user badge components, `NEXT_PUBLIC_BADGE_URL` | Pass runtime configuration from the server to client components. |
+| Public application URL | Diagnostics and photo helpers, `NEXT_PUBLIC_APP_URL` fallback | Use server runtime `APP_URL`; audit any generated absolute URLs. |
+| Release identity | `next.config.ts`, `NEXT_PUBLIC_CMS_RELEASE` | Keep baked into the image: one commit identifies the same application binary everywhere. |
+| Environment validation | `src/env.ts` requires database URL, hotel name and production auth secret | Build with isolated fixture configuration, then validate each installation at startup. Do not publish production environment files or builder images. |
+| Build context | `.dockerignore` currently includes `.env`; Dockerfile copies the context into the builder | Separate build inputs from runtime secrets; inspect final image and build layers before registry publication. |
+
+This is a source audit, not a validated portable image. The next verification is to
+run the **same image digest** for two installations with different names, domains,
+imager/badge URLs and credentials, then check rendered pages and browser requests.
+The registry publishing workflow is intentionally not enabled yet.
 
 ### Diagnose an update that is not visible