Hub — overview

The Hub is the brain: a single Rust binary that runs your certificate authority, ACME client, Cyphers Score engine, renewal lifecycle, and the dashboard. Scout is the eyes, deployed on each endpoint; the Hub is the one instance everything reports to.

One binary, two roles

There is exactly one Hub codebase. Which role it plays is a boot-time configuration choice — CYPHERS_ROLE (satellite or master; the legacy CYPHERS_MASTER_MODE=true/false boolean still works and maps to the same two roles) — not a fork or a separate build. If CYPHERS_ROLE is unset or unrecognized, the Hub defaults to satellite.

flowchart LR
    subgraph satellite [Satellite Hub - your network]
        S["Hub, role satellite"] --- PG1[("PostgreSQL")]
        S --- Sc["Scout agents"]
    end
    subgraph masterinfra [Master Hub]
        M["Hub, role master"] --- PG2[("PostgreSQL")]
        M --- CH[("ClickHouse: CT log corpus")]
    end
    S -->|"mTLS CT Intel query"| M

Role	CYPHERS_ROLE	What it runs	Where it runs
Satellite Hub	satellite (default)	ACME/CA lifecycle, mTLS enrollment, Scout command queue, fleet posture, dashboard. PostgreSQL only — no local ClickHouse.	Your network — one Docker Compose (or native) appliance per customer.
Master Hub	master	Everything a Satellite runs, plus Certificate Transparency log ingestion into ClickHouse and DNS TXT delegation control-plane routes.	Cyphers' own infrastructure, or self-hosted on-prem by a customer that wants its own Master.

A Satellite is the day-to-day product: local certificate lifecycle management against your own fleet. What "Satellite" adds over a bare, CT-disabled Hub is a live query path to a Master Hub's Certificate Transparency intelligence — public issuance/name evidence for domains you care about, without running a CT log scanner and a multi-hundred-GB ClickHouse corpus yourself. That query path is mTLS-authenticated; the Master never receives or controls your local CA private keys.

A Master is centralized infrastructure: it scans public CT logs continuously, stores every certificate it sees in ClickHouse, and answers authenticated CT Intel queries from Satellites. It also runs the DNS TXT delegation control-plane, so Satellites can complete ACME DNS-01 challenges without holding their own DNS provider credentials.

Mode gates live in hub/src/main.rs (route registration) and hub/src/config/mod.rs (HubRole resolution); see docs/agent/architecture.md for the full route/module breakdown.

Where to go next

• Satellite Hub — install procedure — the deliverable: prerequisites, the Master-dependency chain, step-by-step install (Docker Compose and packaged bare-tarball paths), the full satellite env var reference, first-boot CA self-provisioning, the validation preflight gate, and troubleshooting.

Scope of this page

This wiki does not yet carry a standalone Master Hub install page — the Master side of the dependency chain (reachability, the CT Intel mTLS bundle) is documented from the Satellite's point of view in Satellite Hub — install procedure.

Hub PKI endpoints

The Hub runs a public, read-only PKI surface on its Scout REST port (default :8443) — its own CA material, unauthenticated by design. These are Hub endpoints; a running Scout agent is only ever a client of them (and fetches just the CRL, as a revocation-check fallback). They also serve the installer, ops/DR checks, and anything validating a Cyphers-issued certificate:

Hub endpoint (:8443)	Returns	Fetched by
GET /api/ca/chain	the Hub CA chain (intermediate + root), PEM	the installer, to derive the pin
GET /api/ca/crl.pem	the Hub CA's revocation list	the Scout agent (revocation fallback)
GET /api/ca/root	the Hub root CA certificate, PEM	DR/health checks; caIssuers AIA in issued certs
POST /api/ca/ocsp	the Hub CA's OCSP responses (RFC 6960)	nats-server, to staple into the handshake

This table used to live only on the Scout overview page because there was no Hub section to hold it — it moved here since it documents the Hub's own CA surface, not Scout behavior.