10 — The deployment kit (run your own)

Everything before this chapter runs the estate's own deployment. This chapter is for adopting the service as YOUR deployment — an estate's own status page on its own domain, or a page on a shared deployment — without copying anyone's config by hand.

The one command

npm run instance:new -- <name> [--base-url https://status.<name>.example]

scripts/instance-scaffold.ts emits instances/<name>/:

• config/status.yaml — the starter instance (two vantages declared, one example service to REPLACE). The kit validates the YAML through the ONE strict loader before writing anything: an emission that would not parse is refused, never shipped.
• wrangler.toml + wrangler.relay.toml + wrangler.relay2.toml — the worker manifests, names derived, the account id a PINNED placeholder (see the rule below).
• .github/workflows/ci.yml + deploy.yml — the three gates on every change; deploys DELIBERATE (a status-v* tag or a manual dispatch, never a branch push).
• CHECKLIST.md — the ordered operator acts.

The kit never overwrites: an existing instances/<name>/ refuses.

The rules baked into the checklist

They came from real incidents; the checklist repeats them because they are the ones skipped under time pressure:

1. Workers Paid first. A per-minute multi-vantage prober writes ~24k KV rows/day; the FREE plan's 1,000/day dies shortly after midnight UTC and every write path fails for the rest of the day (the 2026-09-08 incident, docs/manual/04).
2. Pin the account id in every manifest — a deploy must land on the account the domain attaches to, never a default-account theory (the 2026-09-12 lesson).
3. attach-custom-domain.sh --check before any production act — read-only, prints what the hostname attaches to today.
4. STATUS_RELAY_TOKEN is the SAME secret on the status worker and every relay — the report surface refuses anything else.
5. Every probe carries a content assertion — replace the example service with your real surfaces; a bare 200 never counts as up.

The shared-plane alternative

An estate need not deploy anything: register on the provisioning control plane and mount as a page on a shared deployment (docs/manual/07). The checklist carries the three bootstrap calls — org, page, and the page's OP client (POST /v1/pages/<slug>/op-client, docs/manual/06) whose emitted YAML arrives with admin.oidc real. Both postures are first-class: own deployment for the estates that want their own workers and domain; the shared plane for everyone else.

The two worked postures (the onboarding pattern)

• Own deployment: the kit; the estate's own account, domain, and identity issuer if it runs one (an estate with its own OP runs its own plane with that OP at OP_ISSUER — the Conormis posture, id.conormis.com).
• Shared plane: the bootstrap calls; the page mounts at /p/<slug>/ immediately and (with a binding) answers on its own host — the demo-tenant runbook (docs/manual/07) is the worked example.

Either way, adoption ends with the same honest service: worst-of vantages, the coverage column, human incident prose, and a board that means what it says.