Documentation
Clustering
Watchpost can run as an explicitly configured Raft cluster using the reusable Gantry Core replication runtime.
Shared Gantry runtime
Watchpost was the pathfinder for Gantry clustering. The generic authority/readiness state machine, durable Raft storage, production timing, mTLS transport, pairwise peer authentication, request identity, follower forwarding, applied-index waiting and bidirectional peer revocation now live in Gantry Core and are reusable by other Gantry products such as Trestle.
Watchpost semantic surface
Watchpost keeps product semantics in Watchpost: posts, post dependencies, rules and the dependency-graph revision are replicated semantic state. Monitoring history, observations and other node-local/runtime state are not made consensus state merely because the runtime is clustered.
Failure contract
ready leader -> propose through Raft
ready follower -> forward to current leader
no quorum -> reject writes
unhealthy -> reject writes
never -> fall back to local SQLMembership and security
Gantry pairing is not Raft membership. Replication voters are added explicitly. Production transport uses mTLS plus Gantry pairwise credentials and capability checks. A disabled or revoked peer is denied replication in both directions and can catch up after deliberate reauthorization.
Real-machine evidence
The reusable runtime was dogfooded on three independent Linode VMs across geographically separated regions. The campaign exercised leader loss, 2/3 quorum availability, 1/3 fail-closed behaviour, partition recovery, durable restart, snapshot plus trailing-log recovery, credential rotation, peer revocation, rolling upgrades and HTTP idempotency across leadership changes. Operational findings were fed back into Gantry Core before the runtime was treated as reusable.