Skip to content

Deploy verified immutable releases with staged checks and recovery - #16

Merged
tytremblay merged 1 commit into
mainfrom
codex/verified-releases
Oct 31, 2026
Merged

tytremblay merged 1 commit into
mainfrom
codex/verified-releases

Conversation

@tytremblay

@tytremblay tytremblay commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

Summary

verified app image → automatic release PR → reviewed digest manifest
  → exact suite revision → production approval
  → staged config checks → encrypted SQLite backup → apply → HTTPS verification → receipt

Companion app PRs: hawk-shop #27, hawk-mod #72, hawk-bot #59. All four PRs pass GitHub CI, including native x86 startup/upgrade checks and suite backup recovery.

Replace mutable production image selection and host hard resets with an exact release. Add per-image configuration validation, strict container/image checks, authenticated encrypted pre-migration snapshots, a review-only recovery helper and setup diagnostics. Replace retired hawk-mod configuration and fix the portal setup URL.

Evidence

  • Before: image selection used latest, the host fetched the newest main after approval, and preflight changed the active environment.
  • After: 12 deployment tests pass, including stale approval rejection, credential round-tripping, key preservation, rotatable bot credentials, failed pull isolation and failed-apply recovery records.
  • Real Docker integration passed SQLite snapshots for all three existing images, shop uploads, encryption, recovery integrity checks and tamper rejection. Shellcheck, actionlint, Compose fixture assertions and Python syntax checks pass.

Merge Danger

Door: two-way for the source change; database recovery after deployment requires schema review.

Blast Radius: production

This is a coordinated rollout. Merge this suite change first, configure the GitHub App and backup key, then merge the app changes and their three contract-v1 release proposals. The initial manifest records verified existing image digests as contract-0 baselines; the plan refuses them before requesting production approval. The host owner must re-run provisioning once to install the new root-owned JSON launcher. Existing keys and volumes are preserved. Production has not been deployed or modified.

See docs/continuous-deployment.md for the migration, reviewer settings and recovery procedure. Off-site backup copying and retention remain operational setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant