Deploying a Guardian

Install the guardian stack on one host from three inputs: your realm credential, the anchor binaries and a settings file.

Host Requirements

The guardian provides the software stack. You provide the host and keep it secure. Confirm the host's duties yourself.

The guardian provides	You provide
Container images and their cryptography	A FIPS-mode kernel with a validated module, where your baseline needs one
Application TLS and audit records	Encrypted volumes
Roles and access control	The trust chain for your smartcard issuers
The stack's topology and network isolation	Time synchronisation
The compliance profiles	A SIEM, and shipping the audit records to it
Generated secrets and an internal PKI	The host firewall

Requirement	Details
A container host	Linux on x86_64, with Docker and its Compose plugin, openssl and python3. Setup checks for these before it does anything else.
Memory	About 2.7 GB reserved across the services, up to about 10 GB, plus the host's own needs. The table below lists each service.
Disk	Room for 90 days of metrics and flow records, on encrypted storage. The amount grows with the fleet.
Encrypted volumes	Three volumes need encryption at rest: the database, the audit records and the identity service's data. Use your own volume encryption.
/tmp that allows execution	The identity service runs its FIPS self-test from /tmp, so /tmp must allow execution.
Accurate time	Sign-in tokens and certificates depend on it, and clock drift causes intermittent sign-in failures. Run NTP.
One inbound port	`443/tcp`, and nothing else. See Hosting and Exposure for the firewall rules.

Memory, by service

Service	Reserved	Limit
State and audit store	512 MB	2 GB
Identity service	768 MB	2 GB
API server, with the signer and an admin node per realm (about 50 MB each)	512 MB	2 GB
Operator console	256 MB	1 GB
Telemetry intake	128 MB	1 GB
Metrics store	512 MB	2 GB
Front door	64 MB	256 MB

Each limit sits well above its service's normal use. It only stops a fault in one service from affecting the others.

The console's Stack & compliance page shows the same split. It lists what the stack checks itself, what you must confirm and the one published port.

Guardian console — Stack & complianceIllustrative

Stack & complianceguardian-adminStack & complianceWhat this stack can check about itself. Host prerequisites — FIPS kernel, encrypted volumes, time sync, PKI, log shipping — are the deployer's and are not verified here.After first runIngest the realm credentialsecrets/guardian_credential · root seed sealed into the state store.verified by the APICommission the bootstrap nodesPublicly reachable nodes in the guardian realm — the bootstrap list in every manifest.verified by the APIGo to the guardian realm →Collect telemetryEvery manifest carries an export block to this stack's collector; flows are on unless turned off per node.verified by the APIMake the people who sign insetup.sh --first-admin makes the first guardian admin; everyone after it is made on the Accounts page.the deployer's to confirm — the stack cannot see itGo to Accounts →Replace the bootstrap adminCreate the real break-glass admin in the identity service's administration realm, confirm it can sign in, then disable bootstrap-admin.the deployer's to confirm — the stack cannot see itOpen the identity service's users ↗Exercise the outage pathMake the upstream identity provider unreachable and confirm break-glass still reaches the console.the deployer's to confirm — the stack cannot see itBuild the FIPS Node basebuild-node-fips.sh · NODE_BASE=guardian/node-fips:24.21.0 · 30–60 min compile.the deployer's to confirm — the stack cannot see itConfigurationProfileau-ismIdentity modestandaloneApp URLhttps://guardian.example.govAPI URLhttps://guardian.example.govCertificateinternalOTLP endpointguardian.example.gov:443Node credential90 days · 90 at mostNODE_BASEnode:24-trixie-slimPublished portsfront door443the only published port: the console, sign-in at /auth, node renewal, OTLPConsole, API, identity service, collector—reached through the front door onlyState store, metrics store—nothing outside the stackadmin nodes (in the API)UDP outdial this guardian's own bootstrap nodes; nothing dials in

Preparing the Inputs

Run these steps in the guardian checkout on the host.

