Hosts

Flowdrome splits control from execution: the Nucleus manages — it never executes — and hosts run the deployed apps. A host is one machine running the single-file host agent (bare, in Docker, as a Proxmox LXC container, or booted from the live ISO). This guide covers both sides: the Nucleus’s fleet view, and each host’s own dashboard.

The fleet view

Hosts in the Nucleus header lists every enrolled host, grouped by environment — a label like default, docker, prod you assign at enrollment:

The fleet view grouped by environment
The fleet: each host with its agent kind and platform, live status, version, and last-seen. Row actions: open the host's own dashboard, deauthorize, edit, remove.

Enrolling a host

Hosts don’t get passwords — they get join tokens:

  1. Click Join token and create one. It is shown once; treat it like the secret it is.
  2. Hand it to the agent any way that suits the machine: the --join CLI flag, FLOWDROME_JOIN_* environment variables, or paste it into the host GUI’s Connect to Nucleus screen.
  3. The host dials the Nucleus, presents the token, and appears in the fleet as authorized.
The join token modal
The Join token modal — mint tokens here and revoke ones you've issued. A token authorizes enrollment; the host's own identity persists on its data disk.

The host dashboard

Every host serves its own dashboard — open it from the fleet row’s external-link action. It is the same console the Nucleus renders for that host (literally the same component, pointed at the host’s own engine), plus the host’s Nucleus-connection card. What you learn in one place applies in the other, pixel for pixel.

A host's own dashboard: the shared console with workflow rows, per-row controls, and an expanded live performance strip, plus the Nucleus connection card
A host's own dashboard — the shared console: every served workflow with status, version, endpoints and start/stop/pause/remove, an expandable live perf strip per workflow, and the Nucleus connection up top.

Each workflow row expands into its layered performance strip — ops/s, latency, CPU, memory, network, disk and errors on one chart with selectable ranges — with Per node, Recent runs and Logs beneath it. The same rows appear inside the fleet console when you expand this host there:

The fleet console with the same host expanded showing the identical workflow sub-rows
The identical rows inside the Nucleus fleet console — one component, two vantage points.

The history icon on any row opens the full Runs inspector (the Studio’s Runs view) in a floating panel — as many at once as you want, including the same workflow twice for run-vs-run comparison:

A workflow's expanded runs and performance panel
A workflow's runs + per-run performance, served from the host's engine history.
Per-workflow resource telemetry charts inside the console
Per-workflow resource telemetry — CPU, memory, network, disk — sampled by the host itself, so history survives dashboard reloads and Nucleus restarts.

Host settings

The Settings button (host dashboard) and the gear on each fleet row (Nucleus) open the same panel — the host’s engine and logging configuration:

The host settings panel: workers, max concurrent runs, queue depth, node timeout, run history, log directory and telemetry URL
Per-host settings: engine worker pool size, run concurrency and queue depth, node timeout, run-history capacity, the log directory (applies live) and a telemetry export URL. Fields that need a host restart say so.

Settings persist in the host’s data root (settings.json); 0 means “auto” for the numeric knobs. Worker-pool and concurrency changes apply the next time the host’s engine starts; the log directory re-targets live.

The approvals inbox (Nucleus side)

The bell in the Nucleus header is the fleet-wide approvals inbox: every pending gate on every authorized host, polled live. Each card carries the gate’s title and description, the workflow, app and host, and how long it has waited. Approve or Reject (with an optional note) resumes the parked run immediately — the decider is recorded.

A real approval: an order arrives, the bell shows a pending gate, the inbox opens, Approve — and the parked run resumes on its approved branch.

Deploying a workflow to a host

From the workflow, choose Deploy and pick the host — that’s the whole dialog. The Nucleus pushes the same flowdrome.workflow.v1 document you tested, stamped with its saved version, and mints a scoped resolve token (the host’s key to lease that workflow’s secrets at run start). The host registers it with its embedded engine — the same engine Studio tests with — and starts serving its real triggers immediately. The dashboard’s serving strip shows each deployed workflow as “Serving · name vN”, so what version a host runs is never a mystery. The full walkthrough — including operating and rolling back afterwards — is the Deploy to a host guide.

Deauthorizing a host

The fleet row’s deauthorize action revokes the host’s authorization: it stops being able to dial home, receive deployments, or lease secrets. Its row stays (so you can re-authorize a machine that’s coming back); Remove deletes the record entirely. The host’s local data disk is never touched by either — deauthorization is a control-plane decision.

Next

  • Deploy to a host — the full deployment walkthrough.
  • Install — the three host artifacts, including the live ISO appliance.