Stand Up a Deployment¶
What this is: the start-to-finish order for bringing a whole Bedrock deployment online from nothing — the master checklist that ties the individual runbooks together. When you'd do it: a new site, a new customer, or a fresh environment. How long it takes: plan for a day or two end-to-end; most of it is the one-time certificate and Directory setup.
Who does this: a deployment engineer (stands up the machines), a security/PKI engineer (the certificate chain), and an Admin (runs the Directory once it's live). On a small team that may be one or two people wearing several hats.
This page doesn't repeat the detail — each step links to its own runbook. Work top to bottom; the order matters, because each step depends on the one before it.
The order, and why¶
flowchart TD
PKI["1. Certificate chain<br/>(PKI)"] --> DIR["2. Directory<br/>(identity authority)"]
DIR --> SRV["3. Servers<br/>(relays)"]
SRV --> WEB["4. Web client"]
WEB --> PPL["5. Onboard<br/>people & devices"]
PPL --> RUN["Running deployment<br/>(rotate / revoke as needed)"]
- Certificates first — nothing can be trusted until the trust chain exists. Servers and clients all check certificates before they'll talk.
- Directory next — it's the identity authority: it issues the tokens and permits everything else relies on. Servers can't enrol and people can't log in until it's up.
- Servers — the relays that carry traffic. Each one gets its permit (a ServerToken) from the Directory, so the Directory must exist first.
- Web client — gives people a browser way in. It points at a server and logs in through the Directory.
- People & devices last — once there's somewhere to connect and something to log into, you onboard the actual users and kit.
Before you start¶
- Cloud project (or host machines) ready, and access to it — see the
infrastructurerepo. - Your root-CA decision made (existing enterprise root vs standalone) — this shapes everything below. See Set up the certificate chain.
- The hostnames you'll use for the Directory, the servers, and the web client.
- The areas your servers will cover (their geofencing cells).
The steps¶
1. Set up the certificate chain (PKI)¶
Stand up the root and intermediates everything else will trust. ➡️ Set up the certificate chain (PKI)
2. Stand up the Directory¶
Deploy the identity authority, then register the first Admin so you can sign in. Everything after this is done as that Admin. ➡️ Stand up the Directory
3. Add your servers¶
Bring up one or more relays and register each with the Directory (name, classification ceiling, coverage area). ➡️ Add a server
4. Stand up the web client¶
Deploy the browser client and point it at a server and the Directory. ➡️ Stand up the web client
5. Onboard people and devices¶
Now the deployment is ready to use — add the operators and the kit. ➡️ Onboard an operator · Onboard a device
Keeping it running¶
Once live, the ongoing jobs are: ➡️ Rotate keys · Revoke a principal
How to know the deployment is up¶
Walk the chain end to end:
- A client trusts the servers' certificates (no warnings).
- The Directory dashboard loads and you can sign in as the Admin.
- At least one server shows healthy and clients can connect to it.
- A test operator can log in (web or app) and see other connected users.
If all four hold, the deployment is live.
See also¶
- Operator training index
- System overview — the eight components and how they fit.
- The
infrastructurerepo — the cloud provisioning that underpins steps 2–4.
Verified against directory@e8287cd on 2026-06-07 — sequencing cross-checked with architecture/overview.md and the infrastructure repo.