What you're setting up#
A Connected Compute node is a machine you control that pulls governed work from your workspace, executes it under your workspace's policy, and reports evidence back — your compute, LumenFlow's governance. See Connected Compute for the concept and Which credential is for what for how this fits alongside your other workspace credentials.
Prerequisites#
- A recent Node.js runtime available on the machine (the current setup path
runs a small bootstrap script with
node). - Outbound HTTPS access to your workspace's cloud endpoint from a PowerShell or terminal session. Nothing needs to listen for inbound connections — see Firewall and outbound networking below.
- Workspace owner or admin access, to generate the credential this machine will use.
Step 1 — Get your machine's credential#
Open your workspace's Compute page and use Runner setup, choosing Windows. This mints a one-time credential for this workspace and generates the exact PowerShell commands for this machine — connect, doctor, and a one-iteration run. Copy the generated command directly from the page rather than adapting a Linux command by hand: Windows PowerShell and POSIX shell commands are never meant to be mixed in the same command block.
warning The credential is shown once. Don't paste it into a ticket, a chat message, or a shared document — treat it as burned if it ever appears anywhere outside that one command, and re-run Runner setup for a fresh one.
Step 2 — Connect#
Run the generated connect command in PowerShell on the Windows machine. It writes a local credential file (not printed to your screen after this step) and registers a runner session with your workspace.
Step 3 — Doctor#
Run the generated doctor command. It reports, in plain terms:
| What doctor checks | What it means |
|---|---|
| Credential file present | The local credential from Step 2 was found and is readable |
| Runtime claim admission | Your workspace accepted this machine's request to claim work |
| Runner session | The session id your workspace is tracking for this machine |
| Capability probe | What this machine advertised it can do |
| Confinement posture | The isolation level LumenFlow detected on this machine |
| Energy sensor | Whether measured energy readings are available on this machine, or only modeled/estimated |
| Work availability | Whether there's eligible work queued for this machine right now |
no eligible work is a healthy idle state, not an error — it means the
machine is connected and polling, and there's simply nothing queued for it.
Firewall and outbound networking#
This machine only ever calls out to your workspace's cloud endpoint over HTTPS — it polls for work, then reports back. LumenFlow never opens a connection into your machine. You don't need to open an inbound port, configure Windows Firewall for an inbound rule, or forward anything beyond normal outbound HTTPS.
Confinement and energy on Windows#
Windows machines run at a reduced isolation posture by default compared to Linux — doctor's confinement line reports which one your machine actually has, and reduced-posture machines are kept off privileged mutation work. Measured energy readings are also not currently available on Windows through the diagnostic setup path (this is most visible on AMD/Ryzen hardware): energy for assignments on this machine shows as modeled or estimated rather than measured until an admitted Windows sensor ships. Don't treat a modeled or estimated figure as a sensor reading.
Local models on this machine#
If you point this machine at a model you're running locally (for example an
OpenAI-compatible server on localhost), your workspace's model
configuration needs the matching endpoint and model id, and the endpoint
needs to be reachable from this machine specifically. Doctor's report
includes whether that endpoint is reachable. LumenFlow never silently
substitutes a different model when your configured local one is
unreachable — it holds or refuses the assignment instead.
Drain, quarantine, and remove this node#
- Drain — stop the machine from claiming new work while letting anything already in progress finish or fail safely. Use this before planned maintenance or a reboot.
- Quarantine — stop the machine claiming anything at all, immediately, while you investigate something unexpected.
- Revoke — invalidate this machine's credential outright. A revoked machine fails closed on its next request.
- Remove the local install — stop the running process and delete the local credential file. Your workspace keeps the historical evidence for work this machine already did; removing the local files doesn't erase that record.
These actions are available today through your workspace owner/admin — ask us if you don't see a control for one of them yet on the machine's row in the Compute page, and we'll help.
What's not live yet#
A signed Windows installer (WinGet package or MSI) with a proper Windows service — start/stop/restart/logs/upgrade built in — is planned but not yet published. Today's verified path is the diagnostic connect → doctor → run loop above, kept running in a terminal or PowerShell window you control. We'll update this guide the moment a signed package ships.