Administration

Operating a Vulcan CI instance: capacity, worker admission, and the audit surfaces. Admin routes live in Forge under Admin and switch the UI to the steam-cyan context.

Automata & pools

Workers — automata, in admin surfaces — execute build steps. Every automaton belongs to exactly one pool; workflows target pools by name. A pool defines where its workers may come from, which enrollment tokens it accepts, and its admission policy.

Field	Description
Name	Referenced by workflows via `pool`. Renaming breaks references; prefer creating a new pool.
Admission	`manual` (default) or `auto` — see below.
Capacity	Maximum concurrent steps per automaton. Shown as `3 / 24 active` on the pool page.
Labels	Key/value pairs automata report on enrolment, e.g. `arch=arm64`.

Worker admission

Admission is how an automaton joins a pool. Two policies:

Manual — the automaton enrols, appears as pending on the pool page, and an admin approves or rejects it. The default for new pools.
Auto — any automaton presenting a valid enrollment token is admitted immediately. Use for autoscaled fleets where hosts are ephemeral.

On the host, enrolment is one command:

$ vulcan worker enroll --pool linux-arm64 --token $ENROLLMENT_TOKEN
enrolled automaton anvil-07 — pending admission

Enrollment tokens

Enrollment tokens admit workers; they are distinct from the API tokens humans use. Create them in Admin → Tokens, scoped to a single pool, with an optional expiry and admission count.

Single-use — one admission, then the token is spent. Right for hand-provisioned hosts.
Bounded — up to n admissions before an expiry. Right for autoscaling groups.

Delivery log

Every outbound delivery — webhooks, commit-status callbacks, notification emails — is recorded in Admin → Delivery log with its payload, response code, and retry history. Failed deliveries retry with exponential backoff for 24 hours.

The log can be exported as NDJSON for retention or offline audit.