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 access to the rack.

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 rack access, 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.

Host machines and access to them. On the PETRA rack, the three boxes installed, on one switch, and reachable. See the infrastructure repo.
Access to the infrastructure repo. It holds the Ansible that provisions the Directory, the routers, the web client and the media/tile servers.
A set-up controller. Clone that repo, gcloud auth login, then run bin/bootstrap-controller.sh — it puts the vault password on your laptop and generates the SSH key the rack authenticates you by. Your public key has to be merged into ssh_authorized_keys and converged before you can reach any box.
ansible installed on the machine you'll converge from (ansible-galaxy collection install -r requirements.yml).
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.
A rack management path. On the PETRA rack there is no DNS server for bedrock.lan; the internal box names are resolved on rack hosts by a managed /etc/hosts block. To SSH from a laptop, be on the rack LAN or use an explicitly provisioned management path that both routes the rack addresses and resolves those names. The Cloudflare phone/device path intentionally exposes neither SSH nor the internal .lan names.
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.

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.

Before you begin¶

Who does what¶

Prerequisites inventory¶

End-to-end checklist¶

See also¶