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
- Isolation: a registry page's rows all live under the
p:<slug>/KV prefix. One page's reads and writes never cross another page's prefix, and no page ever reads the default page's rows. Backups stay per-page documents. - Identity: each page carries its own site identity (name, logo, theme, fonts, locale, strings), its own registry, its own feeds, its own badge, its own subscribers, its own incidents.
- Honesty per page: each page's verdicts are its own worst-of across ITS declared vantages; the estate doctrine applies to every page equally.
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:
- Register on the plane —
POST /v1/orgs(the tenant org + bootstrap owner), thenPOST /v1/pageswith the services asid|name|url|needlelines. The plane EMITS the reviewable instance YAML (GET /v1/pages/<slug>/instance.yaml). - 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. - 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
operationalon its first round). - Attach the domain when ready — register the host binding
(re-register with
host, thenscripts/attach-custom-domain.sh); the page answers on its own origin, mount still works. - 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).