Deploy to a host

You have a workflow that tests green. Time to make it someone’s job — a host’s.

0. Have a host

Any of the four install artifacts works: the single-file agent, the Docker image, a Proxmox LXC container, or a VM booted from the live ISO. For a quick local ride, the host can run on the same machine as the Nucleus.

1. Enroll it

  1. Nucleus → Hosts → Enroll: create a join token.
  2. Hand it to the agent — CLI --join, FLOWDROME_JOIN_* environment variables, or paste it into the host GUI’s Connect to Nucleus screen.
  3. The host appears in the fleet view as authorized, with its environment label, status and an open-host link.

If hosts live on other machines, make sure the Nucleus was started with a routable FLOWDROME_NUCLEUS_PUBLIC_URL — that URL is baked into deployments as the dial-home address.

2. Deploy the workflow

From the workflow (Studio toolbar or the Workflows view), choose Deploy and pick the host — that’s the whole dialog. The host runs the workflow on its shared embedded engine (the same engine Studio tests with), so there is nothing to compile and no artifact mode to choose.

The deploy:

  1. takes the exact document you tested (flowdrome.workflow.v1, no conversion) and stamps it with the workflow’s saved version and deploy time,
  2. mints a resolve token scoped to this deployment (the host’s key to lease this workflow’s secrets at run start),
  3. pushes it to the host, which persists the deploy envelope and starts serving the workflow’s real triggers immediately.

3. Watch it

  • Workflows view — the workflow’s row expands to its deployments: host, status, and a version badge — teal vN when the deployment runs the current saved version, orange when a newer save exists (drift you can see). The logs drawer streams output through the Nucleus.
  • Host dashboard — everything the host serves, with status and uptime, the run ledger, and the Resources tab (CPU, memory, disk). The serving strip shows each workflow as “Serving · name vN”.
  • Rollback — restore an older version from the workflow’s history and the rocket action redeploys it to every host currently serving that workflow, in one step.

4. Operate it

ActionEffect
StopGraceful; the deployment shows stopped (not failed) and stays installed.
RestartStop + start, sub-second.
RedeployThe new document replaces the old, same workflow identity (deployments match by workflow id, so renames don’t orphan them).
RemoveUninstalls the workflow from the host.

Triggers behave per the production trigger model: real triggers serve continuously, Inject fixtures are inert, Manual makes the deployment a run-once job.

Checklist for real workloads

  • Started the Nucleus with a routable FLOWDROME_NUCLEUS_PUBLIC_URL? (Secrets leasing and dial-home depend on it.)
  • Proxmox/VM hosts: CPU type host — the engine worker’s Bun build needs AVX2.
  • Credentials referenced by the workflow exist and are connected (OAuth2 ones show green).
  • The recovery lane is wired if this workflow should page you when it fails — error handling.