0 of 3 done

01
$ cp anchord-linux-amd64 anchorctl-linux-amd64 ./bin/
Use the pair that VeilNet supplies with your realm credential. The pair is pinned to your realm's tree, and a pair built for another tree refuses to sign. Setup stops if either binary is missing.
anchorctl must be the locked-down build, and setup rejects any other. If a binary lost its execute bit in transit, setup restores it and prints made bin/anchorctl-linux-amd64 executable.

Settings

On the first run, setup copies the values from .env.example into secrets/.env. From then on, secrets/.env is the configuration. To change a setting, edit secrets/.env and run ./setup.sh again.

Setting	Default	Meaning
`GUARDIAN_HOST`	None	The address that operators and machines use: a DNS name or an IPv4 address, with no scheme, port or path. See Address and Certificate.
`GUARDIAN_PROFILE`	`us-dod`	The compliance profile: `us-dod`, `au-ism` or `uk-mod`. See Compliance Profiles.
`GUARDIAN_MODE`	`standalone`	Where operator accounts live: in the identity service, or in your own identity provider with `brokered`.
`GUARDIAN_TLS`	`internal`	Where the certificate comes from: `internal`, `own` or `acme`.
`GUARDIAN_BIND_ADDR`	`0.0.0.0`	The host address that publishes port 443.
`GUARDIAN_CONSOLE_CONTROL`	`on`	Whether operators act on running machines from the console, or only from conflux. See Console Control.
`GUARDIAN_NODE_CREDENTIAL_DAYS`	90	How long a machine credential lasts, up to 90 days. This lifetime also sets the revocation latency, and no other setting changes it.
`GUARDIAN_DELEGATION_DAYS`	180	How long a sub-realm delegation lasts.
`GUARDIAN_RENEWAL_LEAD_DAYS`	14	How many days before expiry the guardian renews a sub-realm delegation and, when online, the realm credential.
`NODE_BASE`	`node:24-trixie-slim`	The Node.js base image. To use FIPS, name the FIPS base here. See FIPS.

Brokered sign-in needs eleven more values from your identity provider. See Sign-in Modes.

Telemetry has no setting, because every machine reports. Setup ignores a leftover GUARDIAN_TELEMETRY line and warns about it.

Telemetry intervals

Two settings control how often telemetry is collected. The defaults suit most fleets. A shorter interval means more telemetry traffic and more stored data.

Setting	Default	Range	Meaning
`GUARDIAN_INBAND_INTERVAL_SECONDS`	30	5 to 300	How often each realm's admin node asks every machine for its current readings.
`GUARDIAN_METRIC_INTERVAL_SECONDS`	60	5 to 3600	How often each machine exports its metrics. The value is written into each manifest, so a change reaches only machines commissioned after it.

Console Control

GUARDIAN_CONSOLE_CONTROL decides where operators act on running machines: from the console, or from conflux. These actions are blocking and unblocking machines, moving them between compartments and setting the networks a gateway serves.

GUARDIAN_CONSOLE_CONTROL	Operators act from	How it works
`on`	The console	For each action, the realm's admin node is lent the one power that the action needs, for ten minutes. Then it returns to its standing credential.
`off`	conflux, on their own machine	No admin node ever holds a power that acts on machines. Instead, an operator issues a control credential from the realm's page. It is a conflux manifest that lasts 1, 4, 8 or 24 hours. The console shows it once, keeps no copy and never renews it. The console shows what is in force but takes no action.

In both modes, the realm's Control activity records every action and every control credential issued, including refusals.

To change the setting, edit secrets/.env and run setup:

$ $EDITOR secrets/.env         # GUARDIAN_CONSOLE_CONTROL=off
$ ./setup.sh

Setup recreates the API server with the new value. Its summary does not show this setting, so check it on Settings → Realm control.

Guardian console — Settings, realm control offIllustrative

