Before you begin

Read this once before your first bring-up: it tells you who you need in the room, what to gather, and the order of the eight runbooks — so you don't get four steps in and discover you're missing a role, a key, or a cloud project.

Who does what

Bring-up is not a one-person job. The runbooks are written for an operator — the person who runs the live Directory day to day — but standing the system up from nothing needs two more hands: someone to provision the infrastructure, and someone to set up the certificate chain. A pure operator owns only the steady-state jobs: onboard, revoke, and rotate.

You cannot do bring-up solo

A new deployment needs three hats: a deployment engineer (provisions the machines and uploads secrets), a PKI / security engineer (builds the certificate chain), and an Admin (runs the Directory once it's live). On a small team one person may wear several hats — but the roles are distinct, and steps 1–4 below need the engineer and the PKI hat plus a cloud project, not just an operator login. If you only have an operator account, you can do onboarding, revocation, and key rotation — but you cannot stand up the PKI, the Directory, the servers, or the web client yourself.

Each runbook states its own "Who can do this". Here is the whole guide mapped to roles:

Task	Who
Set up the certificate chain (PKI)	PKI / security engineer (does the cert work) + Admin (ties it into the Directory)
Stand up the Directory	Deployment engineer (provisions the VM + runs the one-time /setup to mint the first Admin)
Add a server	Admin (registers the server in the Directory) + deployment engineer (stands up the box)
Stand up the web client	Deployment engineer (provisions the web VM; needs an Admin to mint the service token)
Onboard an operator	Admin
Onboard a device	Admin
Revoke a principal	Admin
Rotate keys	Admin

The pattern: the first four (PKI, Directory, servers, web) are deployment + PKI work and can't be done from an operator login alone. The last four (onboard / revoke / rotate) are pure Admin-in-the-dashboard jobs — that's the steady-state operator's world.

Prerequisites inventory

Everything the eight runbooks ask for, gathered in one place. Tick these off before you start step 1 — most of a failed bring-up is a missing item from this list.

• A cloud project (or host machines) and access to it. GCP project ID, and permission to provision in it. See the infrastructure repo.
• Access to the infrastructure repo. It holds the OpenTofu stacks for the Directory, servers, and web client, plus the secret-upload scripts.
• OpenTofu (tofu) and gcloud installed and authenticated on the machine you'll provision from.
• The global Terraform stack already applied (terraform/global/). The Directory's deploy service account is an output of that stack — the auth stack won't apply without it.
• One FIDO2 hardware security key per Admin. The admin UI accepts no other authentication method. The first Admin needs theirs at /setup; every operator you onboard needs their own.
• DNS control for the hostnames below. Caddy can't provision a TLS certificate until the hostname resolves to the static IP Terraform creates — so you need to add A records.
• Hostnames decided for the Directory, each server, and the web client (e.g. auth.…, relay-north.…, app.…).
• Your root-CA decision made — chain under your existing enterprise root, or stand up a standalone offline Bedrock root. This shapes the whole PKI step; see Set up the certificate chain.
• Coverage cells chosen for each server — the geohash-5 cells each relay will serve. Decide these before you register a server.
• Telesto AIS feed credentials (TELESTO_HOST, TELESTO_PORT, TELESTO_CLIENT_CERT_B64, TELESTO_CLIENT_KEY_B64, TELESTO_CA_CERT_B64) — only if you're standing up the web client; the web-demo stack requires them in Secret Manager before its first tofu apply. See Stand up the web client.

End-to-end checklist

The eight runbooks in deployment order. Work top to bottom — each step depends on the one before it. For the why behind the ordering, see Stand up a deployment.

• 1. Set up the certificate chain (PKI) — the trust anchor everything else checks. → Set up the certificate chain (PKI)
• 2. Stand up the Directory — the identity authority; mint the first Admin via /setup. → Stand up the Directory
• 3. Add your servers — bring up each relay and register it (gets its ServerToken). → Add a server
• 4. Stand up the web client — the browser entry-point, pointed at the Directory + a server. → Stand up the web client
• 5. Onboard your operators — give each person a login + FIDO key. → Onboard an operator
• 6. Onboard your devices — drones, sensors, feeds, APIs. → Onboard a device
• 7. (Ongoing) Revoke when needed — cut off a lost device or departing operator. → Revoke a principal
• 8. (Ongoing) Rotate keys — scheduled, or on suspected compromise. → Rotate keys

When steps 1–6 are done and the four checks in Stand up a deployment → How to know the deployment is up all hold, the deployment is live. Steps 7–8 are the steady-state operator jobs from then on.

See also

• Stand up a deployment — the master sequence, with the why.
• Operator training index — the full runbook list.
• System overview — the eight components and how they fit.
• The infrastructure repo — the cloud provisioning that underpins steps 1–4.

---

Verified against directory@e8287cd on 2026-06-07 — roles mapped from each runbook's "Who can do this" admonition; prerequisites consolidated from the runbooks' "Before you start" blocks (FIDO-only admin auth: directory app/middleware/admin_auth_middleware.ts + /setup flow; terraform/global/ + Telesto secrets: infrastructure repo).