Health & upgrades
A running OAP is a handful of platform components — the operator, authorization, channels, the web server, an
operator-managed SpiceDB, the messaging bus, and the memory stores. Two commands keep them honest:
oap check to see health, and re-running the install to upgrade.
Checking health
oap check verifies each component and reports ✓ / ⚠ / ✗ per one, so "is the platform healthy?" has a
concrete answer rather than a guess. oap check --watch keeps re-checking every couple of seconds — useful
while an install or upgrade is converging. It's the same readiness the install itself
waits on, available on demand.
Upgrading
An upgrade is a re-install: oap install applies the current platform manifests over the running one. The
apply is idempotent — an unchanged component is left alone, and only what actually differs is updated — so
re-running it is safe. The resolved cluster kind is stamped onto the components at install,
which is why upgrading a pre-cluster-kind install means re-running oap install so the kind is set explicitly.
oap install --builder-starters user:$(oap identity canonical-id you@example.com)
oap install needs either --builder-starters (who may start Agent Builder) or --without-builder; see
Agent Builder. The starter list replaces what was there, so pass the full list on every
upgrade.