# ToolHost — Deployment Profiles (E-HA-3)

*Anchor: project-docs/01-product-spec/02-capabilities-enterprise.md E-HA-1/E-HA-3;
00-FINAL-GOAL.md §8 item 8.*

## Three first-class supported shapes, one config schema

- **Single binary + local dev** — one process, SQLite-grade local store. Fastest path to try the
  product; not a production posture.
- **Docker Compose + Postgres** — the reference production shape today.
- **Kubernetes manifests** — the enterprise deployment shape.

The same declarative config schema is validated identically across all three profiles; the
differences between them are documented deltas, never separate code paths or separate schemas.

## The honest availability claim

[Anchor: 00-FINAL-GOAL.md §8 item 8] Deployment honesty holds: until the shared-store cutover
passes its conformance tests, the product claims **single-replica + fast restart, never HA**;
after it, the Kubernetes profile claims HA with per-replica skew and epoch-lag surfaces live.

**That cutover has not yet landed.** Listing a Kubernetes manifest as a supported shape is not the
same claim as multi-replica high availability — the two are decoupled on purpose. Today, running
the Kubernetes profile gets you the same single-replica-plus-fast-restart guarantee as the other
profiles, packaged for a Kubernetes operator's tooling; it does not yet get you a load-balanced
multi-replica deployment with shared rate-limit state, shared schema pins, and shared credential
storage all landed and conformance-tested together.

## What "fast restart" means concretely

A process restart re-reads its Generation from the shared config store and resumes serving; there
is no multi-minute warm-up and no manual reconciliation step. This is the honestly-claimed
resilience posture until the multi-replica cutover ships — restart, not redundancy.

## What changes when the cutover lands

Schema pins move to shared Postgres storage (a dual-path already exists), rate-limit state is
either shared or its per-replica semantics are explicitly documented, and the credential store
runs on Postgres with a stated migration/backfill procedure. Only once all three are true and
conformance-tested does the HA claim activate — and this page will say so plainly when it does,
not before.