Settingsguardian-adminSettingsHow this guardian stack is configured, read back from the API and the deployment.Read-only. The API has no settings routes — every value here is set on the host, and each one names where.Realm controlWhat operators may do to a running node, and through what.Console controlOff: no admin node is given a power that acts on members. Operators do the same from conflux, with a control credential.off — CLIGUARDIAN_CONSOLE_CONTROL · secrets/.envAdmin nodesOne per realm, made with the realm and started with this stack. Each orders its realm's telemetry, and is given a power that acts on members for one action at a time.one per realm · in the API containerone daemon eachTelemetryRead a member's own report. Held between actions, on a week-long credential renewed daily.grantedcredential · chainBlockMake a node an outsider to every member of its realm, or let it back in. Held for ten minutes at most, for one action.granted · CLI onlycredential · chainCompartmentsMove a node to other compartments while it runs. Its credential keeps the ones it was commissioned with.granted · CLI onlycredential · chainNetworks servedChange which networks a node forwards for its realm. conflux up --subnet on the machine sets them again.granted · CLI onlycredential · chainNodes themselves are issued no power. Every action is recorded, refusals included, for auditors.

Running Setup

To set up the stack and create the first administrator, run:

$ ./setup.sh --first-admin a.morgan

Setup works through these stages in order:

It checks every setting and the credential, and lists every problem before it changes anything.
It writes the deployment's secrets, its internal certificate authority and its settings into the secrets directory.
It builds and starts the stack, then waits up to 15 minutes for every service to become healthy.
It applies the settings to the identity service: the console's address, the account-management client and the sign-in notice.
On a standalone deployment, it creates the first administrator, unless an account with that name exists. It writes the temporary password to secrets/first-admin.env and never prints it.

A first run, abridged

$ ./setup.sh --first-admin a.morgan
==> Preflight
    docker 28.3.2, compose 2.39.1
    openssl 3.0.17
    anchord      21M
    anchorctl    9.6M (lockdown)
==> Settings, from .env.example
    credential   Northern Command -- tier2, realm named by its chain, delegated until 2026-10-31T00:00:00Z, renewal online
    profile      au-ism
    accounts     standalone
    address      https://guardian.example.gov -- the app, sign-in at /auth, node renewal
    certificate  internal
    telemetry    every manifest exports to guardian.example.gov:443
==> Node base image
    …
==> Settings file
    wrote secrets/.env from .env.example
    derived the URLs, OTLP endpoint and node uid into secrets/.env
    linked ./.env to secrets/.env, for docker compose
==> Internal PKI
    generated internal CA (P-384, 825d)
    …
==> Realm credential
    guardian     Northern Command
    tier         tier2
    realm        named by its chain
    delegation   until 2026-10-31T00:00:00Z
==> Starting the stack
    building the images and starting every service -- the first run takes several minutes
    every service is up
    created a.morgan, a guardian admin; its temporary password is in ./secrets/first-admin.env

Guardian is running.

The run ends with Guardian is running. when the stack is up.

The secrets directory holds the deployment. Everything the containers take from the host is written there, including the settings. To back up the configuration, back up this directory. See Backup and Restore.
You can run setup again at any time. It fills in what is missing and updates anything that depends on the settings, such as a certificate that no longer names the host. It leaves existing secrets unchanged.
--no-start writes the secrets directory without starting the stack. You cannot combine it with --first-admin, which needs a running stack.

After the First Run

0 of 4 done

On a standalone deployment, sign in to the console with the temporary password from secrets/first-admin.env. Set up a one-time code and choose a new password, then delete the file.
Create every other account on the console's Accounts page. In brokered mode, your identity provider holds the accounts, and its groups set the roles.

Host Requirements

Preparing the Inputs

Copy the anchor binaries+

Copy the realm credential+

Fill in the settings+

Settings

Telemetry intervals

Console Control

Running Setup

After the First Run

Sign in as the first administrator+

Replace the bootstrap administrator+

Ship the audit records and test break-glass access+

Commission your bootstrap nodes+