# 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](../assets/clean-host-deployment-audit.md).

The accepted single-host topology remains suitable. The route forward is now
explicit in these implementation tickets:

- [Provision a runnable non-root Hub service](10-provision-nonroot-service.md)
- [Package and verify cph with every Hub release](11-package-cph-with-release.md)
- [Make application releases atomic and rollbackable](12-atomic-releases-and-rollback.md)
- [Add real readiness and an accurate service lifecycle](13-real-readiness-and-lifecycle.md)
- [Establish migration compatibility and failed-migration recovery](14-migration-compatibility-and-recovery.md)
- [Test clean-host deployment and rollback on Linux](15-test-clean-host-deployments-on-linux.md)