1.6 KiB
Audit the clean-host deployment and rollback contract
Type: research Status: resolved
Question
What concrete defects prevent a clean, supported Linux host from installing, starting, health-checking, upgrading, and rolling back the current Hub without manual repository knowledge or unsafe partial deployment?
Answer
The current path is a happy-path updater for a manually prepared host, not a
production deployment mechanism. The executed audit found an unrunnable seeded
configuration, an unprovisioned service identity and storage, a missing cph
artifact, in-place mutation before build success, liveness-only verification,
no coordinated application/schema rollback, and a configured bind host that the
server ignores.
The complete evidence, operational consequences, required release invariants, and verification scenarios are recorded in the clean-host deployment and rollback audit.
The accepted single-host topology remains suitable. The route forward is now explicit in these implementation tickets:
- Provision a runnable non-root Hub service
- Package and verify cph with every Hub release
- Make application releases atomic and rollbackable
- Add real readiness and an accurate service lifecycle
- Establish migration compatibility and failed-migration recovery
- Test clean-host deployment and rollback on Linux