Conormis status

The manual

Shared deployments: many pages, one deployment

One deployment of the status worker can serve N pages. The deployment's own compiled instance is the DEFAULT page (its layout is the unprefixed KV keys it always wrote — nothing migrates); every other page is a registry row resolved per request.

The guarantees

Registering a page

The page's instance YAML goes through the SAME strict loader the build gate uses — there is exactly one config contract:

curl -X POST https://status.example.test/api/pages \
  -H "authorization: Bearer $OPS_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"slug":"acme","host":"status.acme.test","yaml":"<the instance YAML>"}'

A page is reachable TWO ways: on its bound host (the custom domain; attach it with scripts/attach-custom-domain.sh) and — the moment it registers, domain or not — at the deployment's path mount /p/<slug>/… (the board, feeds, badge, summary, subscribe all serve under the mount; the internal links carry it). Re-registering bumps the revision; DELETE with the slug retires the page (it stops resolving and probing; its data rows stay for the backup posture — retirement is a state, never a delete).

The relays

A relay holds no KV: each round it fetches GET /api/pages (Bearer STATUS_RELAY_TOKEN) — every active page that declares it — probes each page's services, and reports per page (the report payload carries its page). A page with no relays declared is home-vantage only.

The shared-secret posture (named, honestly)

A registry page's probes run in the deployment's worker: any secretHeaders a page's services declare read the DEPLOYMENT's env (a shared deployment shares its secrets with its pages — the posture for trusted-tenant deployments). A tenant needing private secrets takes their own deployment (the whitelabel posture); there is deliberately no per-page secret store.

The quota ceiling (named, honestly)

One shared deployment's probe fan-out is the SUM of its pages' services x vantages, every minute, plus a KV write per service per page. The Workers Paid posture is a deployment prerequisite (docs/whitelabel.md); the page registry is the dial that turns it.

The v1 limit (documented, deliberate)

The operator surfaces (the admin console, the write API, /ops/drafts) drive the deployment's own DEFAULT page. A registry page is operated through this registry API and its own backups; org-wide membership administration across pages is the control plane's TODO-40 posture.

The worked example (the first tenant, run 2026-09-12)

The exact flow, executed for real against www.ribose.com:

  1. Register on the plane — POST /v1/orgs (the tenant org + bootstrap owner), then POST /v1/pages with the services as id|name|url|needle lines. The plane EMITS the reviewable instance YAML (GET /v1/pages/<slug>/instance.yaml).
  2. Register on the shared deployment — POST /api/pages (OPS_TOKEN) with the emitted YAML. The page is live IMMEDIATELY at /p/<slug>/ — board, feeds, badge, summary, reports — custom domain or not.
  3. The cron picks it up — the next round probes the page's services with its content assertions; the verdict renders (the demo's real probe of www.ribose.com read operational on its first round).
  4. Attach the domain when ready — register the host binding (re-register with host, then scripts/attach-custom-domain.sh); the page answers on its own origin, mount still works.
  5. Retire cleanly — DELETE /api/pages (the page stops resolving and probing; its rows stay for the backup posture) and {"retire":true} on the plane's page row (the registry keeps its honest bookkeeping).